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
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?
