Let’s face it: mobile is taking over the world. Today, there are around 3.5 billion global smartphone users, which translates to nearly 45% of the world’s population owning a smartphone. As one would expect, the ubiquity and popularity of smartphones have opened up a thriving business marketplace of mobile app development, which has emerged as one of the most exciting and interesting fields of work in the 21st century.
Like other domains, mobile app development presents its own set of challenges such as future extensibility and resilience (less prone to crashes). If you are a seasoned mobile app developer or even someone who is just starting out, do you often face the same struggle where a difference in architecture could determine overall success?
If your answer is “yes”, you’ve come to the right place. As a mobile app development professional with 9 years of experience and a track record of delivering over 25 diverse mobile applications to date, I will be sharing about two commonly used mobile app architectural design patterns: MVP & MVVM. In this article, we will discover how we can use them and the benefits they can bring in mobile app development.
Why Design Patterns Matter?
A good question, indeed! As per Wikipedia:
“A design pattern is a general, reusable solution to a commonly occurring problem within a given context”.
Mobile app development has recently become a mainstay of modern computing, evolving into a far from straightforward task for software engineers. This is because mobile apps are now targeting more critical domains such as health, banking, m-payments and even military — to name a few.
That is why choosing the right architecture is one of the most important steps before any major software development, as it defines various components of your application, their scope, functionalities and the relations among them.
As a blueprint for the system, software architecture refers to the base structure of a project and the set of rules governing it. It also provides an abstraction to manage the system’s complexity and establish a communication and coordination mechanism among components. To develop any great product, designing effective architecture is paramount and design patterns can help with that.
Design patterns in software development have shown a great correlation in improving software quality. As design patterns are often traditionally used by software developers, we can be certain that they work, have been revised multiple times and probably optimised during implementations.
As we have discussed above, choosing a recognisable and easy-to-follow design pattern is a stepping stone to enriching your mobile app. This brings us to two major architectural design patterns used in mobile apps development: MVP and MVVM.
MVP : Model - View - Presenter
The MVP design pattern is a derivation of the model–view–controller (MVC) architectural pattern. This is a great alternative pattern to its source of inspiration. Let’s take a closer look at each component:
The Model
The Model contains the application data. This data is usually fetched from the network or a local database and split into small, simple classes which the other components can use.
The View
The View component contains the UI part of the application and does not contain any business logic or information about the data. The View component implements an interface used by the Presenter.
The Presenter
As the middleman between the View and the Model, the Presenter contains the business logic and listens to user actions from the View and updates both the Model and the View. It is also responsible for retrieving data from the Model and returning it formatted to the View. With the help of its own interface methods (e.g. hide/showProgressBar, updateData), The Presenter transports the data and thus allows it to be manipulated or transformed into actions to update the View.
It is a best practice for the Presenter to have as few dependencies to the core platform SDK as possible.
The biggest advantage here is that the Presenter allows the View to be more separated from the Model and the Presenter, which lets us change or update the View (UI) with no or minimum impact on business logic in the Presenter.
MVP Architecture & Functioning
MVP provides modularity and follows the single responsibility and interface segregation principles very well thanks to the Presenter. The following diagram demonstrates the flow in MVP design patterns:
To recap, the View is a presentation layer which provides the user interface and listens to user actions. After receiving a user action/interaction, the View handles events and passes it to the Presenter. Based on user intent, the Presenter manipulates the request, processes it either to communicate to the respective Model to retrieve and update data or perform necessary business logic and triggers back the events to update the View through its interface methods.
In MVP, there is generally a “One-To-One” mapping between the View and the Presenter, with the possibility to use multiple Presenters for complex Views. The sequence diagram below explains the flow and relation between M-V-P as described above:
MVVM : Model - View - ViewModel
As per Wikipedia: “The MVVM is a variation of Martin Fowler’s Presentation Model design pattern. It was proposed by Microsoft architects Ken Cooper and Ted Peters specifically to simplify event-driven programming of user interfaces. The pattern was incorporated into Windows Presentation Foundation (WPF) (Microsoft’s .NET graphics system) and Silverlight (WPF’s Internet application derivative). John Gossman, one of Microsoft’s WPF and Silverlight architects, officially announced MVVM on his blog in 2005.”
The Model
The Model refers to the data model of the app. It can also refer to the data access layer which represents the content. The key functionalities of this layer are to expose its data through observables and the View to be decoupled completely from the ViewModel or any other observer/consumer.
The View
Similar to the MVC and MVP patterns, the View stands for UI components (or presentation layer). It updates the UI whenever a ViewModel is changed. To notify View as soon as the ViewModel changes, there are different approaches like dynamic databinding, LiveData or using the observer design pattern (if you are keen to know more about this, please refer to the links). It also delegates all user interactions to the ViewModel.
The ViewModel (VM)
The ViewModel (VM) is responsible for presenting functions, methods and commands to manipulate the state of the View. It also triggers the right Model methods to serve requests to update the View state.
Ideally, the VM shouldn’t hold any reference to the View or more precisely to the application context or instance. It can update the View only by changing the fields that are bound/referred in the View .
This component is designed to store and manage all UI-related data and business logic decisions in a lifecycle-conscious way. The VM also handles the View state management and allows data to survive configuration changes with respect to the View state lifecycle.
This is the component that replaces the Presenter of MVP. The ViewModel makes applications more distributed and loosely coupled from the View, which makes it simple to separate business logic from the View and provides openness to update either UI(View) or business logic from ViewModel. Other benefits for segregating business logic from the View includes much easier unit testing of the application and more flexibility to change the user interface without having to modify other business logic in the code base.
MVVM Architecture & Functioning
In this design pattern, the View and the ViewModel are in a “One-To-Many” relationship, meaning that multiple Views can share a common ViewModel. The diagram below shows the relation and flow in MVVM components:
To recap, the View provides an interface to the user, lets them interact with the application and listens to the user action. It then captures user action and passes it to the ViewModel for manipulation and keeps observing the ViewModel for updates/callbacks.
The ViewModel processes the request and calls the respective Model to retrieve or update data. The Model is responsible for data operation and can communicate with either a local database or web server for application data. Next, the application data server responds back to the Model, which finally transforms plain application data into the desired format and notifies the change to the ViewModel. As soon as the ViewModel gets updated data, the respective fields bound to the View will get updated and trigger the View to update itself.
The sequence diagram below explains the flow and the relation between M-V-VM:
Key Difference Between MVP and MVVM
So far we have introduced the MVP and MVVM methodologies of mobile app design patterns. But what is the main difference between these two design patterns?
In short, the MVP Presenter uses traditional interface callback methods to update the View, Presenters sit at the same level as Views listening to events from both the View and Model and mediating the actions between them. On the other hand, MVVM uses dynamic data binding or observable pattern which makes it a more event-driven architecture as compared to MVP.
MVP or MVVM? That Is The Question
There is probably an infinite number of discussions and articles on design patterns. But based on my personal experiences, the most popular and widely adopted one is MVVM.
Firstly, it overcomes some shortcomings of MVP. For instance, the Presenter in the MVP is tightly coupled to View and requires a huge amount of interfaces for interaction between layers. As each interface covers only a small fraction of the interaction, this may make it more tedious to implement. The code size is also quite excessive which makes it a bit complex.
Another consideration hinges on dynamic data-binding. When it is possible to use dynamic data-binding, most developers prefer using MVVM as there are less interfaces and code to maintain. The ViewModel is very easy to use and has proven very effective along with data-binding. Conversely, MVP might be suitable when you are unable to use dynamic data-binding. (Windows Forms is a good example). Google has also introduced ViewModel as their own lifecycle-aware Android Architecture Components as part of Android Jetpack, which shows that MVVM is recommended for Android applications.
Conclusion
In today’s tech-driven consumer landscape where sustainable mobile apps have become critical to how we function, design patterns can greatly enhance the application codebase with a modular approach and significantly future-proof many issues with mobile app development. As a final verdict, I would recommend the MVVM design pattern as it makes code cleaner and easier to maintain with your teams — no matter the platform.
References
1.https://en.wikipedia.org/wiki/Software_design_pattern
2.https://en.wikipedia.org/wiki/Modelviewviewmodel
3.https://en.wikipedia.org/wiki/Modelviewpresenter
4.https://developer.android.com/topic/libraries/architecture/viewmodel
5.https://en.wikipedia.org/wiki/Software_architecture
6.https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel
