Android MVVM pattern

In my last post, I’ve introduced the Android data binding support library which helps to get rid of unnecessary boiler-plate code related to view-model binding. In this post, I’d like to introduce you to the Android MVVM pattern (Model-View-ViewModel) which builds upon data binding functionality and helps to keep the architecture design of your applications clean and its parts clearly decoupled.

With MVVM, the ViewModel retrieves data from the Model when requested by the View via data binding mechanism. This makes Activities and Fragments really lightweight and your code becomes easily testable. Let’s have a look at the Android MVVM pattern in detail now.

Android MVVM pattern

One of the examples in the official documentation to the data binding support library presents a direct binding of properties from User data object to layout attributes. Specifically, this is the example code I want to discuss:

Even though it’s perfectly correct to do syntactically, I’d argue against it. This logic belongs somewhere else than to the layout definition (we’ll soon find out that it belongs to the ViewModel class). Placing it here makes the testing and debugging of your code harder.

A better solution is to adopt an Android MVVM architectural pattern. The MVVM (Model-View-ViewModel) pattern abstracts the state and behaviour of the View, which allows the developer to separate the development of the user interface from the business logic. This is achieved by introducing a ViewModel layer in between the View and Model, that binds to the View and reacts to events.

MVVM diagram (Android MVVM pattern)

The MVVM pattern comprises of three core components, each having a distinct role:

  • Model: Data model representing the application business logic;
  • View: The structure and appearance representation of the displayed content;
  • ViewModel: Object linking the two together which deals with the view logic.

Other architectural patterns for Android development

MVVM is not the only architectural pattern to be used for development in Android. The most commonly used is probably MVC pattern (often not ideally implemented). Another approach gaining popularity lately is MVP which is quite similar to MVVM pattern in a way. Let’s have a look at what’s different about them.

MVC (Model-View-Controller)

MVC approach is quite common in Android development. It requires no additional architectural knowledge. On the other hand, it produces hundreds of lines of code in a single Activity or Fragment — so called God object. The code is messy and unstructured which often leads to bugs and is difficult to test.

The problem with this approach is that the Activity/Fragment classes have access to every other object and every action is done inside of their code. In this case, the Activity/Fragment acts as a Controller (click listeners and other event listeners) and a Model (business logic, connection to DB and REST API) at the same time. View layer is represented by the XML layout files.

MVP (Model-View-Presenter)

An example of a well-though-out architecture approach in Android is the MVP pattern. MVP allows to separate the Presentation layer from the business logic. The application is divided into three layers which can then be tested independently.

The Presenter acts as the middle man between the View and Model. It receives data from the model and returns it in a proper format to the View. It additionally decides what happens upon interaction with the View. The View contains a reference to the Presenter and the only thing it does is calling methods from the Presenter for each interface action (for example a button click). The Model is simply a provider of the data to display.

MVVM: Example application

We shall demonstrate the usage of Android MVVM pattern on the example application from my previous post on data binding. In short, the application displays a list of article items each containing a featured image of the article, its title, excerpt and two buttons navigating to hypothetical article comments and detail.

We modify the project by simplifying the Article model data class and creating a new ViewModel class acting as a bridge between the Model and View. The holding Activity doesn’t change much too:


We implement an adapter for RecyclerView that uses data binding for each of its items.


With the introduction of ViewModel, the Article data model class becomes lighter and loses the View-Model binding logic. Now it’s only a POJO (Plain Old Java Object) with a constructors and getter and setter methods.


The ViewModel class acts here as the middle man and communicates with both Model (in our case Article object) and View (defined by the layout XML file). It implements the Observable interface by extending the BaseObservable class and all the View-Model binding logic has moved into its code from the Article class:

The clearer separation of View and Model layers in Android MVVM pattern can be observed for example in the  getCommentsButtonVisibility method. Previously, the button visibility logic has been a part of the View (defined in XML). Now the visibility is decided upon in ViewModel and can be easily refactored and tested. Additionally, we no longer have to reference the View class as a variable from the layout file.

View (Layout XML files)

The only object the View layer has access to is now the ViewModel. Only through the ViewModel can the View get the data to present to the user. All the view logic (such as the card background colour logic for highlighted articles or button visibility) has been moved to the ViewModel class and View only calls the appropriate methods to get the result to show to the user.


To conclude, if you decide to go with data binding (see my post on Android data binding) and plan to use it in more complex project, using the Android MVVM pattern is definitely the right way to go. It clearly separates the View and Model layers by introducing the ViewModel middle-man containing the view logic. Not only does the code become better structured, but it will also be much easier to test.

Here, you can download the whole example application project.


Share this:

Follow me: