Attention should be paid when using MVP for Android.

Attention should be paid when using MVP for Android.

• Lifecycle:Because Presenter is created by View, we need to ensure that we fully understand the life cycle of View, especially because it will most likely process state update and asynchronous data. For example, each Presenter should cancel an asynchronous task in View destroyed, or reset it to the original state when the user pauses or restores the View event. Last but not least, when the View has been destroyed and you try to update the View element from the Presenter, always pay attention to the terrible NPEs.

• Keep Views as stupid as possible:Our Views should no longer contain any business-related logic. It should only contain the minimum things of the Android framework inflate and set the View. Any user interaction should be distributed to the Presenter. Based on experience, if your views has any other method to update the UI elements or respond to user-triggered events, You may check their implementations.

• Keep the Presenter as pure as possible:In this regard, you should try to avoid Android-related code in your presenters. Writing pure unit tests for these components without the need to use other testing frameworks such as Robolectric, which is obviously simplified. This is much easier to say than doing it, because you will eventually encounter this situation in some places. For example, you will need a reference of Context to load data and access strings files.