Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AsyncRelayCommand.NotifyCanExecuteChanged() must be run on the main thread #458

Open
widnat opened this issue Aug 23, 2024 · 6 comments
Open

Comments

@widnat
Copy link

widnat commented Aug 23, 2024

Type of issue

Missing information

Description

In multiple instances, after calling MyAsyncRelayCommand.NotifyCanExecuteChanged() my Android app was crashing because this call needs to be run on the main thread.

Page URL

https://learn.microsoft.com/en-us/dotnet/communitytoolkit/mvvm/asyncrelaycommand

Content source URL

https://github.com/MicrosoftDocs/CommunityToolkit/blob/main/docs/mvvm/AsyncRelayCommand.md

Document Version Independent Id

708935cd-5970-b89b-8443-2e758f35a54b

Article author

@Sergio0694

Metadata

  • ID: 708935cd-5970-b89b-8443-2e758f35a54b
  • Service: dotnet-communitytoolkit
  • Sub-service: mvvm-toolkit
@Sergio0694
Copy link
Contributor

Not sure I see the issue here. That method should be called on the UI thread, yes. Same as OnPropertyChanged. ...Yes?

@widnat
Copy link
Author

widnat commented Aug 23, 2024

OnPropertyChanged is called from any thread so that the main thread can update the UI. In Xamarin forms the equivalent command to NotifyCanExecuteChanged is RaiseCanExecuteChanged which can be called from any thread so that the main thread can update the UI.

@widnat
Copy link
Author

widnat commented Aug 23, 2024

If this call is not going to be changed to be safely called from a thread that is not the UI thread, I think it would be good to put a warning that it needs to be called from the UI thread.

@bijington
Copy link
Collaborator

It's worth considering that this toolkit is agnostic to UI frameworks and therefore it can't dispatch to the UI thread.

@Sergio0694
Copy link
Contributor

"to be safely called from a thread that is not the UI thread"

There is nothing about that call that makes it not safe to be called from a non-UI thread. The reason why it's crashing in some UI frameworks is because they are invoking a handler on the same thread while requiring the UI thread to run the actual callback code. It's their responsibility to dispatch the handlers back on the UI thread if they need that. Or, if you want to work around that yourself, you can of course just make sure to set those properties and call those methods from the UI thread from the start. But this is just the expected behavior. That said, sure, we can add a note just as an FYI in case it helps 🙂

@widnat
Copy link
Author

widnat commented Aug 23, 2024

Ok, that makes sense. I didn't realize that the framework needed to handle that. Thanks for the responses!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants