Android: Re-evaluate camera locking logic

[opcodewriter]

I'm using ZXingScannerFragment and I see a problem accessing the camera after navigating away from the Activity which contains the fragment.
I'm calling StopScanning like this

        public override void OnPause ()
        {
            base.OnPause ();
            _scannerFragment.StopScanning ();
        }

I have a settings screen where I enumerate available cameras so that user can select the front or back camera for scanning. Sometimes the camera id list is empty, sometimes it's non-empty but accessing a camera throws CameraException, and sometimes everything works!:

CameraMaanager cameraManager = (CameraManager)topActivity.GetSystemService (Context.CameraService);
string[] cameraIdList = cameraManager.GetCameraIdList ();
return cameraIdList.Select ((iCamera) => GetCameraInfo(iCamera)).ToList ();

Digging in the ZXing.Net.Mobile code, I can see that ZXingSurfaceView.ShutdownCamera() starts a thread which runs different shutdown stuff:

https://github.com/Redth/ZXing.Net.Mobile/blob/master/Source/ZXing.Net.Mobile.Android/ZXingSurfaceView.cs#L506

            // make this asyncronous so that we can return from the view straight away instead of waiting for the camera to release.
            Task.Factory.StartNew (() => {
                try {
                    if (theCamera != null) {
                        try {
                            theCamera.SetPreviewCallback (null);
                            theCamera.SetPreviewDisplay (null);
                            theCamera.StopPreview ();
                        } catch (Exception ex) {
                            Android.Util.Log.Error (MobileBarcodeScanner.TAG, ex.ToString ());
                        }
                        theCamera.Release ();
                    }
                } catch (Exception e) {
                    Android.Util.Log.Error (MobileBarcodeScanner.TAG, e.ToString ());
                } finally {
                    ReleaseExclusiveAccess ();
                }
            });

But this makes it hard for me to know in my code when I can access the camera without errors.
I wish the stopping mechanism was awaitable. Or maybe there is already a way I'm not aware of?
Maybe I'm missing something, but this looks to me like a big problem. Is there a workaround?

I can't see other solution than having a loop which runs until a non-empty camera id list is available and no CameraException are caught....
I'd appreciate some thoughts...

[opcodewriter]

I think ZXingSurfaceView.ShutdownCamera() should be synchronous, it shouldn't start a thread

[Redth]

We can probably make the stopping awaitable pretty easily. I don't want to make it all synchronous again since that would make the UI slower. I recently refractored a lot of this code but didn't re-evaluate the exclusive camera locking code. I think it's worth doing this for v2.2

[opcodewriter]

@Redth Thanks for the comment.
After more thinking, I don't think making the stopping awaitable is a solution. Awaiting on it won't help because navigation to another screen which accesses the camera too is still going to run in parallel.

I think the solution is to synchronize the access to camera across app code and ZXing.Net.Mobile library:

• have a flag in MobileBarcodeScanningOptions, which tells ShutdownCamera to use a thread or not, something like IsShutdownCameraAsync. Not ideal, because as you said makes UI a bit slower, but after I removed the thread from ShutdownCamera, testing on a Samsung Galaxy A5 for example, there is no noticeable delay in UI. This might be a very simple solution for apps which really do not access to camera themselves.

• have ShutdownCamera as it is today, but expose synchronization to camera access outside the library. So if an app using ZXing.Net library accesses the camera too, it has to use same synchronization mechanism used by ZXing.Net. Not sure what would be the best way to implement this. Maybe expose the _cameraLockEvent event or have a camera access singleton with methods like

  Task<bool> ZXingCameraAccess.GetExclusiveAccessAsync(Timespan) and
  Task ZXingCameraAccess.ReleaseExclusiveAccessAsync().

Another thing: I mentioned that I was using Camera2 API in my app to enumerate device cameras. It looks like when I switched to use the deprecated Camera API, problems disappeared. So it looks to me that mixing the two Camera API is not recommended, but this shows another problem for apps which use both the newer Camera APIs and ZXing.Net.Mobile

[opcodewriter]

In the case you're reading this by email notification, I did several modifications to my comment after initial posting. Thanks!

[opcodewriter]

@Redth You mentioned you don't want to change ShutdownCamera() to be synchronous to avoid blocking the UI, which makes sense. However, existing SetupCamera() is synchronous and it's blocking the UI in a really perceptive way(I get a gray screen for somewhere less than 1 sec).