In the previous posts we were dsicussing about DoodleBlue Android Interview Questions with Answers – PART 1, PART 2, PART 3, PART 4. In this last post on this topic , we are going to discuss about MVP and MVVM architectures in Andoid.
What is MVP and MVVM in Android?
The most popular architecture choices in Android are;
A. Model View Presenter (MVP)
B. Model View View Model (MVVM) together with Android Data Binding
First of all, what is architecture in Android?….These Android default templates boost the creation of large activities or fragments. These components typically contain both business and UI logic to improve performance and efficiency in the app execution and implementation of reuse in the application design.Let us discuss the architecture choices briefly;
A.The Model View Presenter architecture for Android:
The MVP architecture pattern improve the app architecture to increase testability. In MVP pattern, A presentor seperates the data model.
The following demonstrates an example data flow in MVP,
1.The view –
The visual part of the app is found in this component. It consists of the UI and not any other logic or knowledge of the data shown. The view component in MVP exports an interface that is used by the Presenter in common exercise. The interface methods are used to shape the view by the presentor.
2.The presenter –
The business logic is set off by the presentor and it tells the view when to update. It communicate with the model and fetches and alter data from the model to update the view.
3.The model –
It contains the data provider and the code to fetch and update the data. The update of the database or communication with the user is done in this part of MVP.
4.Considerations for using the MVP design pattern –
The testing of presentor logic and replacement of dependencies is made easier by MVP. One of the drawbacks of using this is that it makes your app code longer and also not everey Android developer will find this code structure easy to understand.
5.Comparison to Model View Controller –
The views are more seperated from the model in the MVP pattern. The communication between the model and the view makes creation unit tests easier. There is also possibility of using multiple presentors for complex views rather one to one mapping between view and Presenter. The controllers are behavior based and can share multiple views in this view and can directly communicate with the model.
MVP is one of the patterns that the Android community prefers.
B.The Model View View Model architecture for Android:
This is also known as ‘Model View Binder’. This view is primarily used when views are created using WPF technology. MVVM uses data binding and generally has a one to one mapping between the presentor and the view.
The following depicts the work pattern of MVVM,
1. The view –
The view part in MVP has visual part of the app. The view combines to observable variables and actions exposed by the view model usually by by using the data binding framework.
The following are handled by View;
=>Showing dialogs, Toasts, Snackbars
=>Working with Android View and Widget
2. The view model –
The data required for the view is contained in the view model. It is an abstraction of the view and reveals public properties and commands. Observable data is used to announce the view regarding the changes. It also allows to pass events to the model and acts as a value converter from the raw model data to presentation-friendly attributes.
Its basic responsibilites are as follows;
=>Exposing state (progress, offline, empty, error, etc)
=>Executing calls to the model
=>Executing methods in the view
3. The model –
It contains the data provider and the code to fetch and update the data. The data can be recovered from various sources, for example:
Differences between MVP and MVVM in Android:
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.
Evidently, architectural patterns evolve. MVVM has the tendency to become a really neat and apprehensive tool. Meanwhile, MVP pattern is flexible enough already benefiting from various libraries.
What is also clear is that you do not have to stick strictly with MVP or MVVM. In most cases we can not build an app purely on a single pattern, and that’s fine. The main things is to separate the view, the model and the logic between them.