All blog posts with a title that starts with [MVVMbasics] are related to the MVVMbasics framework. If you are only interested in my regular blog posts and not in MVVMbasics, ignore these. To list all articles covering MVVMbasics, go to http://mvvmbasics.mobilemotion.eu/documentation!
In .NET front end applications, all code that accesses user interface elements needs to be executed on the main UI thread. Business logic, however, might run on separate threads – for example, network or NFC communication callbacks are usually executed on separate threads, as well as long-running business logic that is typically assigned to a separate thread intentionally in order to not block the graphical user interface.
If such code blocks shall be able to update the user interface, the statements that actually access UI elements in order to update them need to be explicitly assigned back to the UI thread. All common platforms (such as Windows Store, Windows Phone, WPF, etc.) feature some dispatcher object that takes care of scheduling certain statements to be executed on the UI thread: As developer, you don’t need to find the actual UI thread and assign code statements to this thread, instead you simply instruct the dispatcher to do that for you.
Unfortunately the dispatcher pattern is realized in different ways on those platforms – they all have their own implementation of dispatcher objects that reside within different namespaces and offer varying methods. When developing applications that target multiple platforms, there is no common way of accessing a single dispatcher object from within cross-platforms Viewmodels – however, business logic is typically executed on the MVVM Viewmodel layer, so platform-dependent implementations are not a useful alternative either since this implies that business logic is implemented redundantly for each target platform.
This is where the smart dispatcher that is integrated in MVVMbasics version 2.1 (and higher) comes into play: If you’re fully implementing the MVVMbasics pattern and derive views from the
BaseView class and the application class from
BaseApplication, all Viewmodels derived from MVVMbasics‘s
BaseViewmodel class provide the new
RunOnMainThread(Action a) method. This method checks whether a certain action would (if simply executed) run on some separate thread that does not have access to the UI thread, and if so instructs the dispatcher to assign it to the UI thread.
Using the MVVM pattern, direct access to UI elements is typically replaced by data binding. This means, only the
PropertyChanged event that informs the UI about changes in the underlying data needs to be raised on the UI thread. When using the MVVMbasics
Set method to update a data binding property from within a Viewmodel, from version 2.1 on the
PropertyChanged event raising mechanism is automatically invoked using the dispatcher if currently not running on the UI thread, which means that it is not necessary to wrap property assignments in the above-mentioned
RunOnMainThread method – this is done automatically by the MVVMbasics framework!