The MVVM (Model : View : VeiewModel) UI design pattern has been around now for a number of years and is recognised as being an important mechanism in separating the responsibilities of UI from Behaviour from Business data. In particular it provides for effective unit testing of the application in isolation from the UI.
As a brief summary the dependency graph flows like this:
View -> ViewModel -> Model
in that the View knows about the ViewModel but nothing else. The ViewModel has no knowledge of the View, but know about the Model and the Model knows only about itself.
An underlying piece of infrastructure to allow this concept to work is that the View needs to be able to update properties of the ViewModel, and know when these properties update (due to possible changes in the Model). It also follows that the ViewModel needs to be aware of any asynchronous changes to properties in the Model not directly initiated by the ViewModel.
When WPF was released with C# back in 2008 this asynchronous comms between the View and ViewModel was achieved by a feature called Data Binding, which provided for properties on UI controls to be bound to properties on the ViewModel, with the binding being one-way or two-way.
This feature is available within Xamarin Form’s XAML implementation, and the following is a small application that demonstrates this feature. It also utilises ZXing to read bar-codes. Just in case anyone is interested. (Thank you ZXing)
Threads & UI Thread
Single hardest issue to debug is the problem of setting a value in the ViewModel and the change not being recognised or actioned in the UI.
Need to jump back to UI Thread. How? Use the Device global (i.e. Static object). Problem is that using the Device object breaks the MVVM paradigm. More importantly, it makes it almost impossible to Unit Test the ViewModel.
You need to wrap this up in a Service.
Same is true of Navigation.