Nowadays when you start writing a new android application, there are a lot of architectural patterns you can apply. This article briefly describes pro and cons of the two most popular approaches(MVP, MVVM) and one underrated pattern called MVPVM.

MVP

Model-View-Presenter

Model contains general business logic.

Presenter is responsible for basic presentation logic, for handling user screen interactions, for routing, for updating view and it’s also responsible for calling right model method.

View represents UI. It updates UI whenever presenter requests that and it delegates all user interactions to a presenter.

Pros

it is testable

view state is separated from a presenter state

you have full control of the view. It’s easy to command view to scroll to something or to focus on something, and it looks naturally

Cons

not friendly with android lifecycle

a lot of boilerplate in fragment/activity code to set and get user input

MVVM

Model-View-ViewModel

Model contains general business logic.

ViewModel is responsible for basic presentation logic, for exposing View state, for handling user screen interactions, for routing and it’s also responsible for calling right model method. The main difference from a MVP presenter is that it doesn’t have any reference to a view, so it can update view only by changing its fields that are bound to View.

View represents UI. It updates UI whenever a ViewModel is changed and gets updated whenever a ViewModel is changed(by means of databinding framework), also it delegates all user interactions to a ViewModel.

Pros

it is testable

friendly with android lifecycle

less boilerplate code for getting/setting user input

View components are easy to reuse with <include /> tag

Cons

ViewModel can contain View state next to presentation business state, so it might get messy

it is not convenient to make view scroll to some position or to focus on some field

MVPVM

Model-View-Presenter-ViewModel

MVPVM

This approach combines MVP and MVVM concepts.

Model contains general business logic.

ViewModel is a simple data class with no behavior, it’s responsible for representing the current view state.

Presenter updates view by changing a ViewModel, also presenter gets notifications about user click events(or other gestures). It has a reference to a view, so presenter can easily call some view actions which are not easy to implement with MVVM (like hideKeyboard). It contains all the presentation logic and presentation business state(like if we load all items in the list or if user is allowed to perform some basic operations on the screen)

View is the same as it is in MVVM approach.

Pros

it is testable

less boilerplate code for getting/setting user input

View components are easy to reuse with <include /> tag

friendly with android lifecycle

View state is separated from presenter state -> less coupling for both sides

you have some control of the view. It’s potentially possible to command view to scroll to something or to focus on something, show/hide keyboard, etc.

Cons

there are not a lot of samples with such approach

Which approach do you prefer?