UIKit.UIKitThreadAccessException: UIKit Consistency error: you are calling a UIKit method that can only be invoked from the UI thread.

[Mike-E-angelo]

I am making use of the CameraCaptureUI.CaptureFileAsync which works fine in Android but in iOS, it fails with the error:

System.InvalidOperationException: Command 'TakePhoto' failed when executing command with '-null-'.
 ---> UIKit.UIKitThreadAccessException: UIKit Consistency error: you are calling a UIKit method that can only be invoked from the UI thread.
   at void UIKit.UIApplication.EnsureUIThread() in /Users/builder/azdo/_work/5/s/xamarin-macios/src/UIKit/UIApplication.cs:line 111
   at new UIKit.UIImagePickerControllerDelegate() in /Users/builder/azdo/_work/5/s/xamarin-macios/src/build/dotnet/ios/generated-sources/UIKit/UIImagePickerControllerDelegate.g.cs:line 143
   at new Windows.Media.Capture.CameraDelegate()
   at async Task<StorageFile> Windows.Media.Capture.CameraCaptureUI.CaptureFile(CancellationToken ct, CameraCaptureUIMode mode)
   at async void Windows.Foundation.AsyncOperation<Windows.Storage.StorageFile>+<BuildTaskAsync>d__23.MoveNext()
   at async void System.WindowsRuntimeSystemExtensions+<AsTaskCore>d__11<Windows.Storage.StorageFile>.MoveNext()

This is being called from a MVUX model, and it's surprising to see that this is not being called on the UI thread by default.

Is there a way to ensure that commands executed from the UI are run on the UI thread?

Thank you for any assistance you can provide.

[jeromelaban]

Thanks for the report. Could you tell which version of the uno.sdk you're using?

[Mike-E-angelo]

Thank you for the quick response @jeromelaban. I am using 5.6.45 here.

[Mike-E-angelo]

Additionally, it appears that the iOS version selects the library instead of the camera:

It requires the NSPhotoLibraryUsageDescription setting and not the NSCameraUsageDescription setting. 🤔

[Mike-E-angelo]

I have created #19716 to track 🙏

[Mike-E-angelo]

Hi @jeromelaban the UI thread issue appears to be more fundamental than the CameraCaptureUI and is due to how AsyncCommand is executing. From WPF/Silverlight it was expected that every command fired on the UI thread. Of course, WPF/Silverlight didn't have asynchronous operations at the time. 😁 But it would be the expectation here that any calls made directly on the model would be on the UI thread. I have captured this on https://github.com/unoplatform/uno/issues/19717

[francoistanguay]

MVUX is running commands OFF UI Thread and it's by design. You want to leave the UI thread as soon as possible. Conceptually, UI-level apis like Camera Capture shouldnt be called directly from "Models" and either be wrapped in a service or in all cases, called using Dispatcher to go back on UI Thread.

[Mike-E-angelo]

Thank you for the clarification @francoistanguay. I am in agreement that typically one wants to leave the UI thread where possible, but in cases like this it would be convenient to configure the method so that it gets called on the UI thread. Additionally, as I recall, all calls on WPF were marshalled on the UI thread by default so there's some expectation that this would carry over.

Ideally, it would be valuable to somehow decorate the method with an attribute to denote that it should run on the UI thread. Is this possible with MVUX? If you can point me in a direction where I can possibly create a solution to make this possible, it would be appreciated. Thank you for your efforts out there. 🙏

[francoistanguay]

Totally agree it would be useful. That's a feature request we could eventually explore in MVUX or support if someone wanted to take a stab at a spec+implementation.

In the meantime, I do believe we have an IDispatcher interface in Extensions.Core you can rely on (but I think you need to be using Navigation as well):

https://github.com/unoplatform/uno.extensions/blob/f42061a36717d8ae0db091c363c27ec2d1e39940/src/Uno.Extensions.Navigation.UI/ServiceProviderExtensions.cs#L29

I'll mark this as Closed for now but please feel free to open a separate discussion about the feature if you still strongly feel it's appropriate!

[Mike-E-angelo]

Thank you for that, @francoistanguay. I am aware of this dependency, which is why I suggest using an attribute to encapsulate it so that it's not a required dependency for the model whenever this scenario is encountered. It's surprising to learn that MVUX does not have an extensibility point to do this. Please let me know if I have misunderstood.