Google's official MVP sample code reading notes

Unraveling the project structure

According to international practice, the project structure diagram is as follows:

It is easy to tell the functions from the package name: addedittask is for adding tasks, data is for data management, statistics is for statistics, taskdetail is for task details, tasks is for task browsing, etc. In fact, the key to this project is: Tasks, TaskDetail, AddEditTask, Statistics.

These four key points have something in common:

• Defines the contract between view and presenter
• Activity is responsible for the creation of fragment and presenter
• Fragment implements the view interface
• Presenter implements the presenter interface

In other words, each of the several functions is in the MVP mode, except that the Model layer is shared. And the View layer in this project is all Fragments. Sure enough, Google recommends using Fragments and even gives us a demonstration in its own project... In fact, there is still some controversy about whether to use Fragments. So should we use them? I think for individuals, whether you like it or not, you have to use it and give it a try, because people have to step into pits to grow. For formal projects, you need to comprehensively consider whether the advantages of using Fragments outweigh the disadvantages.

That's a little off topic. Let's take a look at a structure diagram given in his code repository:

You can see that the left side is data management, a typical Model layer. On the right side, you may think that Activity is Presenter, but in fact, Presenter is in Activity, and Fragment is View. At this point, I think the introduction to the structure of this project is enough, and let's look at the code.

I think the correct way to look at an Android project is to play with the app first and see what it does. Here are some pictures of the app:

Next, it’s time to look at the entry Activity. The entry Activity of this project is TasksActivity, and the package it is in is tasks. Let’s see what’s in it:

The first one is the custom View, the second one is the entry Activity, and the third one is the "contract" mentioned above, which contains the View interface and the Presenter interface. TasksFilterType is an enumeration with three filter types: all, in progress, and completed. TasksFragment is the View in MVP, and TasksPresenter is the Presenter in MVP. Take a look at the initialization code in TasksActivity:

  protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.tasks_act);
        Log.e(getClass().getSimpleName(), "onCreate" ); 
 
        // Set up the toolbar.
        Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar);
        setSupportActionBar(toolbar);
        ActionBar ab = getSupportActionBar();
        ab.setHomeAsUpIndicator(R.drawable.ic_menu);
        ab.setDisplayHomeAsUpEnabled( true ); 
 
 /**
 * The following DrawerLayout is not shown for the time being
 */
        // Set up the navigation drawer.
        mDrawerLayout = (DrawerLayout) findViewById(R.id.drawer_layout);
        mDrawerLayout.setStatusBarBackground(R.color.colorPrimaryDark);
        NavigationView navigationView = (NavigationView) findViewById(R.id.nav_view);
        if (navigationView != null ) {
            setupDrawerContent(navigationView);
 } 
 
 // Get the fragment and add it to the view
 // The click event of the floating button set in this taksFragment
        TasksFragment tasksFragment =
                (TasksFragment) getSupportFragmentManager().findFragmentById(R.id.contentFrame);
 // getSupportFragmentManager().findFragmentById()
        if (tasksFragment == null ) {
            // Create the fragment
            tasksFragment = TasksFragment.newInstance();
 // Provide methods to help activity load ui
 // This method actually gets a transaction and then adds the fragment to the corresponding id
            ActivityUtils.addFragmentToActivity(
                    getSupportFragmentManager(), tasksFragment, R.id.contentFrame);
 } 
 
        // Create the presenter
        mTasksPresenter = new TasksPresenter(
                Injection.provideTasksRepository(getApplicationContext()), tasksFragment); 
 
        // Load previously saved state, if available.
        if (savedInstanceState != null ) {
            TasksFilterType currentFiltering =
                    (TasksFilterType) savedInstanceState.getSerializable(CURRENT_FILTERING_KEY);
            mTasksPresenter.setFiltering(currentFiltering);
 }
 }

First, initialize the toolbar and slide. You don't need to go into detail here, so you can skip these two. Then initialize the fragment and presenter. Initializing the fragment first tries to find a possible existing Fragment object by id. If not, create a new Fragment object. The next step is to create a presenter. The last step is to restore data when the application switches between landscape and portrait modes.

