- Published on
Architecture Pattern: Understanding Android MVC, MVP, MVVM
- Authors
- Name
- Dan Tech
- @dan_0xff
Basically, we can write any style we want as long as the code runs correctly. However, in modern software development, knowing how to write organized code is a prerequisite for determining whether a candidate is suitable for the company's needs.
The evolution of software architecture in Android has also undergone many changes, and currently, the most chosen architecture is MVVM (Model-View-ViewModel). Before diving into MVVM, let me introduce you to the full evolution of this software development.
Model - View - Controller
Model-View-Controller is the oldest architecture in Android programming. In this architecture, the classes of a feature are divided into 3 parts:
- Model: Contains classes responsible for data. Takes on data roles: Query database; update cache; handle network connection
- View: Is Activity, Fragment in Android. Responsible for handling events, drawing the interface, and features for the User.
- Controller: Contains classes responsible for handling the program's logic.
In MVC, the Controller's Lifecycle sticks to the View's Lifecycle. While the Model can have a larger Lifecycle. Typically, the Model will have a Lifecycle equivalent to the Application, while the View and Controller will have Lifecycles corresponding to their Activity and Fragment.
Model - View - Presenter
Model - View - Presenter is an upgraded architecture of MVC. When the Controller is replaced by the Presenter. In this architecture, communication between the Model, View, and Presenter is through an Abstract Layer - which are Interfaces (Some people like to call them Contracts). The purpose of these Abstract Contracts is to predefine the methods needed for the feature, serving as a basis for building it in the Implementations.
The advantage of MVP over MVC is that the written code is easier to test. Both in terms of Manual Test and Unit Test. The reason is that we have Abstract Contracts, so mocking a few components to test the rest is very easy.
From my perspective, MVP is not a breakthrough in software architecture. This is just an improved version of MVC that helps the code written be better Modularized, and follow standards for testable, reliable codes.
The Lifecycle of the Presenter will stick to the View, and the Lifecycle of the Model will also often be at the Application level. This is similar to the MVC model.
Model - View - ViewModel
Model - View - ViewModel is a major upgrade from the two old architectures MVC, MVP. Here, ViewModel is created to replace the Controller or Presenter. However, the biggest difference is that the ViewModel has a larger Lifecycle than its View.
In the old architectures, when the View is Destroyed in cases of Configuration Changes, the Controller and Presenter will also be Destroyed and initialized together, restoring the state.
In MVVM, when the View is Destroyed by Configuration Changes, the ViewModel is still alive and retains the previous states. This helps avoid data loss during the User's use of our Android app.
In addition, when using MVVM, we can combine it with other Android classes: LiveData, SharedFlow, StateFlow, which makes controlling the View easier and more flexible than using the old Presenter. However, for me, this is not a significant impact. Because LiveData, SharedFlow, or StateFlow can all be used in MVC, MVP normally.
For those who want to learn more about specific examples of each type of Architecture Pattern, you can refer to this git repository: https://github.com/dantech0xff/AndroidFundamentalsByDanTech I have compiled all the basic examples for you to understand how to set up a Fragment with each architecture MVC, MVP, MVVM.
Good luck!