On the interpretation of Android official MVP architecture

overview

The MVP (Model View Presenter) architecture evolved from the famous MVC (model view controller) architecture. For the development of Android applications, it can be regarded as an MVC architecture. In general, XML files are regarded as the view role in MVC and activity as the controller role in MVC. However, in more cases, in practical application development, activity can not fully act as a controller, but a combination of controller and view. Therefore, the activity is responsible for both the display of the view and the processing of the business logic. In this way, the code in the activity reaches thousands of lines, even thousands of lines are not enough. At the same time, such an activity also appears bloated. Therefore, MVC architecture is not very suitable for Android development. Let's introduce the MVP architecture and take a look at the MVP architecture example officially given by Google.

Introduction to MVP architecture

For an application, we need to abstract all levels of it, and in the MVP architecture, it isolates the UI interface and data, so our application is divided into three levels.

Let's take a look at the relationship between various levels in MVP through the MVP structure diagram.

In MVP architecture, these three layers are abstracted into their respective interfaces. The layers are isolated through interfaces, and the presenter's interdependence on view and model also depends on their respective interfaces. This conforms to the principle of interface isolation, which is interface oriented programming. A view interface is included in the presenter layer and depends on the model interface to connect the model layer with the view layer. For the view layer, a presenter member variable will be held and only calls to the presenter interface will be reserved. The specific business logic will be handled by the presenter interface implementation class.

Analysis of official MVP architecture

Project introduction

We have some understanding of MVP architecture, and at the front-end time, Google has given some implementations of app development architecture.

The project address is: https://github.com/googlesamples/android-architecture.

Enter readme here to see the implementation of Android development architecture given by Google this time.

The implementation of the above five development architectures represents the projects completed so far, while the following two represent the projects in progress. Now let's first introduce these architectures.

From the above introduction, we can see that the implementation of all official architectures is ultimately based on MVP architecture. Therefore, the above basic MVP architecture todo MVP is analyzed here.

Analysis of project structure

For this project, it implements the function of a memo. For unfinished tasks in the work, add them to the to-do list. We can mark the completed tasks in the list, enter the task details page to modify the task content, and make statistics on the number of completed tasks and unfinished tasks.

First, let's take a look at the overall project structure of todo MVP

As can be seen from the above figure, the project as a whole includes one app SRC directory and four test directories. Under the SRC directory, the code is organized by function. This project contains four functions: add edit task, statistics of task completion, task detail, and tasks list display. For the data package, it is the data source in the project, performs the reading and writing of the database, and stores the network request operations in the package. It is also the model layer in the MVP architecture. Under the util package are the tool classes used in some projects. Two interfaces basepresenter and baseview are stored in the outermost layer. They are the base classes of presenter layer interface and view layer interface. All presenter interfaces and view layer interfaces in the project inherit from these two interfaces.

Now enter the function module to see how classes are divided within the module. Under each function module, the classes are divided into xxactivity, xxfragment, xxpresenter and xxcontract. It is these classes that constitute the presenter layer and view layer in the project. Let's analyze how to implement MVP architecture in this project.

Implementation of MVP architecture

Here, we only pay attention to the implementation of MVP architecture from the macro perspective, and do not analyze the internal details of the code in detail. Then let's take the function of adding and editing tasks to see how the Android official implements the MVP architecture.

Implementation of model layer

First, we start from the innermost layer of MVP architecture, that is, the corresponding model layer. The contents under the corresponding data package in this project. Encapsulation of some data sources such as database under data. The tasksdatasource interface is provided for the presenter layer. Take a look at the tasksdatasource interface here.

The implementation of the tasksdatasource interface is taskslocaldatasource. The methods in tasksdatasource are the operations of adding, deleting, modifying and querying the database. In the two internal interfaces of tasksdatasource, loadtaskscallback and gettaskcallback are the callback interfaces of the model layer. Their real implementation is in the presenter layer. For the post change after successfully obtaining the data, or pass the data to the presenter layer through this callback interface. Similarly, if the acquisition fails, the presenter layer will also be notified through the callback interface. Let's take a look at the implementation class of tasksdatasource.

