ANDROIDMVP's attempt

In Android project development, as functionality continues to iterate, the amount of code often increases and maintenance costs become higher.

As a developer, I am often overwhelmed by the clutter of logic, wondering: what structure simplifies development while reducing maintenance costs?

In the current development of the more respected is the three-tier architecture, the typical representative is the MVP. I would like to share with you the recent understanding and experience of MVP.

All along, the author's understanding of the MVP model in Android is not very thorough, recently read KYMJS's article "using MVP architecture to develop Android applications", there is a sense of clairvoyant, thanks to the author. The author's MVP framework has also been put on GitHub-THEMVP, interested friends can pay more attention to.

As for the individual's understanding, the current divergence of MVP is mainly about the attribution of activity. Most people think that activity belongs to the V-level, but some people think activity belongs to P-layer.

activity belongs to V-level?

Take the landing page for example, two edittext to get the account number and password, a button for landing. Activity first Setcontentview, then add button click Listen, the onclick to get account and password to request, one go. Setcontentview in the process, the button is monitored, and the UI elements need to be manipulated directly. For complex pages, the direct manipulation of the UI elements will be more, and activity as a V-layer has a natural advantage.

activity as P-layer?

There are many callback methods available in the activity, and as a context implementation class, various managers can be invoked through activity. It can be said that most of the logical operations we can think of can be done in the activity, activity also has the potential as P-layer.

Since the activity as a V-layer, p-layer has a certain reason, how should we understand the activity?

activity is omnipotent .

Activity is the God class, and we can do anything in the activity.

Imagine that in a dynamic layout page, we might not need XML to write the layout, and all the controls are code generation. Various events are also handled by the activity, including the file operation. An activity will do the MVP operation, is not very omnipotent?

　　

do we need to use mv* mode?

Only from the author's development experience, the use of mv* mode is not much, most of the cases use the Activity/fragment+model layer.

When we develop an app that is not particularly complex in logic, the code should be easy to maintain and do not have to use mv* mode as long as the abstraction is reasonable.

But with the PM of the odd idea more and more, the larger the project, an activity may be thousands of lines, a variety of logic intertwined, it seems very complex. At this time we can consider to save us through mv*!

In other words, the use of mv* mode itself is a helpless. The business is too complex to divide and conquer complex problems only by splitting the hierarchy.

What kind of activity is more reasonable in the V-layer and P-layer?

Activity because it is too comprehensive, on which floor can be. But just because it is irreplaceable, whatever it is, it needs to be a choice.

As a V-tier, you should place non-UI actions on a custom P-layer. The custom P-layer itself does not have many functions (such as OnDestroy release handler, etc.), which require activity to provide an interface implementation.

As the P-layer, the UI action needs to be placed on a custom V-layer, and the UI-related operations are handled by the V-layer, and the P-layer does not intervene.

I think activity as P-layer is more convenient, and try to use activity as P-layer to achieve a relatively simple and imperfect MVP, for reference only.

Ideas

The M layer is not given, and the P-layer is the PRESENTERADAPTER,V layer that inherits from the activity is a custom viewadapter.

Many of the business processes on the P-tier are reflected on the V-tier, so our activity holds viewadapter.

When the page is more complex, you may need to do a lot of UI processing, viewadapter provide a variety of interfaces to Presenteradapter operation is also more troublesome. We can let p, v hold the same state set info,p modify Info,v to render the UI based on info.

• Presenteradapter holds iview (primarily viewadapter implementation classes) and Baseinfo implementation classes, initializes both, and binds Baseinfo to iview.