Next, let’s look at the “contract” between View and Presenter:

 public interface TasksContract { 
 
    interface View extends BaseView<Presenter> { 
 
        void setLoadingIndicator(boolean active); 
 
        void showTasks(List<Task> tasks); 
 
 void showAddTask(); 
 
        void showTaskDetailsUi(String taskId); 
 
        void showTaskMarkedComplete(); 
 
        void showTaskMarkedActive(); 
 
        void showCompletedTasksCleared(); 
 
        void showLoadingTasksError(); 
 
 void showNoTasks(); 
 
        void showActiveFilterLabel(); 
 
        void showCompletedFilterLabel(); 
 
        void showAllFilterLabel(); 
 
        void showNoActiveTasks(); 
 
        void showNoCompletedTasks(); 
 
        void showSuccessfullySavedMessage(); 
 
 boolean isActive(); 
 
        void showFilteringPopUpMenu();
 } 
 
    interface Presenter extends BasePresenter { 
 
        void result( int requestCode, int resultCode); 
 
        void loadTasks(boolean forceUpdate); 
 
 void addNewTask(); 
 
        void openTaskDetails(@NonNull Task requestedTask); 
 
        void completeTask(@NonNull Task completedTask); 
 
        void activateTask(@NonNull Task activeTask); 
 
        void clearCompletedTasks(); 
 
        void setFiltering(TasksFilterType requestType); 
 
        TasksFilterType getFiltering();
 }
 }

This interface includes View and Presenter. You can see that there are many methods in View and Presenter. In fact, this is as it should be. Because in the MVP architecture, View is only responsible for drawing the UI according to the instructions of Presenter, and View leaves all user interactions to Presenter. Therefore, many methods of Presenter may be the processing of user input, and there must be output if there is input. The various methods defined in the View interface are callbacks to Presenter. Presenter pushes the processing results of user input to View through the callback function, and View updates the UI accordingly based on this result. In this project, Fragment is View, and the corresponding methods of Presenter are called in each click event of Fragment, leaving the business logic to Presenter. This seems to be much better than traditional MVC, because in traditional MVC, Activity can be considered as both Controller and View, and it is difficult to separate responsibilities. When writing later, one Activity may have thousands of lines of code, which will bring a lot of trouble for subsequent maintenance. MVP extracts the business logic into the Presenter, and the responsibility of the Fragment or Activity as the View is more single, which undoubtedly brings convenience to subsequent development and maintenance.

Next, let's look at the initialization of Presenter in detail. The creation of Presenter is completed in TasksActivity. Check its constructor:

 public TasksPresenter(@NonNull TasksRepository tasksRepository, @NonNull TasksContract. View tasksView) {
      mTasksRepository = checkNotNull(tasksRepository, "tasksRepository cannot be null" );
      mTasksView = checkNotNull(tasksView, "tasksView cannot be null!" ); 
 
      mTasksView.setPresenter(this);
 }

The first two check whether the passed parameter is empty, then assign it to the reference in TasksPresenter, call the setPresenter method of view, pass itself in, so that the presenter object can be used in the view, which looks much more elegant than taking it directly from the activity. I won’t look at the specific logic of Presenter, which is all relatively simple code. Let’s review the process of events that occur when opening this app: create TasksActivity -> initialize Toolbar -> initialize side sliding -> create TasksFragment object -> create TaskPresenter object -> set Presenter object for Fragment -> initialize Fragment layout. After this set of processes, the whole process is sorted out, and the next step is just waiting for user input.

