Well, before discussing MVVM or other design patterns. First, why do we need these design patterns, and what is a design pattern?
Design Pattern is a way you code your project
Let's say you are building a project and you want to make sure that as your project grows most effectively in a most effective way or either you want to reduce the complexity in your code base then you are probably looking for a design pattern and maybe you need it to use it.
You don't need to add design patterns in simple applications, in that case working with data and views should be fine.
Also if you are just getting started with the development, you can learn about these further.
- it works on my machine!
The second option, right? it's the same for a design pattern, you can use it to enrich your stuff. The only difference is here you are dealing with English words but while working with a specific design pattern, you deal with your code.
Even though the second option has more letters than the first; in the end, the second option is more readable, and can be used to extend a talk and so.
MVVM is one of the design patterns which makes sense!
- To keep things simple this is what MVVM means:-
MVVM = Model-View-ViewModel
The Model represents the data that should be present in your app/project through multiple classes/objects which you can access through ViewModel later.
Now this data can be retrieved from anywhere it may be from an API, a database, or anything.
Also known as a repository in Android Dev's context.
In the case of model objects/classes, the heart is whatever the data you choose (string, other data, or whatever) as it networks with it.
also known as repository
Shouldn't be aware of anything except data classes in kotlin or other network stuff.
All the business logic should be done here (network or other stuff) from which ViewModel or others can access the data from your "Model".
Your UI for any project is considered as a "View"
If you're working with xml+kotlin || xml+java then XML can be considered as a view here or if you are working with Jetpack Compose then composable functions can be considered as a "view" in this context.
Views never contain data directly, they'll get data from the ViewModel or other.
All the logic which is related to your UI should be only done in this particular layer, if you are working with Jetpack Compose you need to compose your UI-related stuff only in the composable functions.
Should be able to chit-chat with ViewModel to access the data from a ViewModel from which you'll update the UI.
The ViewModel class is designed to store and manage UI-related data in a lifecycle-conscious way. The ViewModel class allows data to survive configuration changes such as screen rotations.
- ViewModel takes care of the data you need for your UI through the Model, it is responsible for the state of the UI.
In the case of ViewModel, its networking(chit-chatting) is with UI and Model.
Make sure that "ViewModel" isn't aware of the UI stuff from which you can access the data from any other UI file(s).
ViewModel should be aware of "Model" || "Repository" from which you can grab the data you want from the "Model" || "Repository" so that UI can grab that data from your ViewModel.
- The Model is only supposed to respond with the result that ViewModel requests.
- UI can access the data from ViewModel and can update the view model data accordingly.
From my experience, MVVM resolves pretty much mess in the code-base. You can get a clear view of what you are doing and what is happening. Working with Retrofit+MVVM would be a great combination, it gives you a lot of flexibility you want while working with the network operations.
MVVM clearly breakdowns the stuff(UI, Logic, Other Stuff) into their respective positions. In general, a less connected project structure with great compatibility for scaling, testing and so.