The new trend in Android right now is the MVVM-Architectural pattern. Now for newbies, MVVM stands for Model-View-ViewModel and is a design pattern for your code structure. Now the question arises: What’s so different about MVVM and Why should I replace my current coding pattern or architecture and move towards MVVM or what magic does it have that other patterns don’t have…We’ll cover it all. So let’s dive into the world of MVVM.

As the name suggests, MVVM has 3 building blocks:

a. Model.
b. View.
c. ViewModel.

So, what does each of these three components in the title mean?


The Model represents the data or state for an entity. Model can be POJO classes  which represent the data retrieved from sources like API or local databases. 

A model is neither tied to the view nor to the controller, which makes it reusable in many contexts. 


View represents the UI displays to the user. It only knows how data needs to be displayed to the users. It only contains Pure UI Logic that only  deals with change of the UIs. 

For Android, Activities and XML files are considered as View components.

The view is responsible for handling: Showing dialogs, Toasts, Snackbars, Menus, Permissions, Event listeners, Working with Android Views and Widgets, Starting activities i.e, all the functionality related to the Android Context.

View Model

The view model contains the data required for the view. It can be said as an abstraction of the view and exposes public properties and commands. 

It uses observable data to notify view about the data changes. It also allows us to pass events to the model. It is used to convert the raw model data to presentation-friendly properties.

View model can be used to do the following work in Android:

Exposing data, Exposing state (progress, offline, empty, error, etc), Handling visibility, Input validation, Executing calls to the model, Executing methods in the view.

The view model can have the application context so it can: Start a service, Bind to a service, Send a broadcast, Register a broadcast receiver etc.

It should not be used to perform any view-related work like displaying a dialog, starting an activity, Inflating a layout etc. View Model should not be tied to the view.

Why should you use MVVM for Android ?

Collaborative working:
By separating the UI from the related code it becomes easy for multiple developers to work on related items at the same time. The idea is to let the designers work on the UI and developers work on the code without needing to have them both work on the same files at the same time.

For large teams, MVVM can be of great use.

Ease of testing
One of the main problems with apps is that they are hard to test.

But as MVVM fully separates the UI and Business logics, testing becomes more accessible. As ViewModel does not contain any UI context, view models can be tested independently.

Ease of maintainability

By having a separation between the different parts of an app’s code it brings a level of uniformity to the code. It becomes easy for other developers to understand the code and make changes. This benefit comes with almost any good architectural pattern that you follow.

Some Drawbacks:

In comparison to MVC or MVP, MVVM seems much more complex to implement so it is harder for developers to adapt.

It may not be the best idea  to use MVVM for small and simple projects 


MVVM pattern is really a great pattern which can be used by collaborative teams. It is also Google’s recommended pattern for Android. So you can surely start building new apps using MVVM. But i would also say that moving your current app’s architecture from MVP/MVC to MVVM might not be a good idea because it may take much of the time.But if time may not be your concern you are good to go.

None of the design patterns will solve all the problems. Each one has its own pros and cons. The Design Pattern to choose from should majorly depend on your project type, size, team size and your needs. 

So fellas, now you know  about MVVM so go Dive into the world of MVVM.