The Presenter layer can provide the View layer with data from the data access layer. In addition, it will also process some background transactions. That is to say, in mvp mode, view only displays the ui, and all business logic processing is placed in the Presenter (through the interface to interact with the Molde, View.
Why is the MVP architecture used for its advantages?
Android Developers now encounter this problem, that is, in a very complicated logic Activity, the amount of code can reach hundreds or even thousands of lines, making the activity look like a view, but it makes some sense to be more like the Controller of mvc. In the end, you will find that "all things are connected together", and the result is a "omnipotent object ".
With MVP
The most different between MVPs and MVC is that M and V are not directly associated, and there is no direct relationship between Model and View. The two are separated by the Presenter layer, it is responsible for controlling the indirect interaction between views and models. The MVP structure is shown below. You can understand this diagram without having to limit it to the following rules, after all, there may be some discrepancies in different scenarios. In Android, the most important thing is that the UI operations basically need to be performed asynchronously, that is, in MainThread, to operate the UI. Therefore, it is reasonable to disconnect the View and Model. In addition, the interaction between Presenter and View and Model can be further achieved through the interface definition interaction operation, or through the interface for more convenient unit testing.
MVP DEMO
Here is a simple demo. On the main interface, click a button to display the data transmitted by the model layer. The engineering logic is simple, but the touch is small and dirty. First look at the directory structure (for convenience, the project structure is not subcontracted, And the subcontracting will be much more elegant)
CallBack is a CallBack interface that identifies the request data Success or Fail; IModel: Model layer interface IPresenter: Presenter interface IView: interface at the ui Layer (that is, what functions are available on your interface, then your activity implements this interface.) Weather Weathering: There is nothing to say about the two java Beans.
Then let's talk about the specific logic. Since Presenter is used as an intermediate component, it has two functions:
1: Responsible for the functional requests passed on The view Interface, get data at the Model layer 2: Persenter get data at the Model layer (usually through callback ), the data is then transmitted to the View (the data obtained from the View layer is relatively passive and is transmitted by the Presenter)
View the interface requirements: click the button and TextView displays the data transmitted by the model.
First, write the IView interface for this interface:
package com.example.luhuanju.myapplication;/** * Created by luhuanju on 15/10/23. */public interface IView { void showProgress(); void hideProgress(); void showError(); void setWetherInfo(Weather weather);}
Since the Model is responsible for the request data logic, the IModel interface is much easier to write: (you can see that the parameter has a callback interface, which is called back to the Persenter after the Model request data is Success, (Persenter needs to implement this callback Interface ),)
/** * Created by luhuanju on 15/10/23. */public interface IModel { void getInfo(String id,CallBack callBack);}
Therefore, Persenter looks like this:
/** * Created by luhuanju on 15/10/23. */public class PresenterImpl implements IPresenter,CallBack { IView mIView; IModel mIModel; public PresenterImpl(IView view){ mIView=view; mIModel=new ModelImpl(); } @Override public void getInfo(String id) { mIModel.getInfo(id,this); } @Override public void onSuccess(Weather info) { mIView.setWetherInfo(info); } @Override public void Error() { }}
The Model is responsible for requesting relevant network data. I have directly replaced the false data ~, You can use fit to better implement network requests. Let's look at the Model:
/*** Created by luhuanju on 15/10/23. */public class ModelImpl implements IModel {@ Override public void getInfo (String cityNO, final CallBack callBack) {// some fake data is directly simulated ~! // In the normal logic, WeatherInfo = new WeatherInfo (); info. setCity (bei jing); info. setCityid (101); Weather weather = new Weather (); weather. setWeatherinfo (info); // This callback is used to call back the data to the Presenter ~! CallBack. onSuccess (weather );}}
After the Presenter obtains the data called back by the Model, it passes the data to the View through the IView interface to see the Activity:
// You need to implement the IView interface public class MainActivity extends Activity implements IView and View. onClickListener {EditText editText; Button button; TextView textView2; TextView textView; TextView textView3; IPresenter presenter; @ Override protected void onCreate (Bundle savedInstanceState) {super. onCreate (savedInstanceState); setContentView (R. layout. activity_main); init ();} void init () {editText = (EditText) findViewById (R. id. editText); button = (Button) findViewById (R. id. button1); textView = (TextView) findViewById (R. id. textView); textView2 = (TextView) findViewById (R. id. textView2); textView3 = (TextView) findViewById (R. id. textView3); button. setOnClickListener (this); // instantiate Presenter presenter = new PresenterImpl (this) ;}; @ Override public void showProgress () {}@ Override public void hideProgress () {}@ Override public void showError () {}// receives data transmitted by Presenter @ Override public void setWetherInfo (Weather weather) {WeatherInfo = weather. getWeatherinfo (); textView. setText (info. getCity (); textView2.setText (info. getCity (); textView3.setText (info. getCityid () ;}@ Override public void onClick (View view) {int id = view. getId (); switch (id) {case R. id. button1: presenter. getInfo (editText. getText (). toString (). trim (); break ;}}}