Android Architecture with Multi-Screen MVP (Part 2)
In this article, we continue our “ride” of revising the way we develop our Android Taxibeat application.
The previous article described in detail the transition from the old “monolithic” Android architecture to a more dynamic one, capable of addressing the increasingly high demands of the flexible UI/UX we are currently implementing. To this end, we espoused the Model-View-Presenter (MVP) architectural pattern and implemented a number of significant modifications to the structure of our codebase in order to address our specific needs.
Let’s discuss our MVP theory
In our previous article we summarised what the MVP pattern is about and presented our alternative approach to it. We also introduced the concepts of the the Screens and Flows, and made a direct association between Screens and Views, Flows and Presenters.
Here is how we could define the concepts of Screens and Flows:
Screen is a view interface that determines the look and the behaviour of a UI. It is typically implemented by an Activity. Note that more than one Screens can be found and implemented by a single Activity.
Flow is a controller that manages the behaviour of a single Screen at a time, and reflects the business logic that helps us connect a Screen with a Model. A single Flow might be part of a bigger Presenter, while many Flows may be descendants of a single Presenter.
But, really, why did we follow this pattern?
As outlined in the first part of this series, our main goal in this radical departure from the established approach to Android development, was to give our users the experience of an interface, where the basic functions are operating smoothly and fluidly and are built in such a way that the user is always guided toward the relevant parts of the application .
To achieve this, οur designers came up with the idea of a central map component, which includes most of the features and of course implements the basic flow of our product’s use case, namely the process of hailing a taxi. From the application launch until the eventual hailing of a taxi, everything happens inside a single Activity, and indeed inside the same map.
Another MVP advantage is that an Activity’s XML layout can be transformed and used in multiple ways. For example, a common case could be that the same “screen”, in terms of UI/UX, might be needed for two or more Activities.
Apart from the obvious advantage of providing a more comprehensible and clear method of coding an Android project, the MVP pattern also provided us with the great advantage of being able to “break down” a very “large” Android activity into smaller parts with separate Presenters, each implementing smaller business functions and creating, at the same time, the required UI/UX flow.
How we eventually implemented the Screens and Flows?
Let’s take an example. Suppose we have a design requirement to integrate two new screens for a new payment feature. In the first screen, the passenger will be able to edit the payment means he/she had previously added, while in the second screen, he/she will be allowed to select the payment means they prefer to use to pay for their ride.
The most “naive” approach would be to create two different activities.
Single PaymentActivity example:
Yet the UI changes between these two screens are insignificant. Thus, one Activity with two modes, passed via intent extras would be a better solution.
MVP implementation with Presenter and Screen:
Following a more structured pattern, with the use of MVP rules we can separate our PaymentActivity into the PaymentPresenter (the Presenter of this Activity) and the PaymentScreen interface (the view interface implemented by the PaymentActivity).
MVP implementation with Presenter, Screen and Presenter Flows:
There is more that can be done to improve this further. The PaymentPresenter can be divided yet again and allow specific Presenter flows to call the right method and act according to the Flow that calls it.
This way, both Activities and Fragments become very simple, undertaking only the task to initialize and update UI views, as well as to handle user events. Thus, the Presenter handles the business logic goes to the Presenter, that can be further divided into more parts and share logic with its Flows. Therefore, by using multiple Presenters in a wise way, it becomes easier to comprehend, maintain and test the project.
The aforementioned example should illustrate that the re-use of the same UI components resulted in a useful way to re-use the same Activity, a smaller code-base and cleaner interfaces between the individual components involved.
But, is it always possible to identify how the core code of the Activity can be divided into smaller parts? To determine this, start by following the business model of your project, working around UI challenges and limitations and deciding which use cases are important for each screen of the application.
The real example.
Following the example above, and implementing the MVP pattern with multiple Screens and Flows, this is a real example of how a single Activity can be re-used, dividing the logic of a single Presenter into the following Flows:
Conclusion and Demo Project
We have reached our destination. In this series we described an MVP implementation aimed at improving the way Activities, Presenters and Views are used in MVP, as informed by the specific needs of our application.
In the GitHub link below, you can find an Android project that will help you deepen your knowledge of our approach and the topics presented here. Please, do not hesitate to comment on or respond to this presentation!
