In this blog, Model View Controller (MVC), Model View Presenter (MVP) and Model View View-model (MVVM) are briefly discussed. We’ll see… what are these design pattern? What impact do they have in our daily coding habits?What are their different use cases? How we can implement these in our Android projects in order to reduce the code complexity in order to make it intelligible. Before moving forward I would like to clarify that all discussion is made in context of Android as a platform. Lets have a look on each pattern one by one:-
MVC(Model View Controller)
I think this is the most widely used approach in Software Development. Model View Controller consist of three main components, around which the whole architecture is revolving.
View:- This component directly interacts with user and is responsible for how user going to see our application. In MVC, Xml is treated as view.
Model:- Model is the data Source for the Application and the main business logic is defined here, it contains data objects that are used in application and is shown to user. Data Source can be Web, local database(sqlite) etc.
Controller:- Here comes the important part of MVC pattern, Controller is the component that manipulates, edit, uses data model and show it to users via View. Controller is responsible for gathering all data and act as middle men between model and view. Activity/Fragments are considered to be Controllers in Android.
All these components interact with each other and perform their specific task. As shown in figure see their interactions among themselves.
It has been noticed that Android is not able to follow the MVC architecture completely, as Activity/Fragment can act as both Controller and view, which makes all the code cluttered at one place. Activity/Fragment can be used to draw multiple views for single screen in app, thus all different data calls and views are populated at the same place. Therefore to solve this problem, we can use different design pattern or can implement MVC carefully by taking care of conventions and following proper programming guidelines.
MVP (Model View Presenter)
Model View Presenter (MVP) is derived from MVC pattern. It is emerging and becoming popular amongst developers. MVP is somewhat able to minimize high dependency on View as it separates view layer from business logic layer by presentation layer. Presentation layer is decides what to be displayed on view. Lets discuss its component individually,
View:- It renders information to users and contains UI Component .Xml file, Activity, fragments, Dialog comes under View Layer.It do not have any other logic implemented.
Model:- Model here too plays role of domain or business layer and is data source of pattern. It describe the main logic of application and decides from where the data should be fetched.
Presenter:- This layer performs the functionality of Controller and act as middle layer between view and model layer. But unlike controller, it is not much dependent on View. View contact presenter for the data to be presented, then Presenter takes data from model and returns to view in presentable format. Presenter is a simple java class that do not contain any UI components, it just manipulates data from model and displays it on view.
It completely depends on mobile architects and approach to a problem that decides how we can implement this pattern, there are whole lot of ways in which this pattern can be implemented but the main idea to loosely couple view/model interaction should be preserved.
Presenter communicates with view through interface. Interface is defined in presenter class, to which it pass the required data. Activity/fragment or any other view component implement this interface and renders the data in a way they want. Changing views can have different Presenter class. The connection between Presenter:View is one to one.
MVVM (Model View View-Model)
Model View View-Model is introduced in last year’s Google I/O.This architectural plan is becoming popular by the features it provides. It mainly implements the Data Binding Framework, it allows for “binding” of views to fields on an arbitrary object. When a field is updated, the framework is notified and the view is updated automatically. The architecture introduces two-way communication between its components. Along with features like binding, Automatically updating views, it also easy for testing purpose.The functionality of Model and View is same as we have discussed in MVP.
View-Model :- It is responsible for exposing methods, commands, and other properties that helps to maintain the state of the view, manipulate the model as the result of actions on the view, and trigger events in the view itself.View has a reference to View-Model but View-Model has no information about the View.There is many-to-one relationship between View and View-Model means many View can be mapped to one View-Model. It is completely independent of Views.