An android app in its life time goes through numerous change cycles, app upgrades with many features addition/removal. Incorporating these over a period creates chaos in your application code if it is not designed well. This is why we should use an architecture pattern. By applying architectural patterns to your mobile code base, you can significantly reduce bugs, build fragile code, making code simpler to read and easy to test.
“Software Design is the process of analyzing system requirements that enables building components and interfaces between those components.”
MV'X' Architectural Pattern
MV'X' are architectural patterns commonly used for developing user interfaces that divides an application into three interconnected parts. This is done to separate internal representations of information from the ways information is presented to and accepted from the user. All these design patterns stated below by and large help in developing applications that are loosely combined, easy to test and maintain.
Model View Controller (MVC)
Model View Presenter (MVP)
Model View ViewModel (MVVM)
We will focus on MVP pattern in this blog. All discussion about the pattern is made in context of Android as a Platform.
Model View Presenter (MVP)
In MVP,
- Model: Handles the data part of the application
- View: 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
The Presenter contains the UI business logic. All invocations from the View delegate directly to Presenter. The Presenter is also decoupled directly from the View and talks to it through an interface. This is to allow mocking of the View in a unit test. One common attribute of MVP is that there must be a lot of two-way dispatching.
For example, when user clicks the "Save" button, the event handler delegates to the Presenter's "OnSave" method. Once the save is completed, the Presenter will then call back the View through its interface so that the View can display that the ‘save’ action has completed.
Two primary variations are Passive View and Supervising Controller
Passive View: The View is as dumb as possible and contains almost zero logic. The Presenter is a middle man that talks to the View and the Model. The View and Model are completely shielded from one another. The Model may raise events, but the Presenter subscribes to them for updating the View. In Passive View there is no direct data binding, instead the View exposes setter properties which the Presenter uses to set the data. All state is managed in the Presenter and not the View.
Pros: Maximum testability surface; clean separation of the View and Model .
Cons: More work (for example all the setter properties) as you are doing all the data binding yourself.
Supervising Controller: In Supervising Controller, the view interacts directly with the model to perform simple data-binding that can be defined declaratively, without presenter intervention. The presenter updates the model; it manipulates the state of the view only in cases where complex UI logic that cannot be specified declaratively is required.
Pros: By leveraging databinding the amount of code is reduced.
Con: There's less testable surface (because of data binding), and there's less encapsulation in the View since it talks directly to the Model.
Image credits: Microsoft MSDN website
Conclusion
The value of separation of concerns is to simplify application development and maintenance. When concerns are well-separated, individual sections can be reused, as well as developed and updated independently.
