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.
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
ViewModel can also hold logic for processing users input, same as the
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.
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.
Step 1: Add the Gradle dependencies
- To add it to your project, open the project level
build.gradlefile 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
LiveDatais 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
Using Room Database with LiveData | Android Jetpack
LiveData is an observable data holder, part of the Android Jetpack.
Step 4: Create a ViewModel
Now you will create a ViewModel class.
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”
Using View Model with RoomDatabase
ViewModel is part of the Android Jetpack that is used to handle the lifecycle configurations.
Now create a ViewModel :
We will access the database from the ViewModel because it has two benefits:
- It provides abstraction.
- 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.
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.