As part of my very first blog post, I thought it would be fitting to write yet another introduction to the world of Xamarin and MvvmCross. I was inspired by the N+1 Days of MvvmCross tutorial series and decided to write a tutorial based around an application that I think is actually useful as is. The title of the application is Say Numbers and functionally, it allows people learning English as a second language to practice speaking numbers. In particular, since I live in Japan, I am thinking of Japanese learners. They have an especially hard time since they count by 10,000 instead of 1,000 (so 100,000 in Japanese is actually “ten ten-thousands”). The completed project is here.
Today I am going to talk about the overall architecture of the application, and in subsequent entries I will be discussing each level of the architecture from the bottom to the top, and why things are the way they are. The app adheres to a principle called MVVM (Model, View, View Model). This is a flexible model that decouples the presentation of the app (the view) with the logic (the model) via a brokering agent (the view model). Think of them kind of like a team developing a game. The model is the programmer, the view is the artist, and the view model is the technical artist who runs between the two communicating their needs because they are unable to directly communicate with each other.
This is what MVVM looks like
With the power of this model, it is easy to share more and more of the core code between platforms. Indeed with Xamarin Forms, there is now very little that we cannot share between platforms. Let’s have a look at the layers in more detail.
This is the core business logic of the application. It houses services, which are basically just classes which perform a certain task. These can be implemented at this level, or deferred up to the platform-specific logic, if needed, through a system called Dependency Injection. In short, it means that we only deal with interfaces, and register the implementation at runtime.
This level handles communication between the levels above (View) and below (Model) itself. Views will send a signal to the view model when an interaction takes place, and the view model then takes the appropriate action to update the model. This could be done synchronously or asynchronously. Regardless, when the model is finished with whatever it is doing, it will signal the view model again which will then relay the new state back to the view.
This level handles displaying the user interface to the user. This is all that this level does. Very minimal logic should be performed here. This was more important back when the views were all platform specific, but it is still important now to prevent coupling display with logic.
Stay tuned for part two, where I will discuss the Model section of the app!