The next thing to look at is the Model that has been ignored from the beginning of this article to now: TasksRepository. However, before analyzing TasksRepository, let me introduce the entity class in this project. It is written elegantly, and we can also follow its routine when we write entity classes in normal times. Why do I say that it is written elegantly? Because each attribute or method with a return value is annotated with @Nullable or @NoNull to indicate whether it can be null. In fact, the error of null pointer can be regarded as a common error in normal times... But if you have good design and coding habits, it can be avoided. Bringing these two annotations can give you relevant prompts at compile time. Not only that, this entity class also overrides the equals(), hashCode() and toString() methods, and the implementation method is also in line with the specification. There is a good summary of how to override these three methods in "Effective Java", you can go and read it.

 /*
 * Copyright 2016, The Android Open Source Project
 *
 * Licensed under the Apache License, Version 2.0 (the "License" );
 * you may not use this file except   in compliance with the License.
 * You may obtain a copy of the License at  
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to   in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF   ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and  
 * limitations under the License.
 */ 
 
 package com.example.android.architecture.blueprints.todoapp.data; 
 
 import android.support.annotation.NonNull;
 import android.support.annotation.Nullable; 
 
 import com.google.common.base.Objects;
 import com.google.common.base.Strings; 
 
 import java.util.UUID; 
 
 /**
 * Immutable model class for a Task.
 */
 public final class Task { 
 
 @NonNull
 private final String mId; 
 
 @Nullable
    private final String mTitle; 
 
 @Nullable
    private final String mDescription; 
 
    private final boolean mCompleted; 
 
 /**
     * Use this constructor to   create a new active Task.
 *
     * @param title title of the task
     * @param description description of the task
 */
 public Task(@Nullable String title, @Nullable String description) {
        this(title, description, UUID.randomUUID().toString(), false );
 } 
 
 /**
     * Use this constructor to   create an active Task if the Task already has an id (copy of another
 * Task).
 *
     * @param title title of the task
     * @param description description of the task
     * @param id id of the task
 */
 public Task(@Nullable String title, @Nullable String description, @NonNull String id) {
        this(title, description, id, false );
 } 
 
 /**
     * Use this constructor to   create a new completed Task.
 *
     * @param title title of the task
     * @param description description of the task
     * @param completed true if the task is completed, false if it's active
 */
 public Task(@Nullable String title, @Nullable String description, boolean completed) {
        this(title, description, UUID.randomUUID().toString(), completed);
 } 
 
 /**
     * Use this constructor to specify a completed Task if the Task already has an id (copy of  
 * another Task).
 *
     * @param title title of the task
     * @param description description of the task
     * @param id id of the task
     * @param completed true if the task is completed, false if it's active
 */
 public Task(@Nullable String title, @Nullable String description,
                @NonNull String id, boolean completed) {
 mId = id;
 mTitle = title;
        mDescription = description;
        mCompleted = completed;
 } 
 
 @NonNull
 public String getId() {
 return mId;
 } 
 
 @Nullable
 public String getTitle() {
 return mTitle;
 } 
 
 @Nullable
 public String getTitleForList() {
        if (!Strings.isNullOrEmpty(mTitle)) {
 return mTitle;
 } else {
 return mDescription;
 }
 } 
 
 @Nullable
 public String getDescription() {
 return mDescription;
 } 
 
 public boolean isCompleted() {
 return mCompleted;
 } 
 
 public boolean isActive() {
 return !mCompleted;
 } 
 
 public boolean isEmpty() {
 return Strings.isNullOrEmpty(mTitle) &&
               Strings.isNullOrEmpty(mDescription);
 } 
 
 @Override
 public boolean equals(Object o) {
 if (this == o) return   true ;
        if (o == null || getClass() != o.getClass()) return   false ;
 Task task = (Task) o;
 return Objects.equal(mId, task.mId) &&
               Objects.equal(mTitle, task.mTitle) &&
               Objects.equal(mDescription, task.mDescription);
 } 
 
 @Override
 public   int hashCode() {
 return Objects.hashCode(mId, mTitle, mDescription);
 } 
 
 @Override
 public String toString() {
 return   "Task with title " + mTitle;
 }
 }

First take a look at the structure of the package where TasksRepository is located:

From the package name, we can see that local is to read data locally, and remote is to read data remotely. Of course, this is just a simulation of remote reading. Local uses the database access method. There are two TasksDataSource references in TasksRepository (hereinafter referred to as TR):

 private final TasksDataSource mTasksRemoteDataSource;
  private final TasksDataSource mTasksLocalDataSource;

TasksDataSource is an interface in the data package. The interface reference is used to decouple. Even if the requirements change in the future and you do not want to use the database to store data, as long as this interface is implemented, the internal code of TR does not need to be changed. TR uses a singleton, and the implementation is not thread-safe:

 /**
    * Returns the single instance of this class, creating it if necessary.
 *
    * @param tasksRemoteDataSource the backend data source
    * @param tasksLocalDataSource the device storage data source
    * @ return the {@link TasksRepository} instance
 */
 public   static TasksRepository getInstance(TasksDataSource tasksRemoteDataSource,
                                             TasksDataSource tasksLocalDataSource) {
       if (INSTANCE == null ) {
           INSTANCE = new TasksRepository(tasksRemoteDataSource, tasksLocalDataSource);
 }
 return INSTANCE;
 }

