Android MVVM Clean Architecture

Avinash Mujja
3 min readDec 30, 2020

What motivated me to write this article despite having a lot of stuff on the internet regarding clean architecture?
A few months back when I want to understand clean architecture, I found a lot of articles on the internet, but those are a bit hard to understand and not clear as well. My main motive would be, it should be easy to understand and simple BTW

Let's jump into it:

There are so many discussions nowadays regarding clean architecture in Android, when your application is growing bigger you need to be more careful to manage it for future developments.

Let's take an example in MVVM, you created a ViewModel, and it performing data fetch operation from the network. I feel it's quite a simple operation and you don't need to bother about architecture here, but think about if your ViewModel doing multiple functionalities like fetch the data from local DB, fetch the data from remote API, insert the data into local DB, update other parts of the database if required based on business criteria, and so on.

How clean architecture solves the above problem?
we will inject 4 different use cases into ViewModel, each use case will perform single responsibility.

PROS:
1. Unit test cases will become easy write and test(will mock data layer in Usecases)
2. Business logic completely decoupled from UI
3. Project structure easy to understand
4. Adding new features will be easy.

CONS:
1. Starting it would be a little confusing, because of different layers of communication
2. There would be a need of creating extra classes.

Clean Architecture

Consist of 3 Layers

Presentation Layer
Domain Layer
Data Layer

Presentation: Activities, Fragment, and Viewmodels comes under this layer, Handles data to the UI and user interactions

Domain(Usecases): Handles business logic, returns the value to Viewmodels. These Usecases follow the single responsibility principle.

Data: Provides data for our app. It is responsible for obtaining data from external sources like local DB, remote API.

invoking different use cases from ViewModel below…

Domain layer: Each use case performing a single operation…

Data layer: Provides the data to the app

Above we used a mapper class to convert the network result object into the required mapper object for use.

Unit Testing:

We will mock the data layer in use cases and will create the mocking mapper object to verify the actual vs expected result to test unit testing.

Used Github open APIs(which are limited to use) to fetch the list of users' data, individual details, and their stats, please feel free to check out from the above link. Please provide your valuable feedback
Note: Still under development….

Thanks for reading the article, Do star the repo if you like it…..

--

--

Avinash Mujja

Software developer @Gojek, Currently experimenting on jetpack compose.