Whether you are in charge, you’re part of a mobile development team, or you are looking for an outsourcing partner that could code your idea, it is important to understand MVVM (Model-View-View-Model). As an architectural pattern, it stands to bring multiple benefits to your app.
In this post I’ll explain the performance of the MVVM Pattern and its functionalities, compared to the popular MVC. It is crucial to fully grasp the complexities of the available presentation patterns, since they function to make the apps easier to test and maintain.
You can implement MVVM in both iOS and Android. This framework ties together the app’s user interface and business logic adding great features including data binding and commands.
A bit of context… MVC pattern
The most common pattern in mobile development is MVC. But… what is MVC? First of all, let me give a quick explanation.
MVC stands for ‘Model-View-Controller’, which is a pattern that separates your mobile application in these 3 layers, where each of them has its own responsibilities:
- Model: The models are classes that represent the business logic of the app, with its properties, getters and setters
- View: The view represents the UI components of the app. For example, on iOS it could be a UIButton, and on Android would be a Relative Layout.
- Controller: It is the intermediary between the Model and the View, and manages how the model should be presented on the View. For example, UI View Controller on iOS, and Activity / Fragment on Android.
Apple encourages iOS developers to follow the MVC pattern, but although it is easy to understand and implement (its learning curve is very low), it has a big problem: it leads to enormous ViewControllers with thousands lines of code that, in the long-term, make it unreadable and difficult to maintain and test. That’s why some people call it Massive View Controller.
But don’t worry, I am here to present you a better alternative. This option may require a little more of an investment, since it might take a little more time to learn and assimilate, but I assure you, all your efforts will bear fruit: say hello to MVVM, or Model-View-ViewModel.
Introduction to MVVM
The MVVM design pattern is similar to the MVC as implemented in iOS, but with some fundamental differences: now the View and the Controller are unified to become the View, and the concept of ViewModel appears, which is where the presentation logic now resides. This decoupling results in thin, flexible, and easy-to-read ViewController classes in iOS, and Activity / Fragment classes in Android.
The relationships between all of the layers of MVVM pattern are simple, and we must follow these strict rules:
- The View has a reference to the ViewModel, never vice-versa
- The ViewModel has a reference to the Model, never vice-versa
Failing to abide by these two rules means we might be implementing MVVM pattern the wrong way.
Data binding
So, if the ViewModel does not have reference to the View, how does it update the UI? The answer is simple: Data Binding. This is the key feature that differentiates MVVM from other patterns.
Data Binding is a method to connect UI elements to observable properties of the ViewModel. iOS does not support bindings by default, but there are some great frameworks out there that make our life easier such as Bond (Swift), ReactiveCocoa (Swift), BIND (Objective-C), and they are all simple to use. You can achieve the same results with KVO (Key-Value Observing), although it is not recommended for developers with no experience on this technique.
If we’re talking about Android, Marshmallow version (2015) introduced a powerful Data Binding library, which is a wink to MVVM adoption and a sign that mobile development is gradually moving towards an MVVM architecture.
MVVM also provides better encapsulation. Business logic and workflows are contained almost exclusively in the ViewModel. The view/view controllers concern themselves only with the UI and know little about the business logic and workflow.
Navigation in MVVM
Navigation can be a challenge in MVVM because in theory, the logic of which View should be on the screen is a responsibility of the ViewModel, but the APIs for actually moving from one screen to another are platform-specific.
However, there are two defined approaches to this problem:
View-First
MVVM states that the ViewModel should know nothing about the View, but that View should be aware of the ViewModel. The obvious way to attach a View and ViewModel, then, is have the View construct its ViewModel and set it to its DataContext.
ViewModel-First
The ViewModel-first approach accepts that a ViewModel shouldn’t know anything about its View, but does not accept that the View should be responsible for constructing the ViewModel. Instead, a third service is responsible for locating the correct View for a given ViewModel, and setting up its DataContext correctly.
Why MVVM?
- Maintainability: Clean separation of different kinds of code make it easier to go into one or several of those more focused parts and make changes without worrying
- Testability: With MVVM each piece of code is more granular and if it is implemented right, your dependences are in separate pieces of code from the parts with the logic that you would like to test
- Extensibility: This also has the ability to replace or add new, similar-acting pieces of code into the right places in the architecture
- Reusability: This makes it easier and cleaner to reuse code over the application, if well architecture is applied
—
MVVM is an excellent pattern that reduces the amount of code on our Views and makes our code cleaner, maintainable, reusable and testable, no matter what platform we’re employing during development.
Also, MVVM makes our life easier by allowing us to make cross-platform apps effortlessly (in Xamarin, for example). Our mobile team loves it since it provides our partners with a high quality code. If you are a developer, we encourage you to try it and we think you will love it too!