Menu
MVVM and its implementation in Android
Why is it bad to write code without following an architecture?
Writing application code before thinking about an architecture is a really bad idea. Android programming does not make a difference. Everybody who starts creating Android apps begins doing so without following a specific architecture. All the code concerning a screen in the application is written in the corresponding Activity or Fragment. And this is done until the moment when the code gets so messy that it is almost impossible to understand what is happening in it. The result is the so called God classes. A God class is a class containing all the logic specific to a certain task. Speaking in the Android context, if we have a screen which shows for example information about a list of foods, the activity holds all the logic about network request, database calls, user interactions and so on. The class has a dozen of callback methods and the final result is a spaghetti code.
Benefits of using MVVM
Following an architecture has a lot of benefits, the most import of which is the separation of the code. Classes contain code which is related to their role in the application and each class implements a specific business or interface related logic. One of the widely used architectures in creating Android applications is the Model-View-View Model or MVVM. Another great thing about this software architecture is it is working really well with the Android Architecture Components for which we will talk in a next chapter. So the main benefits of using MVVM are:
- Separation of concerns
- Creating applications which are easy to maintain, test and further expand
- Good integration with Android Architecture components
What is MVVM?
As we said MVVM stands for Model-View-View Model. These are the components of the architecture. Each one has a specific role in the architecture and is a set of classes implementing the role of the component they belong to. Below is shown the architecture scheme.
- Model – it is the data in our application. These are classes representing objects that we persist in our database or that we get from network calls to services. It is another name for the domain objects.
- ViewModel – it is a model of the view. The purpose of the ViewModel is to apply any business logic to the Model before exposing it to the View for consumption. This way the View is free of business logic. Its only purpose is to apply UI logic related to user interactions. The ViewModel exposes the data to the View via Observables.
- View – it is the user interface of the application – Activity, Fragment or any class extending the framework’s View class. It observes the data hold in the ViewModel via Observers and when new data is supplied from the ViewModel all the user interface elements holding reference to this data are updated. It holds logic for user interactions like clicks, dragging, rotation of the screen and so on.
The next figure shows the best practices for creating an Android application. We will go in depth in the next chapters for each of these components but for now it is important to notice that each component in the architecture depends only on the component one level below it. For example Activity and Fragment depend on ViewModel. The only exception is the Repository which depends on both the Model and the remote service.
Letzte Beiträge
Share :
Share :
Weitere Beiträge
LiveData
LiveData is an observable data holder class. It is also lifecycle-aware, which means that it respects the lifecycle of the other app components, such as activities, fragments and services. It notifies only active observers, represented by the Observer class.
Repository in Android’s MVVM architecture
Repository is a class which purpose is to provide a clean API for accessing data. What that means is that the Repository can gather data from different data sources(different REST APIs, cache, local database storage) and it provides this data to the rest of the app.
View Model. Example
In this article we will go through the steps of creating a simple game screen. We will make it the traditional way without using View Model and we will see why it is absolutely wrong to persist data in the View.
