Application and expansion of MVP model in Ctrip Hotels

Preface

The hotel business department is one of Ctrip's major businesses. Its business logic is complex and its business needs change rapidly. After years of research and development, it has become a project with a huge code scale. How to standardize the code, classify the code according to its function, and write the code to the appropriate place plays an important role in the iteration of the project.

The MVP model is a popular framework model for clients. Ctrip has been exploring the use of this model for related business function development for a long time to improve the standardization and maintainability of the code, and has accumulated certain experience. This article will explore the advantages and disadvantages of this model in actual projects, and introduce Ctrip's thinking and solutions to these problems, as well as the extended model MVCPI based on practical experience.

1. Let’s start with MVC

MVC is already a very mature framework model, and many people even think it is outdated and old-fashioned. In practice, many colleagues complain that MVC makes the code very bloated, especially the Controller can easily become a hodgepodge, and the expected maintainability becomes very fragile. As a result, on the one hand, they hope that a new framework model can solve the current problems, but at the same time, they are somewhat skeptical about the framework model. Can the new framework model really solve the current problems? Will it repeat the same mistakes? Will it be over-designed? Will it fall into a deeper pit? In short, these concerns like "once bitten by a snake, you will be afraid of the rope for ten years" seem reasonable. But no matter what, we need to do our work carefully and patiently.

1.1. Misunderstood MVC

Before the MVP pattern became popular, whether we were conscious or unconscious, we were using the MVC pattern. Taking Android as an example, let's take a look at what MVC looks like.

 public class HotelActivity extends Activity {
      private TextView mNameView;
      private TextView mAddressView;
      private TextView mStarView;
 @Override
      protected void onCreate(Bundle savedInstanceState) {
          super.onCreate(savedInstanceState);
          setContentView(R.layout.activity_main2); 
 
          mNameView = (TextView) findViewById(R.id.hotel_view);
          mAddressView = (TextView) findViewById(R.id.address_view);
          mStarView = (TextView) findViewById(R.id.star_view); 
 
          HotelModel hotel = HotelLoader.loadHotelById(1000); 
 
          mHotelNameView.setText(hotel.hotelName);
          mHotelAddressView.setText(hotel.hotelAdress);
          mHotelStarView.setText(hotel.hotelStar);
 }
 }

The above code summarizes the basic structure of Android MVC. From my experience, many applications have this code style, which is what most people think of as MVC:

• Model：

 Hotel, HotelLoader

• Controller:

 HotelActivity

• View:

 mHotelNameView 
 
 mHotelAddressViewmHotelStarView

Imagine if this interface displays a lot of data, MainActivity will inevitably become very large, just as most people complain. Admittedly, the demo above is an MVC pattern, but it is only from the perspective of the system framework. If you look at it from the perspective of the application framework, it is not. Let's take a look at the correct structure of MVC from the perspective of the application framework:

1.2. The correct posture of MVC

The MVC in the application should be further encapsulated on the system's MVC framework according to the needs of the business itself. In other words, when we declare that we are using the MVC framework mode, it means that our main work is to encapsulate our own MVC components. It should look like the following style:

 public class HotelActivity extends Activity { 
 
    private HotelView mHotelView; 
 
 @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main2);
        mHotelView = (HotelView) findViewById(R.id.hotel_view);
        HotelModel hotel = HotelLoader.loadHotelById(1000);
        mHotelView.setHotel(hotel);
 }
 }

Compared with the previous code, the basic structure is similar, as follows:

• Model：

 Hotel, HotelLoader

• Controller:

 HotelActivity

• View:

 mHotelView

Only the View layer has changed. This is because Model and Controller are relatively easy to understand concepts. When facing any business needs, people can naturally and instinctively encapsulate them (although most engineers can complete the basic encapsulation of the Model, it is undeniable that the design of the Model is crucial and difficult). As for the View, people may think that "it is enough to lay out and display it correctly". But this is the key point: we need to encapsulate the interface in all aspects, including the View. Specifically, a true MVC framework should have the following characteristics:

• The data is encapsulated by the Model
• View binds business entity, view.setXXX
• The Controller does not manage views that are not related to the business.

1.3 Problems with the MVC Model

As mentioned earlier, many people complain that the MVC model makes the Controller bloated. I believe that it is true that the Controller becomes bloated, but it is incorrect to attribute it to the MVC model. This blame should not be placed on MVC, because this argument will lead us to the wrong direction and fail to find the real problem of MVC. Why do I say this? That is because in many cases that I have learned, people do not correctly understand the MVC framework model. For example, if the first model mentioned above is adopted, the Controller will naturally become bloated, but if the second model is adopted, the code and logic of the Controller will also be very clear, at least there will not be so many complaints. Therefore, if you just want to solve the problem of bloated Controller, MVC is enough, no doubt. So what is the problem with MVC? I think only when we have a deep understanding of this problem, we need to consider whether we need to introduce a new framework model and avoid the problems that may arise in the new model.

