Which is better MainThread.Being/Invoke... VS Dispatcher.Dispatch...

[michaelstonis]

In MAUI, we now have multiple ways to execute code on the Main/Dispatcher/UI thread.

The MainThread class was carried over from Xamarin.Essentials and offers a good, generic way to access the main thread virtually anywhere in code.

BindableObjects now have a Dispatcher property which can be used to get access to the main thread.

From the outside, both of these offer essentially the same subset of functionality. There might be situational differences for when you would want to call these though (i.e. do I currently have a BindableObject handy). Are there other reasons why to prefer one of these over the other or are they functionally equivalent? Is there any performance gain between one or the other? For example, is MainThread static and always available, but Dispatcher is lazy loaded or evaluated. I just want to make sure that I understand the differences and use cases, if any.

[mattleibow]

Good question.

So you are correct, there are different ways to invoke on the main thread:

• BindableObject.Dispatcher.Dispatch()
• Dispatcher.GetForCurrentThread().Dispatch()
• MainThread.BeginInvokeOnMainThread()

All 3 use the same mechanisms under the hood since both use platform APIs to get to the main thread. However, the main difference is the fact that the Dispatcher is coming from a UI object, so always knows which thread to use. The MainThread is static so it is mostly correct. Let me explain.

When you have a UI component (BindableObject, Button, Page, Window), it knows which thread it is assigned to. Some platforms, like Windows and iOS, require that UI objects be created on the UI thread. It will throw otherwise. And, the dispatcher is initialized to that thread.

MainThread has no concept of the UI thread so picks the first one. In most cases, it is correct because most platforms only have 1 "main thread". Windows is an outlier to this because it supports windows on separate threads. The current implementation is actually going to pick the current window that is in focus - which is correct 90% of the time since by default apps share a single UI thread. However, if the user was to instantiate a new window in a new thread, then MainThread would switch when the other window is selected.

So, what is the "correct" way to do things? Well, mostly I would say use dispatcher if you can - keep in mind that you can pass the IDispatcher around and can inject it via dependency injection because it is part of the DI system already. You can also pass the instance around since the object is valid for as long as the thread is valid.

There is also a Dispatcher.GetForCurrentThread() that can be used. This is different to MainThread in that MainThread will always try find a UI thread. GetForCurrentThread will return null if the current thread has no dispatcher.

If you have a VM that needs a dispatcher, the best way would be to use IDispatcher in the constructor, and let DI inject the current instance. And you can test the VM by making the test add any thread/no-thread dispatcher. This allows for tests that can test a VM, but not require ANY UI components.

[HomeroLara]

Wow, great question @michaelstonis and thanks for the answer @mattleibow.

[AndreasReitberger]

@mattleibow thanks for this great answer. Would you mind if you created a small example for this?

If you have a VM that needs a dispatcher, the best way would be to use IDispatcher in the constructor, and let DI inject the current instance. And you can test the VM by making the test add any thread/no-thread dispatcher. This allows for tests that can test a VM, but not require ANY UI components.

[taublast]

As @mattleibow said since this Dispatcher thing comes from an UI object there may be cases when Dispatcher is just not available yet due to the lifecycle of of the UI object while the static MainThread is already available. And an absolutely contrary case is possible too. I've met many cases when at one point (mainly at app startup) Dispatcher main thread was available on Windows and Mainthread was not, and an absolutely inversed situation was on other platforms.

So instead of creating an "upon ptaform" different code to workarounf such cases its better to create a safe check: you execute MainThread.BeginInvokeOnMainThread then check inside if (MainThread.IsMainThread) if not we wait a tiny bit and try to repeat the execution from scratch.