Why to choose MVVM over MVP — Android Architecture
Architecture????
According to wikipedia, Software Architecture refers to the high level structures of a software system, the discipline of creating such structures and dah dah and blah blah… we all know what is architecture!!
In simple words, having decided and implementing a specific code architecture or a design pattern is all about solving problems that we developers face from time to time.
Problems
Some common problems like tight coupling of code that even a small change in one portion of code results into changes/bugs in some other part of code. Reduced reusability eventually leading to copy-pasting lines of codes. Not so test friendly etc etc.
Solution
Android itself is written as MVC where Activity is responsible for more or less everything. For simple applications that might be sufficient but as the complexity rises, the amount & level of problems also rises.
There are many different architectural approaches available these days like MVP, FLUX, MVI, MVVM etc that are proven to be fruitful in solving above problems. One can use any approach as long as code is maintainable, we are able to adapt to changes quickly, everything works well, in short a happy developer life.
End Goal
The way I see the big picture here, the end goal is to build things in such a distributed manner that keeps Android related stuff at one place and separates out all other entities that does not require android to run, then to further split apart the non-Android dependent piece as well thereby achieving code modularity, scalability, easy to maintain, test friendly and so on…
The Question ~ Why MVVM..??
Infinite number of talks and articles on architecture patterns and we can agree to this that the most popular and widely adopted amongst the above discussed ones is MVP ~ Model — View — Presenter. There is quite a lot of hype around this and even I appreciate it. Its a mature pattern and to certain extent it actually solves the problem but ~ there is always a but ~ not completely.
We can agree that nothing is perfect and there is always a scope for betterment.
MVP is mature, amazing yet Google introduced Android Architecture Components which included ViewModel rather than Presenter and hence the proof that even Google is supporting MVVM.
There must be something not right with MVP!!
A simple no nonsense MVP looks like
and simple MVVM looks like
Above shown are over simplified representations of both. Can you spot the difference??
Lets start with few problems that we still face with MVP and how we can leverage MVVM to overcome them.
Tight Coupling
For each Activity/Fragment (View) we require a Presenter. This is a hard bound rule. Presenter holds the reference to the Activity and Activity Holds the reference to presenter. 1:1 relationship and thats where the biggest issue lies.
As the complexity of view increases, so does the maintenance and handling of this relationship.
This eventually lead to same issue we faced earlier as in for quick changes in design, we actually need to modify the whole relationship.
Picking a statement from our end goal “Build things in a distributed manner”, In order to achieve it and to avoid this tight relationship ViewModels were introduced.
ViewModels are simples classes that interacts with the logic/model layer and just exposes states/data and actually has no idea by whom or how that data will be consumed. Only View(Activity) holds the reference to ViewModel and not vice versa, this solves our tight coupling issue. A single view can hold reference to multiple ViewModels.
Even for complex views we can actually have different ViewModels within same hierarchy.
Testability
Since Presenters are hard bound to Views, writing unit test becomes slightly difficult as there is a dependency of a View.
ViewModels are even more Unit Test friendly as they just expose the state and hence can be independently tested without requiring the need for testing how data will be consumed, In short there is no dependency of the View.
These are two major ones that made the choice clear. There could more or maybe not. Comments below are waiting for it!! 😄
Final Verdict
These architectural patterns are continuously evolving and MVVM has all the caliber or we can say potential to become powerful, useful yet amazing to implement. MVP has already evolved to a certain level but nothing can be perfect.
I also agree that there is a slight learning curve associated to MVVM but eventually it is helping us overcome some shortcomings.
Not sure about the future but as of now “One fit For all solution ~ Silver Bullet” is non-existent and a single pattern may not be sufficient for a requirement. One may or may-not like MVVM and that is purely upto their discretion. As long as we are able to achieve the end goal, nothing else matters.
PS: These are my personal experiences, thoughts and why we preferred MVVM for our project. The intent here is not to compare and find out differences. All I tried is to share my experience with MVP and some shortcomings which can be overcome by MVVM.
If interested I have also prepared a sample project (boilerplate code setup, link below) which implements MVVM using Kotlin, Android Architectural Components, RxJava, Dagger 2. Feedbacks and suggestions will be highly appreciated.
Well thats it for this article. If you like this and think I have done a good job here then please don’t forget to clap. Your appreciation is valuable and keeps me motivated.
Happy Coding, Cheers!!
