Why to choose MVVM over MVP — Android Architecture

Please don’t get carried away by the image. It's just a curious imagination :D

Architecture????

According to Wikipedia, Software Architecture refers to the high-level structures of a software system, the discipline of creating such structures and 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 the tight coupling of code that even a small change in one portion of code results into changes/bugs in some other part of the code. Reduced reusability eventually leading to copy-pasting lines of codes. Not so test friendly 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, VMI, MVVM etc that are proven to be fruitful in solving the above problems. One can use any approach as long as the 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 do 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..??

An 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. It's a mature pattern and to a certain extent it actually solves the problem but ~ there is always a but ~ not completely.

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

MVP

and simple MVVM looks like

MVVM

Above shown are oversimplified representations of both. Can you spot the difference??

Let's start with few problems that we still face with MVPand how we can leverage MVVM to overcome them. 

Tight Coupling

For each Activity/Fragment (View) we require a Presenter. This is a hardbound rule. Presenter holds the reference to the Activity and Activity Holds the reference to the presenter. 1:1 relationship and that's where the biggest issue lies.

As the complexity of view increases, so does the maintenance and handling of this relationship.

This eventually lead to the 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 interact 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 a 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 the 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 with 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 up to 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, that's 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!!