The main problem of MVC is that the View is strongly dependent on the Model. As a result, many controls are customized according to the business. From the perspective of Android, controls that could have been implemented by a common layout now have to be customized because they need to be bound to the entity model, which leads to a lot of unnecessary duplication of code. Therefore, it is necessary to decouple the View and the Model, and the main idea of ​​MVP is to decouple the View and the Model. Therefore, it is natural to introduce MVP.

2. Android MVP

2.1 Reference Implementation

The MVP reference implementation officially provided by Android has the following general ideas:

1. Abstract the IView interface and standardize the control access method without limiting the specific source of View

 public interface IHotelView { 
 
 public TextView getNameView(); 
 
 public TextView getAddressView(); 
 
 public TextView getStarView(); 
   
 }

2. Abstract the IPresenter interface and define the binding interface between IView and Model

 public interface IHotelPresenter { 
 
 public void setView(IHotelView hotelView); 
  
 public void setData(HotelMotel hotel); 
 
 }

3. The implementation class of IPresenter implements the binding of data and IView and is responsible for related business processing

 public class HotelPresenter implements IHotelPresenter { 
 
  private IHotelView hotelView; 
 
 public void setView(IHotelView hotelView) { 
 
    this.hotelView = hotelView; 
 
 } 
 
 public void setData(HotelModel hotel) { 
 
    hotelView.getNameView().setText(hotel.hotelName); 
 
    hotelView.getAddressView().setText(hotel.hotelAddress); 
 
    hotelView.getStarView().setText(hotel.hotelStart); 
 
 } 
 
 }

4. Activity implements IView, changes its role to View, and weakens the function of Controller

 public class HotelActivity extends Activity implements IHotelView {
 @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main2); 
 
        HotelModel hotel = HotelLoader.loadHotelById(1000);
        IPresenter presenter = new Presenter();
        presenter.setView(this);
        presenter.setData(hotel); 
 
 }
 @Override
 public TextView getNameView() {
 return (TextView)findViewById(R.id.hotel_name_view);
 }
 @Override
 public TextView getAddressView() {
 return (TextView)findViewById(R.id.hotel_address_view);
 }
 @Override
 public TextView getStarView() {
 return (TextView)findViewById(R.id.hotel_address_view);
 }
 }

The main features of the above code can be summarized as follows:

• Interface oriented
• View-Model Decoupling
• Activity role conversion

Based on what we know so far, many applications that use the MVP model are basically not much different from the Android reference implementation, which shows that the application scenarios of this model are also very wide.

2.2 Problems with Android MVP

Although there are already a large number of applications, it is undeniable that this model still has some problems, which are also reflected in Ctrip's use process. For example, there are problems such as context loss, life cycle problems, memory leaks, a large number of custom interfaces, and a long callback chain. These can be summarized as follows:

• When the business is complex, the Activity may become more complex, such as implementing N IViews and writing more template methods.
• When the business is complex, the communication between the roles will become lengthy and complicated, and the callback chain will be too long.
• Presenter handles the business, which makes the business very fragmented. It is impossible to grasp the business as a whole, and it is difficult to answer where a certain business is handled.
• Using Presenter instead of Controller is a dangerous practice, which may cause memory leaks, life cycle synchronization, context loss and other problems.

Let's look at some specific examples based on the following requirement:

The display of the details button requires the server to send a flag control. When it is displayed, clicking it requires requesting a service. When the service returns, a toast prompts the user

 public class HotelPresenter {
    private IHotelView mHotelView;
    private Handler handler = new Handler(getMainLooper());
 public void setData(HotelModel hotelModel) {
 View button = mHotelView.getButtonView();
 int visibility = hotelModel.showButton ? .VISIBLE :GONE;
       button.setVisibility(visibility);
       if (hotelModel.showButton) {
           button.setOnClickListener(new View .OnClickListener() {
 @Override
 public void onClick( View v) {
 sendRequest();
 }
 });
 } 
 
     private void sendRequest() {
 new Thread() {
 public void run() {
                Thread.sleep(15*1000);
                handler.post(new Runnable() {
 public void run() {
                              Toast.makeText(???) // Where   is Context?
 }
 });
 }
 }.start();
 }
 }

The above code shows that HotelPresenter can handle most of the business, but when it comes to using the context at the end, there is a difficulty, because it is impossible to display a Toast without the context.

In order to avoid such embarrassment, the improvement plan is as follows:

 public class HotelPresenter {
     private IHotelView mHotelView;
     private Fragment mFragment;
     private HotelPresenter(Fragment fragment) {
       this.mFragment = fragment;
 }
     private Handler handler = new Handler(Looper.getMainLooper()); 
 
 public void setData(HotelModel hotelModel) {
 View button = mHotelView.getButtonView();
         button.setVisibility(hotelModel.showButton ? VISIBLE :GONE);
         if (hotelModel.showButton) {
               button.setOnClickListener(new View .OnClickListener() {
                      @Override
 public void onClick( View v) {
                             sendRequest();
 }
 });
 }
 } 
 
     private void sendRequest() {
 new Thread() {
 public void run() {
                Thread.sleep(15*1000);
                handler.post(new Runnable() {
 public void run() {
                         Context context = mFragment.getActivity();
 int duration = LENGTH_SHORT;
                         //NullPointerException will occur
 Toast.makeText(context,"Success",duration).show();
 }
 });
 }
 }.start();
 }
 }

In the improved solution, considering the need to use context, a new interface is added to pass in Fragment as context, which can be used when Presenter needs it. However, since the Fragment life cycle changes, it may cause null pointer problems.

So a new problem needs to be solved. There are mainly two ideas. One is to add lifecycle methods to Presenter and call the corresponding lifecycle functions of Presenter in the lifecycle methods of Fragment, but this makes Presenter look like the grandson of Fragment; the other is to admit that Presenter is not suitable to assume the responsibilities of Controller, and provide an interface for external processing; as follows:

 public class HotelPresenter {
       private IHotelView mHotelView;
       private Handler handler = new Handler(Looper.getMainLooper());
 public void setData(HotelModel hotelModel) {
 View button = mHotelView.getButtonView();
           button.setVisibility(hotelModel.showButton ? VISIBLE :GONE);
           if (hotelModel.showButton) {
                button.setOnClickListener(new View .OnClickListener() {
 @Override
 public void onClick( View v) {
                     if (mCallback != null ) {
                          mCallback.onSendButtonClicked();
 }
 });
 }
 } 
 
 public interface Callback {
 public void onSendButtonClicked();
 } 
 
       private Callback mCallback;
 public void setCallback(Callback callback) {
            mCallack = callback;
 }
 }

This solution is very stable and seems to be the best choice. However, customizing interfaces and callbacks is still a bit painful.

3. MVP's extended mode MVCPI

As the above analysis shows, the MVP reference implementation is not a panacea. Ctrip Hotels did not completely adopt the reference implementation, but designed an extension solution based on its own practical experience. We mainly considered the following issues:

• How to define the View interface?
• How to locate the Presenter?
• How to treat Controller?
• How to solve long callback chains?

By thinking about the above problems, we put forward corresponding solutions to avoid the various problems discussed above, and formed the MVCPI framework model of Ctrip Hotels, which has been implemented in multiple business scenarios and achieved relatively satisfactory results. The following is a detailed introduction to the MVCPI model.

3.1、 IView

Unlike the Android reference implementation, we do not use strongly typed interfaces as a way to express Views, but use weakly typed interfaces to define Views. The specific definition is as follows:

 public interface IView {
 //Control used to display the hotel name
 int NAME_VIEW = R.id.name_view;
 //Control used to display the hotel address
 int ADDRESS_VIEW = R.id.address_view;
 //Controls used to display hotel star ratings
 int STAR_VIEW = R.id.star_view;
 //Control used to display the hotel details entrance
 int DETAIL_BUTTON = R.id.detail_button;
 }

The above interface simply describes the sub-control room IDs that the View as a business control needs to have, and does not require a specific implementation class. Therefore, there is no need for the Activity to implement this interface. You only need to declare these IDs in the layout, which greatly simplifies the code.

3.2 Presenter

Different from the reference implementation, we think it is not a good idea to replace the Controller with the Presenter. The Presenter should be a supplement to the Controller, mainly to decouple the View and Model and bind data. The Controller still decides how to handle the business of the control. In addition, the parameter accepted by setView is a general View, not an interface type. The child control is searched internally according to the ID defined by IView. As follows:

 public class CtripHotelPresenter {
 TextView mNameView;
 TextView mAddressView;
 TextView mStarView;
 Button mDetailButton;
 public void setView( View   view ) {
        mNameView = (TextView)mView.findViewById(IView.NAME_VIEW);
        mAddressView = (TextView)mView.findViewById(IView.ADDRESS_VIEW);
        mStarView = (TextView) mView.findViewById(IView.STAR_VIEW);
        mDetailButton = (Button) mView.findViewById(IView.DETAIL_BUTTON);
 }
 public void setData(HotelModel hotel) {
        mNameView.setText(hotel.hotelName);
        mAddressView.setText(hotel.hotelAdress);
        mStarView.setText(hotel.hotelStar);
 int v = hotel.showButton ? View .VISIBLE : View .GONE;
        mDetailButton.setVisibility(v);
 }
 }

3.3 Interactor

Interactor is an extension element we defined, which has no corresponding role in MVP and MVC. To explain its meaning, let's first look at two very common scenarios.

The callback chain is too long

As mentioned above, the Presenter custom interface is a more reasonable choice among many candidate solutions, but compared with MVC, MVP is more likely to have a call and callback relationship as shown above (or even longer). Maintaining this callback chain is usually a headache. From the perspective of View, it is difficult to know what business a certain event has completed in the end, and Acitivity does not know which callbacks to assemble. An unknown new requirement may require adding callbacks to each link in the chain.

The following is another scenario. You can imagine what the callback chain will look like if the above callback solution is adopted.

Interactive Focused Interface

There are several features in this interface:

• Dozens of dynamic interaction requirements,
• Distributed in different modules
• Distributed in nested layers of varying depths

After a large number of version iterations, no matter the product manager, R&D or tester, they are not clear about what the requirements are, what the business logic is, where it is written, etc.

Two conclusions can be drawn from the above two scenarios:

• Troubleshooting is time-consuming
• Adding functions is costly and may cause other problems

In order to solve the above two difficult problems, we introduced Interactor to describe the interaction of the entire interface and solve the above two problems at one stroke. We believe that the interaction model is an important logical unit of a functional module. Compared with the entity model, the interaction model is more abstract and does not attract everyone's attention in most cases, but it does exist like an entity. It is precisely because there is no systematic description of the interaction that the above two prominent problems are caused. Although abstract, the interaction model is very simple in nature and has a similar structure to the entity model. The following is an example:

 public class HotelOrderDetailListeners {
 public   View .OnClickListener mBackListener; // Back button click event listener
 public   View .OnClickListener mShareClickListener; //Share button event listener
 public   View .OnClickListener mConsultClickListener; //Consult button event listener
 …
 }

After analyzing the overall interface, we established the above interaction model. All interactions are registered in the interaction model and managed uniformly by the interaction model, so that the interaction of the entire interface can be controlled at a macro level. Then, all elements on the page share the same interaction model, so that each element no longer needs a custom interface and avoids the need to establish a callback chain. Finally, the Controller is responsible for assembly, which further strengthens the Controller's control capabilities.

3.4、 MVCPI Overview

Finally, let's take a look at the code structure of MVCPI.

1. First, define what user interactions there are in the entire interface. In this example, it is a details button interaction

 public class HotelInteractor {
 //Event handler for clicking details
 public   View .OnClickListener mDetail;
 }

2. When constructing Presenter, the interaction model needs to be passed in. The IView interface is defined internally. The passed View needs to contain the control with the ID defined by it. When bindData is used, the click of the detail button is not processed through the anonymous inner class, but directly references the mDetail defined in the interaction model.

 public class HotelPresenter {
 private View hotelView;
   private HotelInteractor mInteractor;
   private Button mDetailButton; 
 
 public HotelPresenter(HotelInteractor interactor) {
         this.mInteractor = interactor;
 } 
 
 private interface IView {
 int DETAIL= R.id.detail_button;
 …
 }
 public void setView( View hotelView) {
         this.hotelView = hotelView;
         mDetailButton= (Button)findViewById(IView. DETAIL );
 }
 public void setData(HotelModel hotel) {
        if (hotel.showButton) {
             mDetailButton.setVisibility( View .Visibile);
             mDetailButton.setOnClickListener(mInteractor.mDetail);
 }
 }
 }

3. Controller is responsible for the initialization and assembly of various elements of the interface (including the interaction model)

 public class HotelActivity extends Activity {
 @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main2);
        HotelInteractor interactor = new HotelInteractor();
        interactor.mDetail = new View .OnClickListener() {
 public void onClick( View   view ) {
 viewHotelDetail(); //Processing details business;
 }
 };
        HotelModel model= HotelLoader.loadHotelById(1000);
        HotelPresenter presenter = new HotelPresenter (interactor);
 View   view = findViewById(R.id.hotel_view);
        presenter.setView( view );
        presenter.setData(hotel);
 }
 }

IV. Conclusion

Through the introduction and research of MVC and MVP, we found that the relationship between the two is not a relationship of mutual replacement, but a relationship of evolution and improvement. Practice has proved that MVC still has strong vitality, and attempts to replace MVC with MVP will almost always fail. Ctrip, based on the MVC model, combined with the MVP idea, added the MVCPI framework model built by the Interactor element. On the one hand, it separates the data binding logic from the Controller (or View), and on the other hand, it incorporates the control of the interaction model, further strengthening the control ability of the Controller. Whether in terms of code simplicity, maintainability, or scalability, it has great advantages and has certain practical promotion value.

Of course, no framework model is omnipotent, and MVCPI also has its shortcomings. If you have good opinions and suggestions, you are welcome to join us and discuss and promote the development of the framework model.