MVC and MVVM

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