MVP design pattern is a set of guidelines that if followed, decouples the code for reusability and testability. It divides the application components based on its role, called separation of concern.
Model: It is responsible for handling the data part of the application.
View: It is responsible for laying out the views with specific data on the screen.
Presenter: It is a bridge that connects a Model and a View. It also acts as an instructor to the View.
MVP lays few ground rules for the above mentioned components, as listed below:
A View’s sole responsibility is to draw UI as instructed by the Presenter. It is a dumb part of the application.
View delegates all the user interactions to its Presenter.
The View never communicates with Model directly.
The Presenter is responsible for delegating View’s requirements to Model and instructing View with actions for specific events.
Model is responsible for fetching the data from server, database and file system.
3.5. Comparison to Model View Controller
In the Model View Presenter pattern, the views more separated from the model. The presenter communicates between model and view. This makes it easier to create unit tests Generally there is a one to one mapping between view and Presenter, but it is also possible to use multiple presenters for complex views.
In the Model View Controller pattern the controllers are behavior based and can share multiple views. View can communicate directly with the model.
MVVM
Also know as model view binder
The view binds to observable variables and actions exposed by the view model typically using the data binding framework.
The view is responsible for handling for example:
Menus
Permissions
Event listeners
Showing dialogs, Toasts, Snackbars
Working with Android View and Widget
Starting activities
All functionality which is related to the Android Context
4.2. The view model
The view model contains the data required for the view. It is an abstraction of the view and exposes public properties and commands. It uses observable data to notify the view about changes. It also allows to pass events to the model. It is also a value converter from the raw model data to presentation-friendly properties)
The view model has the following responsibilities:
Exposing data
Exposing state (progress, offline, empty, error, etc)
Handling visibility
Input validation
Executing calls to the model
Executing methods in the view
The view model should only know about the application context. the application context can:
Start a service
Bind to a service
Send a broadcast
Register a broadcast receiver
Load resource values
It cannot:
Show a dialog
Start an activity
Inflate a layout
4.3. The model
Contains a data provider and the code to fetch and update the data. The data can be retrieved from different sources, for example:
REST API
Realm db
SQLite db
Handles broadcast
Shared Preferences
Firebase
etc.
Basically the same as the model in the MVP.
4.4. Differences to MVP
MVVM uses data binding and is therefore a more event driven architecture. MVP typically has a one to one mapping between the presenter and the view, while MVVM can map many views to one view model In MVVM the view model has no reference to the view, while in MVP the view knows the presenter.
More info
https://blog.mindorks.com/essential-guide-for-designing-your-android-app-architecture-mvp-part-1-74efaf1cda40
