Android

Deep Dive into MVVM Architecture Components

A simple guide to understand various components of MVVM Architecture in Android

I had directly jumped from MVC to MVVM, so it was quite difficult for me to understand the usage of different components in this architecture. You can also find many useful resources that can tell you how to start with the architecture but they all were quite bound to the code.

So in this article, we will be talking about various components of MVVM architecture. I will not be talking much into code but will provide you a clear image of the components which are used in it. If you are familiar with the MVVM architecture then you can skip this article. Meanwhile, you can check out the advanced topics in Android from the list below:

Machine Learning With CameraX and MLKit

Jetpack Compose: Part 1 — Design

CameraX: HDR, Night and Portrait mode

Don’t like reading much? Check out the video!

We should always start with the basics when it comes to understanding any concept, not only in terms of coding. So, before starting with the architecture let us first understand the architecture.

What is an Architecture?

Architecture is both the process and the product of planning, designing, and constructing structures. In simple language, we can say it as A complex or carefully designed structure of something is an architecture.

Architecture is everywhere. Every building: home, school, office, hospital, and supermarket they all were designed for their particular purpose.

But, Why do we need an Architecture?

For everything, we build either it is a house, or a building, or maybe some other structure. We always try to design it in such a way that it will be easier for us to use the different components of that structure more easily or efficiently.

Maybe your architecture is efficient right now but what if the structure becomes double in size. Will then your architecture be still efficient as it is now?

With this, we can say that if your structure’s architecture is good, then you will spend very little resources in performing a task in it

Let’s try to understand it with an example.

let’s assume there are two-person A and B and both have a house with a bedroom and a bathroom but the difference is that in A’s house the bathroom is adjacent to the bedroom but in B’s house bathroom is 20 steps away from the bedroom.

So, we can say that there is some architectural drawback in B’s house for which B has to pay the energy of 20 steps each time he has to go the bathroom as compared to A.

MVVM(Model-View-View Model) Architecture

Note: MVVM is not the best architecture available but it is the most recommended one. It may be possible that this architecture will not be as efficient for your app, which depends on the business case but according to Android Developer’s team, in the majority of cases, this is the best architecture.

MVVM Architecture flow

Don’t worry, it’s just a diagram. At the end of this article, you will look more friendly towards it

There are mainly 3 components of MVVM architecture, namely:

1. Activity/Fragment: These are the classes in which we place the different views with which the user interacts. So, this is a UI part or we can say View of this architecture.
2. ViewModel: A ViewModel class is a class where we perform functions either which are related to the business logic or independent of the UI.
   
   But why do we need a ViewModel, I mean that there can another class in which we put our business logic and then use that class in our view (Activity/Fragment).
   
   In the above case, the class will be bound to the View’s lifecycle, and if a case occurs where the view is destroyed by the user’s action or some device event that is out of the developer’s hand. In that case, the data is will be destroyed with that. For example, your app may include a list of users in one of its activities. When the activity is re-created for a configuration change, the new activity has to re-fetch the list of users. To avoid this kind of scenarios, we make use of ViewModel by storing such data in its variables.
3. Repository: In this class, we perform the tasks which are related to the data sources which can be an API or a local DataBase. Since we get the data that flows in the app from the repository, we can say that this our Model.

Model — View — ViewModel

In the diagram above, the Repository is connected with 2 data sources. On the left-hand side, is a Local Database it can be the SQLite , Realm or any other file which is stored locally on the mobile device. On the right-hand side, is the remote APIs with which we fetch the data from the remote server.

To get a more clear view, let’s take an example.

Suppose there is a house with a hall and a kitchen, and there is a water tank above that kitchen. Let’s assume, there is a person sitting in the hall, want some water to drink. So in our example, we get the water from the Water Tank to the kitchen, and then in that kitchen, there is a water purifier that purifies that water, and then after that, the purified water is given to the person.

So in this case, our water tank is the Repository and the water in it is the data. So we get the data from the water tank which is our Repo to the kitchen which is the ViewModel and in that there is a water purifier that purifies that water. So, that water purifier is the business logic, we put the raw data in the business logic and get the required data, and then the purified water is given to the person or we can say the resultant data is provided to the user by showing it in the view.

So…😄 I think you will better understand this example.

In the diagram, the repository is connected with 2 data sources, similarly our water tank is also connected with 2 water sources. One is the local water tank and another is the water supply.

Let’s see how to link these components with each other.

View

View Model

Model

Important Note

Always use a single source of truth, either a database or a remote API in your app. Here, single source of truth means a single source from where you get your data that flows in the app. I will suggest you to use APIs to save or update data in the database and then retrieve the data from DB for app use because if you use both, the DB and the APIs to show the data in the app then there can be a chance where the same data differs at different places and our UIs could be confusing from that.

To avoid this, your repository should designate a data source as the single source of truth for the rest of your app.

Advantages of MVVM Architecture:

With this architecture, it is easier for us to add or remove any functionality because it will not disturb the existing one. And since we have separated the business logic from our UI, it will be easier in making changes in the logic.

We know how the requirement of the business team changes over time.😉

And since our code is decoupled, it will be easier for us to test the app.

If you liked this piece, hit the 👏🏼 on your left and do you know you can hit up to 50 claps?

Thank you for your time, Happy Coding🥳

Connect with me on Twitter or may be on LinkedIn