Here we add and edit functions for tasks, so we omit a lot of code. You can see the gettask method implemented in taskslocaldatasource. In this method, you pass in the gettaskcallback callback interface in tasksdatasource. In the implementation of the getTask method, we can see that after callback to Task, callback method is invoked. If these two callbacks are implemented in the Presenter layer, the data will be passed to the Presenter layer. When the queried task is empty, the corresponding operation is also performed through the callback method.

Similarly, the same is true for the data obtained through the network request. For the data successfully requested, the data can be transferred to the presenter layer through the callback method. For the failure of the network request, the corresponding operations can also be performed through the callback method.

Interface provided by presenter and view layer

Since the interfaces provided in the presenter and view layers are in the same class, let's first check which interfaces they provide externally. First, look at the two base class interfaces basepresenter and baseview.

BasePresenter

There is only one start method in basepresenter. The general task of this method is to obtain data from the model layer in the presenter and call the view interface to display. This method is usually invoked in the onResume method in Fragment.

BaseView

There is only one setpresenter method in baseview, and there will be a presenter object for the view layer. Setpresenter initializes the presenter in the view.

AddEditTaskContract

In the MVP architecture officially given by Android, the forms of presenter interface and view interface are different from what we usually see on the Internet. Here, the presenter interface and the view interface are placed in the addedittaskcontract class. In this way, we can more clearly see the functions in the presenter layer and view layer, which is convenient for our future maintenance. Let's take a look at the addedittaskcontract class.

It is clear here that some data display operations are handled in the view layer, while tasks are saved and updated in the presenter layer.

Implementation of presenter layer

Let's take a look at how it is implemented in presenter.

Here you can see that in addedittaskpresenter, it not only implements its own presenter interface, but also implements the callback interface of gettaskcallback. The presenter also contains the tasksrepository object of tasksdatasource in the model layer and the maddtaskview object of addedittaskcontract.view in the view layer. Therefore, the presenter is responsible for the processing of the whole business logic.

As can be seen from the presenter's business processing, first call the gettask method of the model layer interface to query the task through taskid. After the task is queried, gettaskcallback is implemented in the presenter layer due to the callback interface of the model layer. At this time, the task object is obtained through the ontaskloaded method in the presenter layer. Finally, the data is displayed by calling the view layer interface.

Implementation of view layer

The view is implemented in the fragment, while the activity completes the addition of the fragment and the creation of the presenter. Let's first look at the addedittaskactivity class.

The functions provided by the activity are also very simple. First, create a fragment object and add it to the activity. Then create the presenter object and pass the fragment, that is, view, to the presenter.

Let's take a look at the implementation of view, that is, fragment.

In this case, the source code is not posted too much. In the fragment, get the presenter object through setpresenter. And realize business processing by calling methods in presenter. In fragment, it is just some operations on the UI. In this way, the code of fragment type is much reduced and the logic is clearer.

We notice that the implementation of the view layer is done through fragments. Why use fragment instead of activity for the implementation of view. Let's see how the official explains it.

The separation between Activity and Fragment fits nicely with this implementation of MVP: the Activity is the overall controller that creates and connects views and presenters.

Tablet layout or screens with multiple views take advantage of the Fragments framework.

Here, the official gives two explanations for the reasons for adopting fragment.

summary

Through the use of MVP architecture, we can see that the responsibilities between various levels are more single and clear, and the coupling degree of code is reduced to a great extent. For the official MVP architecture examples, Google also made it clear that these architecture examples given by them are only for reference, not a standard. Therefore, there is more room for expansion of the basic MVP architecture. For example, synthesize the examples given by Google. We can build a clean architecture by using dagger2, rxjava, etc. on the basis of MVP architecture. It is also a good choice.

The above is the whole content of this article. I hope it will be helpful to your study, and I hope you can support programming tips.