2 MVP

MVP stands for model-view-presenter and is a interface software architecture pattern. Although this pattern rooted in older GUI development frameworks, it has become very popular in the Android community. It helps to solve the common difficulties in developing Android apps by enabling better maintainability and possibilities of testing the code. It is based on the idea of separation of concerns. It reduces the Android framework to the user interface classes (Activities and Fragments) and allows you to test the other parts of your app without taking account of the Android specific logic.

2.1 MVP Components

model

• an interface that defines the data which will be shown or processed

view

• activity or fragment in the Android SDK
• passive user interface
• only shows data
• can not directly access the model
• has a reference to the presenter
• forwards actions (e.g. user inputs or lifecyle changes) to the presenter

presenter

• acts between the view and the model
• updates and receives data from the model
• prepares and formats data
• has a reference to the view
• triggers view updates

2.2 Advantages

• makes unit test much easier
• view / ui is mostly passiv and doesn't require tests
• code can be testet without mocking the Android SDK
• improves maintainability
• allows background processes to run independent from the Android lifecycle events

2.3 MVP variants

There are variations within the the MVP pattern. They mostly relate to the responsibilities of the view. The definition of a strictly Passive View removes all the update behavior from the view class, including simple cases. This results in extra programming, but gives you the possibility to precisely test your presentation behavior. The opposite would be an Autonomous View implementation, where the view stores all presentation states and behaviors. There is no right or wrong, most likely you will end up with something between to allow good test coverage bust also keep simple ui logic out of the presenter.