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.

MVVM 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.

MVVM in Android application
Share :
Share :

Weitere Beiträge

Room. Reactive queries

Room has great integration with LiveData. Results from SQL queries can be easily wrapped in LiveData container. This way LiveData can be observed in the UI. When the data is changed in the database, all active observers get notified and update the corresponding views.

Weiterlesen »
View in the MVVM architecture

The View component in the MVVM architecture are the UI controllers – Activities and Fragments. They should be as free as possible from any business logic. Their role is to present the data, not to transform it.

Weiterlesen »