Using MVVM |Android Jetpack

Ashish Rawat
MindOrks
Published in
6 min readApr 12, 2019

Model–View–ViewModel (MVVM) is a software architectural pattern which facilitates separation of development UI (Activity or Fragment) from the development of the business logic or back-end logic (the data model).

What is Architectural Pattern

An Architectural Pattern is a general, reusable solution to a commonly occurring problem in software architecture. Architectural patterns are similar to Software Design Patterns but have a broader scope. The architectural patterns address various issues such as computer hardware performance limitations, high availability, and minimization of business risk.

An architectural style defines a family of systems in terms of a pattern of structural organization; a vocabulary of components and connectors, with constraints on how they can be combined.

What is MVVM

MVVM stands for Model View ViewModel and it is an architectural pattern for implementing user interfaces.

Why MVVM over MVP

1. 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 a presenter 1:1 relationship.

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

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.

2. Testability

ViewModels are more Unit Test friendly and there is no dependency of the View as they just expose the state and it can be independently tested without requiring the need for testing how data will be consumed.

3. Relationship with View

In MVP, the role of a Presenter is to drive the View changes and at the same time provide data for completing those operations whereas MVVM, the ViewModel only provides the data, whereas the View is responsible for consuming them and does not hold the reference to the View .The ViewModel can also hold logic for processing users input, same as the Presenter .

Inshort ,MVVM gives more separation of concerns, less boilerplate and encourage reactive approach. Additionally, we get officially recommended tools straight from Google, so we can worry less about lifecycle, memory leaks and crashes.

Now let’s talk about MVVM components.

MVVM Components

It consists of three moving parts:

  • Data Model — it abstracts the data source. The ViewModel works with the DataModel to get and save the data. it represents the business objects that encapsulate the data and behavior of the application.
  • ViewModel — it exposes streams of data relevant to the View and provides the data for a specific UI component, such as a fragment or activity, and contains data-handling business logic to communicate with the model.
  • View — the UI that users see and view send and receive the data from the view model

The Repository holds all the business logic of the particular app section in the app.

Implementation

Step 1: Add the Gradle dependencies

  1. To add it to your project, open the project level build.gradle file and add the highlighted line as shown below:

2. Open the build.gradle file for your app or module and add dependencies:

Step 2: Create a Data Source

First of all, you will create a data source for your application if you are using RestAPI you might use Retrofit or Volley for parsing the JSON data and if you are using SQL database you will use Room Database or SQLite.

In our case, we are using Room Database to demonstrate how to set up MVVM.

We have already implemented how Room in our project and if you do not know how to use Room then we have also written an article we project code.

//article link and code

Step 3: Create a Repository

A Repository is basically a wrapper class which contains the business logic of our app.

As we are Using Room database we need to have ApplicationContext and we will write all the database operation here so the person who is working on the UI does not have to worry about any database operations.

We have already created the Repository class here:

In this Repository class, we will write all the DAO operations and access them in the UI through ViewModel.

If you noticed that we have used LiveData above so

LiveData is an observable data holder class. Unlike a regular observable, LiveData is lifecycle-aware, meaning it respects the lifecycle of other app components, such as activities, fragments, or services. This awareness ensures LiveData only updates app component observers that are in an active lifecycle state.

We also have written an article on Using Room with LiveData

Step 4: Create a ViewModel

Now you will create a ViewModel class.

The ViewModelclass allows data to survive configuration changes such as screen rotations.

Why use ViewModel?

The purpose of the ViewModel is to acquire and keep the information that is necessary for an Activity or a Fragment. The Activity or the Fragment should be able to observe changes in the ViewModel. ViewModels usually expose this information via LiveData or Android Data Binding. You can also use any observability construct from your favorite framework.

To know more about ViewModel and how to use it with RoomDatabase we also have written an article on “Using ViewModel with RoomDatabase”

Now create a ViewModel :

We will access the database from the ViewModel because it has two benefits:

  1. It provides abstraction.
  2. ViewModel can handle the lifecycle configurations.

Let’s see the code that we have already written.

Step 4: Use it in UI (Final Step)

If you see the above code, we have instantiated ViewModel class and pass our ViewModel class.

Now we can access the methods we have written in our ViewModel class in our Activity.

View is accessing the dta from ViewModel class and ViewModel is accessing it from Repository class which has all the database operations.

View <-> ViewModel <-> Model

Now you have got an understanding and working of MVVM.

To know how the complete app works on MVVM we have linked Github repository below.

This is a series for Android Jetpack, we will be back with other Android Jetpack Components.

Thanks for reading this article ❤

If I got something wrong? Let me in the comments. I would love to improve.

Clap 👏 If this article helps you.

Connect with me on LinkedIn.

Check my GitHub repositories.

Follow me on Twitter.

--

--