Shulou(Shulou.com)06/01 Report--

With the expansion of Android application development scale, the client-side business logic is becoming more and more complex, which is no longer a simple data display. Like the component splitting idea adopted when the back-end development encounters a bottleneck, the client also needs to design the architecture, split the view and data, uncouple the modules, and improve the degree of convergence within the modules.

Before we begin, let's start with a PPT diagram for internal sharing:

The above are the problems faced by the author in the process of client development, involving the following four topics:

Architecture Design of Android App: from VM, MVC, MVP to MVVM

Network access to Android App: Retrofit+Okhttp that supports REST, HTTPS and SPDY

Responsive programming for Android App: RxJava/RxAndroid solution

Dependency injection for Android App: Dagger2 and ButterKnife use

This article will start with architecture design and share some of the author's ideas on using MVC, MVP and MVVM in Android development.

I. MVC in the native development of Android

Android native development uses XML files to achieve page layout, and through Java to develop business logic in Activity, this development model has actually adopted the idea of MVC, separating the view and the controller. MVC pattern (Model-view-controller) is a software architecture pattern in software engineering, which divides the software system into three basic parts: Model, View and Controller.

The MVC model, first proposed by Trygve Reenskaug in 1978, is the Xerox Paro Alto Research Center (Xerox).

PARC) A software architecture invented for the programming language Smalltalk in the 1980s. The purpose of MVC mode is to realize a dynamic programming, simplify the subsequent modification and expansion of the program, and make it possible to reuse a certain part of the program. In addition, this mode makes the program structure more intuitive by simplifying the complexity. The software system not only separates the basic parts of itself, but also gives each basic part its due function. Professionals can be grouped by their own expertise:

Controller (Controller)-is responsible for forwarding requests and processing them.

View (View)-the interface designer designs the graphical interface.

Model (Model)-the functions that programmers should have in writing programs (implementing algorithms, etc.), database experts for data management and database design (which can achieve specific functions).

The above content is from Wikipedia.

In Android programming, View corresponds to xml layout file, Model corresponds to entity model (network, database, Imax O), Controller corresponds to Activity business logic, data processing and UI processing. This is shown in the following figure.

But in the actual development process, the function of each XML file purely as View is weak, and Activity is basically the combination of View and Controller, which is not only responsible for the display of the view but also adding control logic, and undertakes a lot of functions, resulting in a large amount of code. All the more appropriate current conventional development should be the View-Model mode, most of which are coordinated by Activity and connected to the processing logic.

II. Transition from MVC to MVP

On pages with slightly more complex business logic, it is easy for Activity to have more than a thousand codes. If the author has just read "how to write unmaintainable code", congratulations on the children's shoes who later took over the code. The next few months will be very sour.

Since Activity has the problem of too much code, you will naturally want to split it. The previous section mentioned that the native development of Android adopts the idea of MVC, but Activity is not a Controller in a standard MVC mode, its primary responsibility is to load the layout of the application and initialize the user interface, and to accept and process operation requests from users, and then respond. As the complexity of the interface and its logic increases, the responsibilities of the Activity class increase so that it becomes bulky and bloated.

MVP is a transition from MVC, and the MVP framework consists of three parts: View is responsible for display, Presenter is responsible for logical processing, and Model provides data. In the transition of Android development from MVC to MVP, the main change is to move the code responsible for business logic in Activity to Presenter. Activity only acts as the View in MVP, responsible for interface initialization and establishing the relationship between interface controls and Presenter.

After this split, Presenter takes on a lot of logical operations and avoids the bloated Activity. The entire architecture is shown in the following figure.

View (Activity) is responsible for responding to user actions and requesting data through methods exposed by Presenter

After obtaining the data, Presenter realizes interface control (showLoading/showUsers) through View (Activity) exposure.

The data of Presenter is obtained through Model. Model includes network, database, Icano and so on.

Model transfers the data to Presenter through callback.

The obvious advantage of adopting MVP is that it avoids the coupling of View and Model in the traditional development mode, and improves the code expansibility, the ability of component reuse, the efficiency of team cooperation and the convenience of unit testing. But there are also some shortcomings, such as:

The data transfer process from Model to Presenter requires callback

View (Activity) needs to hold a reference to Presenter, while Presenter also needs to hold a reference to View (Activity), which increases the complexity of control.

The code of Activity in MVC is very bloated, and it is transferred to Presenter of MVP, which also makes the code of Presenter bloated when the business logic is complex.

From Presenter to ViewModel

MVVM is the abbreviation of Model-View-ViewModel. In practice, ViewModel is the combination of View's data model and Presenter. The specific structure is shown in the following figure:

View (view layer) uses XML file to describe the interface

Model (model layer) obtains the data needed by the view layer through the network and the local database.

ViewModel (View-Model layer) is responsible for the communication between View and Model, thus separating the view from the data.

The bidirectional binding of view and data is realized between View and Model through Android Data Binding technology; ViewModel holds the reference of Model and requests data through the method of Model; after obtaining the data, it returns to ViewModel through Callback (callback). Due to the bi-directional binding of ViewModel and View, the interface can be updated in real time. At the same time, when the input data of the interface changes, due to the two-way binding technology, the data in ViewModel can be updated in real time, which improves the efficiency of data acquisition.

ViewModel is used to solve the problem that View (Activity) and Presenter hold each other's applications in MVP. The interface is driven by data, the operation of the response interface does not need to be transmitted by View (Activity), and the change of data does not need to be realized by Presenter calling View (Activity), which makes the process of data transmission more concise and efficient.

The core supporting technology to realize the MVVM architecture in Android is the open source Data binding technology of Google last year. The idea of this technology is not novel. It was originally proposed by Microsoft and has a mature application in the front-end development. Here is a brief introduction to it.

4. Data Binding in Android

There are two main recommendations for learning Data Binding:

Official Data Binding tutorial

Proficient in Android Data Binding

The basic content of Data Binding has been described in detail in these two articles. Here are only two pits encountered in practice.

The get method of ObservableField may not be able to return the content of the real-time update of the interface

Public ObservableField username = new ObservableField ()

The above username represents the user name and may be bound to EditText on the interface. The EditText display can be set through the set method of username, but if the input is changed, the data of the interface may not be returned in time through the get method.

Data Binding still has a lot of poor components (listview,recyclerView, etc.) that are supported, and it is not possible to bind ViewModel to all components so that Activity has no business logic operation. In addition, after ViewModel gets the data, it is not possible to bind all the data directly to the interface, and some of it needs to be passed to Activity through callback.

From MVC, MVP to MVVM, it is actually a process of separation of model and view. The model and view in MVC are not completely separated, resulting in bloated Activity code, Presenter is used to transfer the model and view in MVP, and the model and view are completely separated, but the code is not elegant because V and P refer to each other. ViewModel implements the binding of views and data through Data Binding, which solves the defects of this kind of MVP, but there is also a problem that Data Binding is not yet mature.

In fact, MVC, MVP and MVVM are not absolutely good or bad, and there is no need to either or in the software programming process. The most important thing is to make the software highly cohesive, low-coupling, maintainable and extensible. As for the architecture, choose it according to the actual situation.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.