MVP architecture in Android development

Recently, more and more people have started talking about architecture. So have my colleagues and engineers. Although I don't have a deep understanding of MVP and DDD, we decided to build our new project through MVP.

This article is a summary of my research and study of various articles and special discussions. It includes the following points:

• Why are more and more people starting to pay attention to architecture?
• First of all, what is MVP?
• Which architecture is the best, MVC, MVVM or MVP?
• Pros and Cons of MVP
• Show me the code!!!

Unfortunately, this article will not cover:

• Detailed and vivid code examples
• How to write test code

***, I will tell you how to study these topics further.

By the way, I gave a talk about MVP architecture at a local seminar last week. This post is pretty much the same as the talk.

Introduction ~ Activity is the God class ~

First, let's think about why a clear software architecture is so urgent in Android development.

This paragraph is excerpted from "Code Complete Second Edition":

Avoid creating god classes. Avoid creating omniscient, omnipotent god classes. If a class needs to spend time retrieving data from other classes via Get() and Set() (that is, it needs to go deep into the business and tell them what to do), then these functions should be better organized in other classes rather than in the god class. (Riel 1996)

God classes are expensive to maintain, hard to understand what is going on, and difficult to test and extend, which is why it is a golden rule to avoid creating God classes.

However, in Android development, if you don't consider the architecture, the Activity class will tend to become larger and larger. This is because Android allows Views and other threads to coexist in the Activity. In fact, the biggest problem is that business logic and UI logic coexist in the Activity. This will increase the cost of testing and maintenance.

Activity is God

This is one of the reasons why a clear architecture is needed. Not only will it cause the Activity to become bloated, but it will also cause other problems, such as complicating the life cycle of Activity and Fragment, as well as data binding.

What is MVP?

MVP stands for Model, View and Presenter.

• The View layer is responsible for handling user events and displaying the view part. In Android, it may be an Activity or Fragment class.
• The Model layer is responsible for accessing data, which can be a remote Server API, a local database, or a SharedPreference.
• The Presenter layer is the bridge connecting (or adapting) View and Model.

The following diagram is one of the patterns based on MVP architecture. View is the UI thread. Presenter is the adapter between View and Model. UseCase or Domain is in the Model layer and is responsible for getting or loading data from entities. The dependency rules are as follows:

The Dependency Injection

The key is that the high-level interface does not know the details of the low-level interface, or more accurately, the high-level interface cannot, should not, and must not know the details of the low-level interface, is (oriented towards) abstraction, and is detail-hiding.

The higher interfaces do not know about the details of the lower ones

Dependency rules?

Uncle Bob's "The Clean Architecture" describes what the rules for dependencies are.

Concentric circles divide the software into different areas. Generally, as the level goes deeper, the level of the software becomes higher. The outer circle is the implementation mechanism, and the inner circle is the core strategy.

Here is the summary of the above article:

Enitities:

• Can be an object holding method functions
• Can be a set of data structures or method functions
• It is not important as long as it can be used by different applications in the project

Use Cases

• Contains application-specific business rules
• Carefully orchestrate the flow of data into or out of an Entity
• Direct the Entity to directly use the business rules within the project scope to achieve the goal of the Use Case

Presenters Controllers

• Convert the data in Use Case and Entity into the most convenient format
• External systems, such as databases or web pages, can easily use this data
• MVC architecture that fully includes the GUI

External Interfaces, UI, DB

• All the details
• Such as database details, web framework details, etc.

MVC, MVP or MVVM?

So which one is the best? Which one is better than the others? Can I choose just one?

The answer is, NO.

The motivation behind all these patterns is the same. That is how to avoid cluttered code, make it easy to perform unit testing, and create high-quality applications. That's it.

Of course, there are more than just these three architectural patterns. And none of them can be a silver bullet. They are just one of the architectural patterns, not the only way to solve the problem. These are just methods and means, not the purpose or goal.

Pros and Cons

OK, let's get back to the MVP architecture. We just learned what MVP is, discussed MVP and other popular architectures, and introduced the differences between MVC, MVP and MVVM. Here is a summary of the pros and cons of the MVP architecture:

