Understanding MVVM pattern for Android in 2021
Im almost 100% sure that you've heard the words “MVC”, “MVP”, “MVVM”, “MVI”, Mv whatever 🤷 when you where searching for development resources. In order to understand MVVM we need to go to the basics. (Don't worry I will go straight to the point).
WHAT’S THE PROBLEM?
When we start with android development, we tend to put all our logic inside of our Activities, Fragments, Views, etc.
So at the end, our “views” tend to do more than just render the UI. They now can save data into SharedPreferences, Databases or even making network calls and handle all of this extra tasks in one place.
SOFTWARE DESIGN PATTERNS
A software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design.
Wikipedia
In a very brief resume, that's what a SDP is. If you want you can go deep into it, there are a lot of resources about it.
Ok, we identify the problem and we know we have tools for fix it.
MVVM
The V stands for View which can be an Activity, Fragment or even composables now. The ViewModel stands for our jetpack ViewModel which is a class that can survive configuration changes.
Ok, lets pack it all together, our View subscribe to our ViewModel observables and reacts to any Model changes. Finally! here is our M, the M stands for Model, which is… my model is… 🤔
Wait, who or what is your “Model”? The majority of resources out there told you that your model is the “place” where you obtain the data, is where your repository lives, etc. I think this is wrong, and im gonna tell you why.
This is an extract of this blog from the amazing Iveta Jurčíková
The concept of Model is nothing new. It was first defined by Trygve Reenskaug in 1979 as a part of MVC architecture.
“Model is responsible for representing state, structure, and behaviour of the user’s mental model.”
“A View presents information that it retrieves from one or more model objects.”
“Let the View register with the Model as being a dependent of the Model, and let the Model send appropriate messages to its dependents whenever it changes. “
We ended up with something like this:
Our model should represent the current state of our view, which can be a loading, success, or a failure state. And our view should have to render the UI according to the current state.
SHOW ME THE CODE
Lets assume we have to show a list of movies in our app. We can represent the state like the following class:
What is a OneTimeEvent? It's just a utility class that help us to consume objects only once, for avoid showing snackbars, toast twice when the user comebacks to your screen.
What is a Failure? Is a Sealed class that represents any type of failure. You can use exceptions, strings, etc. Anything that serves to your project in order to notify the user that something went wrong.
Ok, you doing great. Now how the 🤬 should I “render” the view genius?
Easy champ, I got you. Let me explain those 3 methods.
- initView() only initialize the recyclerview adapter.
- collectUiState() collect the uiState Flow. You can use LiveData, it doesn't matter.
- renderUiState(state: MovieListUiState) this is the one in charge to RENDER the UI according the current state.
Hey Chris, and what about my ViewModel? Your ViewModel should be the one that prepares the data (which can come from a repository interface, use case, etc) and use the result of it for modify your State.
And that’s it. Now you know who actually is your Model in your MVVM world.
I’ll be uploading more content in the following days for help you to make a robust android app in 2021. Here is the playground project that will be side to side with the following blogs.
See you later! 👋
