Android Architecture: MVVM, MVP, MVC and why you should care
Every serious Mobile Developer should focus on building a high-quality, maintainable, and performant mobile app. Following a recognizable and easy-to-follow design pattern is a great way to achieve this goal.
When we talk about native android development we have three main candidates architectures, MVC, MVP, and MVVM. It’s tricky to choose the best architecture for your project and your team so this article will discuss the following points to help you understand the architectures in the android development world and how to choose the best one for you.
Why you should care about architectures
Why you should care about architectures
One question that could be asked is Why is it important to choose the correct app architecture? This can be answered from two perspectives; that of the engineer and that of the client. I will start by answering from the perspective of the engineer.
Most engineers are familiar with common architecture patterns. This means that when a new engineer joins a project or a team of engineers takes on an existing project, they can better navigate the project structure and begin work much more quickly and with more confidence that new features can be added without any issues. Additionally, as new features are added it would be obvious which part of the architecture needs to be modified and teams can work together on different layers of the architecture. All of this leads to more stable applications with fewer bugs and better performance overall.
From a client's perspective, there are many reasons why choosing the right application architecture is important. Clients need to be sure that the engineering team they choose to build their application has their best interests in mind, both in terms of quality and efficiency. Software architecture patterns allow for higher levels of quality to be achieved while still maintaining efficiency. There is also no one-size-fits-all architecture that can be applied to every project. For example, a highly complex enterprise-level application would demand a more sophisticated architecture pattern than a simple proof of concept or minimum viable product application. Also, when a project is released and then additional features are required the client can be sure that this process will be as painless as possible.
The Android system and MVC
Android itself is written as MVC where Activity is responsible for more or less everything.MVC is good for simple applications but as the complexity rises, the amount & level of problems also rises. This had led to the introduction of other architectures to the android world like MVVM and MVP but even those two have their downsides.
Android Architecture: MVC
MVC stands for Model View Controller where :
- Model: The model represents the data models (data entities ) and manages their states, also it contains the business logic for the application.
- View: The view is the way we represent the data. For android, it’s the Layout.
- Controller: The controller handles all the user interactions with the app through a communication channel between the model and the view.
The user interacts with the UI, and the controller gets notified via the view. Based on the user interaction the controller modifies certain Models. Models perform some business logic and return the updated model data state to the controller. The controller can then update the UI according to the new data state as received from the Model.
Android Architecture: MVP
MVP stands for Model View Presenter where :
- Model: is the same as MVC.
- View: layouts as well as Activities/Fragments in Android. it should implement an interface for the Presenter’s action
- Presenter: The views invoke the presenter’s action and update their own state through the actions defined in the presenter interface.
Although the Flow diagram looks the same as MVC the difference is how the View and Presenters/Controllers interact with each other.
In MVP the Views and presenters interact via an interface(unlike MVC). Presenters perform some action on the Interface, which is implemented in Views, and hence the view gets updated.
It is far better than MVC as here the presenter has NO ANDROID API (or very little android API) and it can be easily tested.
The views can be tested using espresso etc to see if the views are updated or not.
Thus the views are pretty dumb. They get data from the presenter and updates the UI Components accordingly.
This picture will help understand the presenter’s actions
The view will implement this interface to define how it will be updated when a defined action happens.
Android Architecture: MVVM
MVVM stands for Model View ViewModel, the model and the view are the same as MVC and MVP, ViewModel on the other hand uses live data to observe the model values and update the UI accordingly
What is live data?
This picture illustrates the MVVM flow in android
So the view receives the User interactions and notifies the view model.
Now the ViewModel will update the model as well as the Observable(which will invoke the value change). Next, the ViewModel interface will update the UI.
Comparisons between MVC/MVP/MVVM
As you can see MVVM is more adapted to android cause it allows the ViewModel to be independent of the android API which increases the maintainability.MVVM allows also great modularity thus the application of the SRP principle (single responsibility principle ), which means that you can test the classes cause the business logic is separated from the view. All this makes the project very testable which helps to reduce and find the bugs.
The only downside for MVVM is that it increases the XML complexity cause it’s often used with view binding.
Why MVVM?
The comparison shows that MVVM and MVP are both good for Android and an Infinite number of talks and articles on architecture patterns and we can agree that the most popular and widely adopted amongst the above-discussed ones is MVP.
Yet Google introduced Android Architecture Components which included ViewModel rather than Presenter which means that Google is supporting MVVM and that can’t be just random, there must be something wrong with MVP (wrong for android).
The wrong thing is that MVP requires a presenter for each view means that each activity/fragment has its own presenter. This is a hardbound relationship that affects the simplicity of the presenter cause as the view complexity increases the presenter complexity does as well which makes the maintenance and the tests hard.
On the other hand, MVVM doesn’t require this hard relationship and this makes it more suitable for android development.
Conclusion
At this point, it’s clear that MVC is out and you as a developer or a project owner need to choose between MVVM and MVP based on your requirements, but keep in mind that both MVVM, MVP are continuously evolving and MVVM has all the potential to become powerful and perfect for Android development, useful yet amazing to implement. MVP has already evolved to a certain level but nothing can be perfect.
Finally, I want to mention that this is my personal opinion and you can choose any other architectural pattern, they all proved that they are good to a certain level.