In the end, it doesn't need to be thread-safe. At least in this app, there is no scenario where this object is created concurrently, so it is enough. A LinkedHashMap is used as a container to save Tasks inside TR. Let's take a look at two methods. The first is storage:

 public void saveTask(@NonNull Task task) {
 checkNotNull(task);
       mTasksRemoteDataSource.saveTask(task);
       mTasksLocalDataSource.saveTask(task); 
 
       // Do in memory cache update   to keep the app UI up to   date  
       if (mCachedTasks == null ) {
           mCachedTasks = new LinkedHashMap<>();
 }
       mCachedTasks.put(task.getId(), task);
 }

The incoming task will be stored in the remote data source and the local data source (local database), and then the task will be passed to mCachedTasks (LinkedHashMap). The code is relatively simple, so no further analysis will be done. Next, let's take a look at reading Task:

 public void getTasks(@NonNull final LoadTasksCallback callback) {
       checkNotNull(callback); 
 
       // Respond immediately with cache if available and   not dirty
       if (mCachedTasks != null && !mCacheIsDirty) {
           callback.onTasksLoaded(new ArrayList<>(mCachedTasks. values ​​()));
 return ;
 } 
 
 if (mCacheIsDirty) {
           // If the cache is dirty we need to   fetch new data from the network.
           getTasksFromRemoteDataSource(callback);
 } else {
           // Query the local storage if available. If not , query the network.
           mTasksLocalDataSource.getTasks(new LoadTasksCallback() {
 @Override
 public void onTasksLoaded(List<Task> tasks) {
                   refreshCache(tasks);
                   callback.onTasksLoaded(new ArrayList<>(mCachedTasks. values ​​()));
 } 
 
 @Override
 public void onDataNotAvailable() {
                   getTasksFromRemoteDataSource(callback);
 }
 });
 }
 }

The taskId is the id of the Task that needs to be obtained, and it is also a unique identifier. GetTaskCallback is the interface callback responsible for passing data. The first step is to read data from the memory. The getTaskWithId method is as follows:

 private Task getTaskWithId(@NonNull String id) {
 checkNotNull(id);
       if (mCachedTasks == null || mCachedTasks.isEmpty()) {
 return   null ;
 } else {
 return mCachedTasks.get(id);
 }
 }

The data is read from the LinkedHashMap that stores the task. If the data cannot be read in this process, the data is read from the local data source. If the local data source does not get the data, the data is finally read from the remote data source.

So far, we have briefly gone through this project.

Summary & MVP

The Google sample project has a very clear architecture and a very standard MVP mode. The decoupling is also very good. However, compared to an application with simple functions, the amount of code is still relatively large. Of course, because this is just a small example, it may make people feel that it is not as convenient to develop as ordinary MVC, but a man without long-term plans will inevitably have short-term worries. When we do things, we should try to make long-term plans, otherwise we may be submerged in frequent changes in requirements in the future. There are many things worth learning from this Google project. For example, when we write MVP, we can also use a Contract class to put View and Presenter into it, which is convenient for us to manage (change code).

We all know that the main difference between MVP and MVC is that View and Model do not interact directly, but through Presenter. In this way, View can be modified without affecting Model, realizing the real complete separation of Model and View. In MVP, business logic is extracted and placed in Presenter, making the responsibilities of each module clearer and the hierarchy clearer. And there is also a key point, using MVP architecture makes it easier to unit test the application. Although there are many test frameworks in Android, to be honest, it is difficult to use those frameworks for effective testing without studying them for a period of time. And many tests are difficult to conduct because some need to rely on Android environment or UI environment. If MVP architecture is used, because the View layer is defined by interface, you can completely build a View to simulate the view object yourself, so that our test does not need to rely on UI environment. The biggest advantage of this is that we do not have to spend too much time studying those test frameworks, and we can also write effective unit tests to ensure the quality of our code.

Compared with the advantages of MVP, its disadvantages are also very obvious. It can be seen from this sample code of Google that the code volume is relatively large, and it is troublesome to use it to develop small Android applications. Presenter is responsible for both business logic and the interaction between Model and View. It is inevitable that it will become bloated in the later stage, and it may be difficult to maintain it in the end.

Although MVP still has some shortcomings, it is still easier to write maintainable and testable code than MVC, so you may wish to read this code from Google~