1 /**2 * Created by Puff on 2016/1/1.3  */4  Public Abstract classPresenteradapter<textendsIView, UextendsBaseinfo>extendsAppcompatactivityImplementsIpresenter<t, u> {5 6     PrivateT MView;7     PrivateU MInfo;8 9 @OverrideTen     protected voidonCreate (Bundle savedinstancestate) { One         Super. OnCreate (savedinstancestate); A         //Initialize view and info, and associate -MView =Initiview (); -MInfo =initinfo (); the Mview.init (Getlayoutinflater ()); - Mview.setinfo (mInfo); - Setcontentview (Mview.getrootview ()); -     } +  - @Override +      PublicU GetInfo () { A         returnMInfo; at     } -  - @Override -      PublicT GetView () { -         returnMView; -}

• Baseinfo as a state set, each pair of v/p to implement one.

1 /**2 * Created by Puff on 2016/1/1.3  */4  Public classBaseinfo {5     Private BooleanShouldopendialog;6     Private BooleanShouldclosedialog;7     PrivateString DialogTitle;8     PrivateString dialogmessage;9 Ten      Public BooleanIsshouldclosedialog () { One         returnShouldclosedialog; A     } -  -      Public voidSetshouldclosedialog (BooleanShouldclosedialog) { the          This. Shouldclosedialog =Shouldclosedialog; -     } -  -      Public BooleanIsshouldopendialog () { +         returnShouldopendialog; -     } +  A      Public voidSetshouldopendialog (BooleanShouldopendialog) { at          This. Shouldopendialog =Shouldopendialog; -     } -  -      PublicString Getdialogtitle () { -         returnDialogTitle; -     } in  -      Public voidSetdialogtitle (String dialogtitle) { to          This. DialogTitle =DialogTitle; +     } -  the      PublicString getdialogmessage () { *         returnDialogmessage; $     }Panax Notoginseng  -      Public voidsetdialogmessage (String dialogmessage) { the          This. Dialogmessage =Dialogmessage; +     } A}

• Viewadapter implements the IView interface for UI re-rendering each time the activity calls Refreshview

1 /**2 * Created by Puff on 2016/1/1.3  */4  Public Abstract classViewadapter<textendsBaseinfo>ImplementsIview<t> {5     /**6 * Root view, used for view operation7      */8     PrivateView Mrootview;9     /**Ten * Status Set t One * View,presenter through T communication, T Update for refresh A      */ -     PrivateT MInfo; -     /** the * Universal Dialog Shared -      */ -     PrivateProgressDialog Mdialog; -  + @Override -      Public voidInit (Layoutinflater inflater) { +Mrootview =initviews (inflater); A     } at  -     /** - * Materialized View -      * -      * @paramInflater -      * @returnRoot View in      */ -     protected AbstractView initviews (Layoutinflater inflater); to  + @Override -      PublicView Getrootview () { the         returnMrootview; *     } $ Panax Notoginseng @Override -      Public voidRefreshview () { the         if(MInfo = =NULL) { +             return; A         } the         if(Minfo.isshouldopendialog ()) { + ShowDialog (); -Minfo.setshouldopendialog (false); $         } $         if(Minfo.isshouldclosedialog ()) { - Hidedialog (); -Minfo.setshouldclosedialog (false); the         } -     }Wuyi //Other Operations the｝

Through this structure, the author has completed a simple app that can meet the basic needs of development.

Presenteradapter is only for business processing, and the result of business processing is reflected on the state set, which is basically for the data operation. Viewadapter, however, focuses on UI rendering through a state set.

Special cases

Pages that contain adapterview are more complex, because in most cases we need to implement Baseadapter for adapterview data filling.

Baseadapter in fact, and we mention the viewadapter similarities, are the view of the manager, through the data for view rendering. So we can also treat the Baseadapter implementation class as a view layer. Only a list<xx> is needed in the state set for Baseadapter to use.

Remaining issues

There are still a lot of problems with this idea.

Fragment how to deal with it?

Fragment contains many of the functions of the activity, the life cycle is also very complex, in complex applications often appear in a Activity containing multiple Fragment scenes (Activity->viewpager->fragment, This way is very complex, fragment how to deal with, I have not thought of a good way.

Actionbar,decorview this natural presence in the activity of the view how to deal with?

Actionbar can be implemented in other ways, Decorview did not think of any good way.

Setlistener on the P-layer, generally need to pass the r.id, so that the reference to view?

This problem does exist, but it can also be handled via the V-layer interface, but it's a bit cumbersome.

The author level is limited, a lot of problems are not solved, but also only to provide a way of thinking, hope that the garden friends can not hesitate to enlighten, common progress ~

ANDROIDMVP's attempt