Android, MVVM with Clean Code
A sample android application with MVVM and Clean Code architecture
A couple of weeks ago I did an interview for a company that asked me to create a currency converter using Kotlin, as I am quite happy with the final result I decided to post the project on my github and describe the architectural choices here (I think there aren’t too many updated samples on projects using MVVM-Clean Code architectural patterns in a real scenario).
Keep in mind that the project is the result of specific exercise requirements, some choices may seem strange, for example a specific requirement was to retrieve and save the dollar only rate, and calculate the exchange rate using an algorithm.
The project uses the openexchangerate API to retrieve the exchange rate, if you want to use a different key (or the one inside the project has expired), take a look at app/build.gradle, you can change the value there.
What’s inside?
In this project you’ll find
- MVVM and Clean Code architectural pattern, using views-> viewmodels -> usecases -> repositories
- Dependency injection using Hilt
- Room for persistence
- Retrofit for networking
- Coroutines for asynchronous operations
- LiveData and UI states handling for loading/success/error
- Unit testing
Why MVVM with Clean Code?
MVVM is great in android development, it helps separate the views from the business logic (preventing the problem of filling Fragments and Activities with business logic). A disadvantage of MVVM is that in large projects the ViewModel is overloaded with business logic, in such cases MVVM with the Clean Code principles can help to separate responsibilities and keep the project solid and easy to evolve and maintain.
Who is this project for?
- Anyone looking for a way to structure a robust android application that is easy to evolve and maintain
- A quick reference for a MVVM with Clean Code
What is it not?
- A UI/Material Design sample. The interface of the app is deliberately kept simple to focus on architecture.
- A Jetpack Compose sample. I feel more confident using XML layouts and I believe Compose is not mature enough to replace them.
- A real production app, consider it just a showcase of an updated MVVM sample using Clean Code and some cool (jetpack) libraries.
The project in detail
The project can be divided into three layers:
- Presentation
- Domain
- Data
Presentation Layer
The presentation layer contains the View
and ViewModel
objects from MVVM. The views are Activities or Fragments, they must be as simple as possible, if you have any business logic inside the views you need to refactor these classes.
In the sample app the view is the represented by the CurrenciesFragment, this class has only two responsabilities: listen to the user interaction and reflect the changes to the model on UI.
This is a simpler version to show the fragment’s responsabilities:
CurrenciesFragment.kt
ViewModel is a class that is responsible for preparing and managing the data for an Activity or a Fragment. It also handles the communication of the Activity/Fragment with the rest of the application (e.g. calling the business logic classes).
In an Android application the ViewModel can be implemented using the ViewModel Jetpack Library, in our sample app the ViewModel uses a State
pattern, an object responsable to hold a value with its ui state (loading, success, error, empty.)
This is simpler version of app ViewModel and State classes:
CurrenciesViewModel.kt
State.kt
The Domain Layer
The domain layer contains all the use cases
of your application. You can consider the use cases as class responsible of containing the business logic of your application.
In the currency converter project you will find a single class, but keep in mind that a single class should be responsible for a single functionality, so don’t hesitate to create multiple use case classes if your app has different functionality.
Here’s a simpler version of CurrenciesUseCases class:
CurrenciesUseCases.kt
The Data Layer
The data layer contains the repositories
used by the domain layer and the data sources.
In the sample app there are 2 repositories: LocalCurrencyRepository and HttpCurrencyRepository, in a bigger project you should create a repository for each type of data.
Here a simples version of Local and Remote repositories used by the app:
LocalCurrencyRepository.kt
HttpCurrencyRepository.kt
Other important features you can find in the project
LiveData
LiveData is an observable data holder class. The main feature of LiveData is that it’s lifecycle-aware, so you don’t have to worry on what to do during onPause/onStop in order to avoid battery drain or other issues. The LiveData feature is perfect in combo with ViewModel (both are Jetpack libraries). In the sample app you can see LiveData is used within the ViewModel and it’s observed by the fragment in order to update the UI when the data changes.
Dependency Injection
If you don’t know what dependency injection is, please take a look here. For many years i used dependency injection libraries as little as possible because I didn’t like the implementations available in Android environments compared to other solutions (e.g. the wizardry of Spring dependency injection). Nowadays I appreciate Hilt and I happen to use it more and more frequently in my projects.
In the app, HILT is used to inject UseCases, Repositories, and Dao. Take a look at di
package to understand how the objects are provided.
What’s left out?
I am aware I left out some important parts of the project, but I preferred to focus on the architectural parts. In particular, there’s Room configuration and entities, custom exceptions used to handle specific errors, adapters, coroutines, and definitely something else.
If you have questions or doubts regarding the project send me an email or write on my socials.
This article is an extracted from my website: nicolacaferra.dev/posts/2022/20-10-mvvm-clean-code
The source code
You can find the source code here: github.com/nicolacaferra/architecture_sample_currency_converter