**profit

• Testable (TDD)
• Maintainable (code reuse)
• Easy Reviewe
• Information hiding

**Cons

• Redundant, especially for small app development
• (Potentially) additional learning curve
• It takes time before you start writing code (but I bet that designing the architecture is necessary for all project development)

show me the code!!!

This is just a small section of the MVP pattern. If you want to see more projects or live code examples, please refer to the "Links and Resources" at the end of the article. There are very rich and cleverly designed examples, most of which are hosted on Github so that you can clone, run on your device, and understand how it works.

First, define the interface for each View.

 /**
 * Interface classes for the Top   view  
 */
 public interface TopView { 
  
 /**
 * Initialize the view .
 *
     * eg the facade-pattern method for handling all Actionbar settings
 */
 void initViews(); 
  
 /**
     * Open { <a href= "http://www.jobbole.com/members/57845349" > @link</a> DatePickerDialog}
 */
    void openDatePickerDialog(); 
  
 /**
 * Start ListActivity
 */
 void startListActivity();
 }

Let's rewrite the TopView class. The key points are as follows:

• TopActivity is only responsible for handling event monitoring or displaying each view component
• All business logic must be delegated to the Presenter class
• In MVP, View and Presenter are one-to-one (one-to-many in MVVM)

 public class TopActivity extends Activity implements TopView { 
  
  // here we use ButterKnife to inject views
 /**
 * Calendar Title
 */
 @Bind(R.id.calendar_title)
 TextView mCalendarTitle; 
  
  private TopPresenter mTopPresenter; 
  
 @Override
  protected void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      setContentView(R.layout.activity_top);
 ButterKnife.bind(this); 
  
      // Save TopPresenter instance in a meber variable field
      mTopPresenter = new TopPresenter();
      mTopPresenter.onCreate(this);
 } 
  
 /*
   * Overrides method from the { <a href= "http://www.jobbole.com/members/57845349" > @link</a> TopView} interfaces
 */ 
  
 @Override
 public void initViews() {
 // Actionbar settings 
  
 // set event listeners
 } 
  
 @Override
 public void openDatePickerDialog() {
      DatePickerFragment.newInstance().show(getSupportFragmentManager(),
              DatePickerFragment.TAG); 
  
      // do not write logic here... all logic must be passed to the Presenter
      mTopPresenter.updateCalendarDate();
 } 
  
 @Override
 public void startListActivity() {
      startActivity(new Intent(this, ListActivity.class));
 }
 }

This is the Presenter class. The most important thing is that Presenter is just an adapter bridge connecting View and Model. For example, TopUseCase#saveCalendarDate() hides the details of TopPresenter, and the same is true for TopView. You don't need to care about the data structure or how the business logic works. Therefore, you can perform unit testing on TopUseCase because the business logic is separated from the view layer.

 public class TopPresenter { 
  
 @Nullable
 private TopView mView; 
  
    private TopUseCase mUseCase; 
  
 public TopPresenter() {
      mUseCase = new TopUseCase();
 } 
  
 public void onCreate(@NonNull TopView topView) {
 mView = topView; 
  
        // here you call View 's implemented methods
 mView.initViews();
 } 
  
 public void updateCalendarDate() {
 // do not forget to   return if view instances are   null  
 if (mView == null ) {
 return ;
 } 
  
 // here logic comes
        String dateToDisplay = mUseCase.getDateToDisplay(mContext.getResources());
        mView.updateCalendarDate(dateToDisplay); 
  
        // here you save date , and this logic is hidden in UseCase class
        mUseCase.saveCalendarDate();
 }
 }

Of course, you can still perform unit testing even if the business logic is implemented in the Activity class, but it will be time-consuming and a bit complicated. It may take more time to run the App, instead, you should take advantage of the performance of the testing library, such as Robolectric.

Summarize

There is no silver bullet here, and MVP is just one of the solutions. It can be used in conjunction with other methods and can also be selectively used in different projects.