Five-minute technical talk | Introduction to common Android development architecture

Part 01

Concept of Architecture

In mobile development, the code is generally divided into three parts: UI logic, business logic, and data operation logic.

The Android architecture is designed to achieve this goal:

1. Reduce the coupling rate between codes, so that the team can clearly divide their tasks and improve development efficiency;

2. Make the code logic clear and improve the readability and maintainability of the code;

3. Reduce duplicate code, improve development efficiency, and avoid reinventing the wheel.

In order to achieve the above goals, many architectures have emerged. Google has also officially launched its own architecture components, using mature frameworks to reduce boilerplate code and improve development efficiency, just like SpringMVC, which is the framework implementation of MVVM. Let's take a brief look at these architectures.

Part 02

MVC

The MVC architecture should be the architecture used by every Android developer for the first time. The View layer is responsible for displaying the page, interacting with the user, and obtaining the user's operation. The Controller is responsible for receiving the user's operation and processing the business logic. The Model layer is responsible for data processing, network requests, and possible local database operations. The essence of MVC is to divide the three modules into three modules according to the different responsibilities of UI logic, business logic, and data logic, and divide the work among them.

In Android development, View is usually represented by XML files. However, due to the lack of XML capabilities, the logic of UI processing is placed in the activity. At the same time, part of the business logic code of the controller is also placed in the activity, where the interaction with the model layer is carried out.

This brings up the problems and drawbacks of the MVC architecture. The activity will contain both our UI and business logic code. As the project grows and the pages become more complex, the code in the activity will become more and more numerous, more and more complex, and difficult to maintain. At the same time, the view directly holds the controller and model instances, and the codes with different responsibilities are coupled, resulting in high code coupling and unclear module division of labor. The functional modules are intertwined, which makes it very difficult to update or deal with some bugs.

At the same time, the advantage of MVC architecture is that we don't need to write a lot of isolation code to decouple. When we face some simple pages and require quick response, it can help us complete them quickly.

From this we can also see the direction in which MVC needs to evolve and improve in the next step:

1. Strengthen the decoupling between view and model to reduce their mutual dependence.

2. Reduce the complexity of the controller and reduce its weight to improve maintainability and readability.

This brings us to the next architecture.

Part 03

MVP

The full name of MVP is Model-View-Presenter. Compared with MVC mode, it has better scalability and maintainability, and the degree of coupling between codes is lower. The View layer is responsible for page display, interaction with users, and obtaining user operations. The Model layer is responsible for data processing, network requests, and possible local database operations. Their responsibilities have not changed. The difference lies in the Presenter: it is responsible for business logic and acts as a bridge between View and Model.

In order to solve the problem of high code coupling in MVC, we extract all business logic and put it into Presenter, so that our Model and View are completely isolated and one-way dependency is achieved. Interfaces are used to communicate between View and Psenter, so that we can divide the modules according to functions or requirements and develop them at the same time. Also, when we need to, we can replace a single module without affecting the operation of other modules on the same page, which is not available in MVC.

It seems that MVP has met our needs, but it also has its own problems. Because in our actual development process, each page will be more or less different, that is, no two pages are exactly the same, which means that each activity needs its own Presenter and supporting interfaces, which requires us to write a lot of code to decouple them. When facing small projects, this affects our development efficiency. At the same time, the problem of bloated controllers still exists, and the degree of decoupling is still not deep enough. Therefore, we will introduce the next architecture.

Part 04

MVVM

MVVM, the full name is Model-View-ViewModel. The View layer is responsible for page display, interaction with users, and obtaining user operations. The Model layer is responsible for data processing, network requests, and possible local database operations. Their responsibilities remain unchanged. ViewModel: Responsible for storing view data images and business logic.

The key point of the MVVM pattern is the viewmodel, which matches the view and the model one by one through binding, and directly displays the data changes on our view, completely abandoning the UI logic operation in the Presenter of MVP. We no longer need to write interfaces separately for communication. The previous business logic is also placed in the viewmodel. This method completely decouples our view from the business, the view focuses on UI operations, and the viewmodel focuses on business operations. This is the idea of ​​data-driven.

To achieve this effect, we also need a simple and easy-to-use framework to help us bind the view and viewmodel and reduce the overly complex business logic operations in the viewmodel. Therefore, Google officially launched the MVVM framework and the jetpack architecture component library used with it, including: DataBinding, LiveData, ViewModel, Navigation, Lifecycle.

The biggest difference between MVVM and MVC and MVP is that MVVM is data-driven and focuses on page development, more like the architecture officially launched by Google that focuses on mobile development. Unlike the other two, MVVM development requires the existence of pages, which also limits its use to page development. We cannot develop on a plug-in washing machine because there are no data objects and pages.

Part 05

Summarize

From the above introduction, we can find that there is no perfect framework, only the most suitable framework in the scene. The birth of each framework is accompanied by our needs for a special scene or special problems in certain scenes. For example, the problem in Android is the decoupling of UI and business logic. But when we face some small projects, fast requirements or no need for page display, MVVM is obviously not our optimal solution. What we need to learn is to split and understand the requirements and choose the framework that best suits our project.