Lifecycle binding

in CameraFragment you call

CameraX.bindToLifecycle(this, preview, imageCapture, imageAnalyzer)

meaning you bind it to fragment’s lifecycle. But you call this method on onViewCreated() which means you would receive the old lifecycleOwner. To avoid crashing you every time also call CameraX.unbindAll() which is some sort of work around. Instead it would be better to call CameraX.bindToLifecycle() with viewLifecycleOwner. Then you can delete CameraX.unbindAll()

Thus, it seems like you have misused fragment’s lifecycle with view’s lifecycle. Correct me I am wrong. Thanks

[BulatMukhutdinov]

Could you please explicitly specify where in the sample CameraX *initialize* happens?

[owahltinez]

I’m not sure what you mean by “the old lifecycleOwner”. The current sample is using the fragment’s lifecycle, which usually is the same as the view’s lifecycle except CameraFragment sets the retainInstance flag.

By attaching CameraX to the fragment lifecycle, we avoid CameraX being fully torn down (and thus closing the camera) upon config changes like rotation. The intent is to allow for CameraX to maintain some of its state by doing: CameraX.unbindAll() → CameraX.bindToLifecycle(), which happens during onViewCreated.

By using the view’s lifecycle, the order of events is: CameraX *teardown* → CameraX *initialize* → CameraX.bindToLifecycle(). However, I just tested this and it seems that this results in snappier transitions during device rotations on a Pixel 3 device. I’m guessing it’s due to the teardown starting as the view gets destroyed, rather than doing everything during onViewCreated.

I will investigate the potential implications of switching to the view’s lifecycle. It’s likely that devices with slow camera open/close will have degraded performance using this path. We have to take into consideration other things such as navigation, multi-window environments, etc.