50 Android development skills (20 using MVP Mode)

I. MVP introduction as the functions of the UI creation technology are increasingly enhanced, the UI Layer is also fulfilling more and more responsibilities. To better segment the View and Model functions, let the View focus on data visualization and interaction with users, and let the Model process data only, the Model-View-Presenter Model was created based on the MVC concept. In MVP mode, there are usually four elements: (1) View: draws the UI elements and interacts with users (represented as Activity in Android); (2) View interface: interfaces that require View implementation. View interacts with Presenter through View interface to reduce coupling and facilitate unit test. (3) Model: stores, retrieves, and operates data (sometimes a Model interface is used to reduce coupling). (4) Presenter: acts as an intermediate link between View and Model interaction, responsible for processing the interaction logic with users. (Original address: http://blog.csdn.net/vector_yi/article/details/24719873)
Ii. Why is the MVP mode used in Android development? Activity is not a Controller in the standard MVC mode. Its primary responsibility is to load the application layout and initialize the user interface, accept and process operation requests from users, and then respond. As the complexity of the interface and its logic increases, the responsibilities of the Activity class increase, resulting in a huge bloated. When we move the complex logic processing to another class (Presneter), the Activity is actually the View in MVP mode, which is responsible for UI element initialization, establish the association between the UI element and the Presenter (such as Listener), and process some simple logic by yourself (complicated logic is handled by the Presenter ). in addition, how do you perform unit tests on the Code logic when developing Android applications? Do I need to deploy the application to the Android simulator or real machine every time, and then test the application by simulating user operations? However, due to the features of the Android platform, each deployment takes a lot of time, which directly reduces the development efficiency. In MVP mode, the Presenter that processes complex logic interacts with the View (Activity) through interfaces. What does this mean? It means that we can implement this interface through a custom class to simulate the Activity behavior and perform unit tests on the Presenter, saving a lot of time for deployment and testing.
Iii. Similarities and Differences between MVP and MVC the MVC and MVP modes have been applied for many years as a development mode used to separate the UI Layer from the business layer. When selecting a development mode, we first need to understand the advantages and disadvantages of this mode: No matter MVC or MVP mode, there is inevitably a drawback: Extra Code complexity and learning costs. As a result, these two development modes may not be very small applications. But compared with their advantages, this disadvantage can basically be ignored: (1) reducing Coupling Degree (2) obvious division of modules (3) conducive to test-driven development (4) code reuse (5) hide data (6) code flexibility
There are also great differences between MVPs and MVC. There are some programmers who choose not to use any mode, and some reasons may be that they cannot distinguish between the two modes. The following are the key differences between the two models: (reference: http://www.infragistics.com/community/blogs/todd_snyder/archive/2007/10/17/mvc-or-mvp-pattern-whats-the-difference.aspx) MVP mode:

• The View does not directly interact with the Model, but indirectly interacts with the Model by interacting with the Presenter.
• The interaction between Presenter and View is performed through interfaces, which is more conducive to adding unit tests.
• The View and Presenter are usually one-to-one, but complicated views may be bound to multiple presenters to process logic.

MVC mode:

• View can interact directly with the Model
• The Controller is behavior-based and can be shared by multiple views.
• You can decide which View to display.

4. The example of using MVP for Android development demonstrates so many theories that it is now time to practice. Now we can implement a Demo () on Android: You can read and access user information from EditText, or read and Display User information from the background based on the ID.

The page layout is very simple. The following code is based on the MVP principle: first, let's look at the directory structure of the java file:
We can find that Presenter interacts with Model and View through interfaces, which reduces coupling and facilitates unit testing.

(1) first, we need a UserBean to save user information.

  public class UserBean {       private String mFirstName ;       private String mLastName ;       public UserBean (String firstName, String lastName) {             this .mFirstName = firstName;             this .mLastName = lastName;       }       public String getFirstName() {             return mFirstName ;       }       public String getLastName() {             return mLastName ;       }}

(2) Let's take a look at the View interface: according to the requirements, View can read the three edittexts: ID, FirstName, and LastName, and write the FirstName and LastName, the IUserView interface is defined as follows:

public interface IUserView {       int getID();       String getFristName();       String getLastName();       void setFirstName (String firstName);       void setLastName (String lastName);}

(3) Model interface: Similarly, the Model also needs to perform read and write operations on the three fields and store them in a certain carrier (this is not our concern, memory, file, database, or remote server can exist, but it has no impact on Presenter and View.) define the IUserModel interface:

Public interface IUserModel {void setID (int id); void setFirstName (String firstName); void setLastName (String lastName); int getID (); UserBean load (int id ); // read the user information by id and return a UserBean}

(4) Presenter: Now, Presenter can interact with View and Model through interfaces:

Public class UserPresenter {private IUserView mUserView; private IUserModel mUserModel; public UserPresenter (IUserView view) {mUserView = view; mUserModel = new UserModel ();} public void saveUser (int id, string firstName, String lastName) {mUserModel. setID (id); mUserModel. setFirstName (firstName); mUserModel. setLastName (lastName);} public void loadUser (int id) {UserBean user = mUserModel. load (id); mUserrView. setFirstName (user. getFirstName (); // update and display the mUserView by calling the IUserView method. setLastName (user. getLastName ());}}

(5) UserActivity: UserActivity implements the IUserView and View. OnClickListener interfaces. There is also a UserPresenter member variable:

public class UserActivity extends Activity implements OnClickListener ,             IUserView {       private EditText mFirstNameEditText , mLastNameEditText , mIdEditText ;       private Button mSaveButton , mLoadButton ;       private UserPresenter mUserPresenter ;

Override the OnClick method:

@Override       public void onClick(View v) {             // TODO Auto-generated method stub             switch ( v. getId()) {             case R .id .saveButton :                   mUserPresenter .saveUser (getID (), getFristName (),                               getLastName ());                   break ;             case R .id .loadButton :                   mUserPresenter .loadUser (getID ());                   break ;             default :                   break ;             }       }

As you can see, View is only responsible for processing and interacting with users, and throwing all data-related logical operations to the Presenter. After the Presenter calls the Model to process the data, it uses IUserView to update the information displayed by the View.
The remaining methods and UserModel classes of View are not our concerns. If you are interested, you can View them in the source code. Source code here