With all this set, start by checking if we have camera permission, we start the camera and if we do not have it, we request for it. The bindToLifeCycle method returns a Camera object and takes a LifecycleOwner, the CameraSelector, and the last parameter being the various usecases and for the current case, we will pass only the preview usecase.

We then proceed to unbind all the usecases if any were bound and then call the method cameraProvider.bindToLifecycle(). What you should pay attention to here again is the way the CameraSelector is constructed still by following the Builder pattern and also, the creation of the cameraProvider which takes place in lifecycleScope.launch since the await is a suspend function.We have simply decided to use the back camera by default using the CameraSelector’s Builder requireLensFacing() method. Thus most of the time, you will see statements like the one below. Once the object is created(or built), it cannot be changed. With the Builder pattern, a complex object delegates its creation to a particular Builder class rather than itself. This understanding alone helps you a lot in figuring out a lot. Early Spoiler Alertīefore we even go further, I would like to call your attention to understanding that most of CameraX's development revolves around the Builder pattern. Still, if you need full control of the camera, then CameraX is your go-to library for Android development.CameraX saves you the hassle of worrying about dealing with the different manufacturers for cameras for the many Android devices and focus on developing a Camera app. If your interest is not controlling the camera and you just need to take a photo, the simplest thing to do is to launch a camera intent to take a photo.

Building an app that uses Camera features like Instagram or Snapchat on Android has been a hassle for Android devs partly due to the many manufacturers of devices and the wide range of their equipment manufacturers.

Android studio preview view