Category Archives: MVP

Rebuilding a legacy app from scratch (III): Clean Architecture.

Once we have decided the features we want to have in our Minimum Viable Product version of the app, and before jumping straight away to start coding, we need to decide how are we going to design and architect the application.

Why we need to implement a good architecture? Because we want the code base of our application to be testable, scalable, robust, modular and maintainable, among other things.

Over the years a few architectures patterns has been defined and used by Software engineers for different platforms and systems but one of them that has gained lot of traction and popularity in the mobile community is the well known Clean Architecture.


What is Clean Architecture?

This pattern was defined by Uncle Bob and described in this blog post.

He summarise the main goals of a good Software Architecture:

  • Independent of Frameworks: We want to isolate the Android or iOS framework from our business / UI logic, making them testable and interchangeable.
  • Testable: This has been one of the traditional issues when designing the testing strategy of our apps, it was difficult to test a module that has many external dependencies, like the Android SDK.
  • Independent of UI: We want to have our UI independent from our business logic, this way the last one can be unit tested without having to depend on UI or Integration tests.
  • Independent of Database: The source of data must be isolated from the rest of layers of the app, this way we can change this source without affecting the logic of the app.
  • Independent of any external agency: The business logic doesn’t depend on any external factor.


An Android approach to Clean Architecture

So for our Android implementation of the Clean Architecture we are going to follow the design described by Fernando Cejas in one of his great blog post.

We are going to identify three main layers in the code base: Presentation layer, Domain layer and Data layer.


Presentation layer

We are going to use  the Model-View-Presenter (MVP) pattern to implement this layer. I will explain briefly this presentation pattern but you can see a more detailed explanation in my introductory article here.

Basically we are going to have a View entity,  where we implement the Activities, Fragments and Views. These are what we call passive views, what means that they are totally dumb and have zero presentation or business logic. They just display information in the screen under the direction or the Presenter and dispatch events back to this one, like user actions.

Then we have the Presenter that as mentioned previously contains all the presentation logic and is acting as a bridge between the View and the Model layer. This entity should not have any Android dependency, but it knows how to respond to user actions and how to retrieve the information or data that is required to display in the view.

And finally we will have the Model layer that will contain the bridge and adapter classes accessing the Domain layer of our architecture.


Domain Layer

It’s going to contain all the business logic of our app. Once again there shouldn’t be any Android dependency in this layer. In here we will implement what we call Interactors, which basically are Use Cases.

For example, if we look into the MadridBus application, we will see that one use case is to get the list and information of all the bus lines in the city. This logic will be implemented in one Interactor and it will be used by the Presenter of the Line List View.

So when the user open the line list screen, the View is going to tell the Presenter that it has been loaded, the Presenter knows then knows that have to retrieve the line list, so it’s going to instantiate and use the GetLineListInteractor, which is going to access the Data Layer to get the list of lines. When the data set is returned the Presenter knows calls the View and tell it to display this information in the right way.


Data Layer

In this layer is where all the data of the application is stored and processed. This layer is responsible of providing the mechanisms to retrieve the data that the app needs. The Interactors will be calling the API of the data layer so they can retrieve this data to the Presenters.

We want to make the data source totally agnostic for the rest of the different layers of the app. This means that the Interactors doesn’t know from where the Data layer is extracting the information, they will just call the interface of the API exported following the Repository Pattern.

Screen Shot 2017-04-27 at 22.47.21

From Hannes Dorfmann blog post 


For example, in the app we are going to have two sources of data, the first one will be the Cloud, from the public transport agency data service. Then we will have the local database, where we will save the data taken from the cloud, so the next time when the GetLineListInteractor call the Repository to get the list of lines, if this exist in the local database, it will retrieve from there, and if not it will retrieve it from the cloud.

To read more about the repository pattern check out this great blog post from Hannes Dorfmann.


The project structure

One importante aspect when designing our code base which is dependent on the architecture of the app is the structure of the different modules and how are they grouped in the project.

As Uncle Bob says, this is like a blue print of the application. Looking at the project structure should give us an idea of what this system is about.

Screen Shot 2017-04-23 at 00.27.36

As we can see in the screen shot, the project has four main module groups: DI, Domain, Model and UI.

In DI we have all Dagger 2 dependency injections helpers.

Domain as we have mentioned before contains the business logic, interactors, network modules, rules, etc.

In Model basically we have Pojos and data classes.

Finally in UI we have all the Presentation layer modules, like Activities, Presenters, etc.

With this project structure we can easily find and navigate to a specific feature or functionality of the app, either the UI part, the Domain or the Data component of it.



A good architecture is the blueprint for our project, it will guide our implementation and will keep the maintainability, testability, cohesion and modularity of the project.

Clean Architecture is not the silver bullet nor the only way to design our apps, but has proved to be one of the best solutions.

We will be following this pattern in the MadridBus source code implementation that you check out in Github here.

Tagged , , , ,

Rebuilding a legacy app from scratch: MadridBus revamp (I)

MadridBus was the second application that we released in Quoders to the app store. It is an adaptation from the original BilbaoBus, an app to get public transport information like routes, stops info, timetable, etc. It was born just as a learning side project but we got good traction from the beginning  and it grew up having more public transport agencies, improved UI, etc.

screen-shot-2016-10-01-at-09-27-38On the other hand MadridBus wasn’t so popular, probably because there were already a few decent applications in the market for the city of Madrid, so we didn’t focus so much on it. As a result, now days the app looks and feel really outdated, the UI is clunky and the plumbing of the app are really ugly and not maintainable.

So for this reason I have decided to rebuild the app from the scratch as one of my side projects. It will be open source published in Github. I will be explaining here in the blog all the design and implementation decisions, the different techniques, libraries, etc. The goal, apart from having a new and better application, is to have a project that could be a reference for new Android developers and hopefully help them to have a better understanding in how to implement from zero an Android app following good practices, patterns and explain the usage of Android concepts and most used libraries.

In this post I am going to give a quick summary of the different features, patterns, design and other elements that I am going to use following the best practices and modern Android development techniques. In following post I will be describing in more detail each of these elements and explaining the implementation and the source code will be available on Github.

Minimum Viable Product scope and features

So first thing first, let’s define the MVP (Minimum Viable Product) features and requisites.

The current published version of MadridBus has five main features:

    • Go To: This feature allows the user to search a route between point A to B, either pointing in the map or searching by address. This functionality, despite being really useful when you don’t know the city or the best route, interestingly it’s not very used as our Google Analytics data reveals.
    • Line List: Display the list of all the lines (day and night) available and allows the user to see the stops for a specific line and then the next bus time.
    • Stops List: Display a list of all the bus stops in the network. This functionality again is not really very useful, unless you know the name of the stop and want to look up.
    • Favourites: This is really useful as the user can save here to have quick access to the favourites stops, like work, home, etc.
    • News: Display a list of news fro the rss service of the bus agency. Useful when there are disruptions, changes, etc.

So for the MVP of the new app, taking into account what features the users are really using in the published app,  I’m going to go for the Line List, Favourites and News. Also we will be releasing an Android Wear app that will displayFor the V2, we will be adding the Go To feature and maybe the Stops list.

App architecture: Data access and storage

A public transport application needs to work with an extensive and complex source of data containing lines information, time tables, real time, geolocation, etc.

For MadridBus we are going to need two different set of data that we will retrieve from the Madrid public transport agency web servers:

The first one are static data that needs to be downloaded periodically and stored in the device for quick access offline.  This set of data contains the bus lines info, route s, stops position, etc.

The second type of data are the real time information, this will be accessed when we needs to display the real time info of the next bus for a specific stop.

To accomplish this network access we are going to use the well known library Retrofit from Square.  There are other options like Volley from Google but in my personal opinion and as you can see in some reviews like this, Retrofit is much better option. For more information you can check my blog post about Retrofit.

For the data storage on the device we are going to use a local data base managed with the library Realm. Databases in Android usually is a pain to implement using the SQLite API, but with real we simplify and make more robust and less error prone our data base implementation. It supports multithreading, encryption, reactive extensions, etc.

UI Layer: Material design

So now let’s talk about the UI layer. As we mentioned before, for the version 1 we are going to implement just the Line list, Favourites and News functionalities.

We can see clearly three different features that will need three direct access from the home screen. So following the Material Design guidelines we are going to use the recently added Bottom Navigation widget that will give us access to the three different features of the app. As we can see in the documentation,  this component is recommended for between three and five sections. In case we needed more is recommended to use a Tab view component or maybe using the left navigation drawer.

So the first option is the Home view and it will display a Google Maps showing the location of the user and the nearest bus stops. The second option will be the Line List, using a Recycler view to display the lines info, and the third option will be News screen, again using a Recycler view. We will post designs and wireframes in a future post when we start implementing this.

UI Layer: The MVP pattern

The MVP is now days one of the most used patterns in the Android community  when it comes to organise the UI layer. There are multiple benefits like much more modular, reusable and testable code. For a complete description and explanation of the pattern take a look to one of my previous blog post.

As a quick summary, the Activities, Fragments and custom views will be the View layer of the pattern and they will contain only pure UI functionalities.

The Presenter will be a man in the middle layer that will work as intermediary between the Views and the Model. They will respond to events and actions from the user on the View and it will perform any action required using the Model layer.

Modules wiring and communication

So as we are going to have different layers in the app following we need some mechanism to communicate with each other, passing data, etc.

There are different ways to accomplish this, we have just the traditional way using listeners, but we agree that this comes with many problems and we end up with the infamous hell of listeners.

Another better solution would be using an event bus, but this again has its own downside. The code end up being less readable it grows up having multiple events dispatching from everywhere with unexpected results.

There is a better solution and will be using RxJava. As we know it’s one of the library and techniques that has focused the attention of the Android community for a while now.

We will see in a future post and in the code of the app how to use RxJava and how to architect the app using it and all the benefits that it has. In the mean time you can have a look to my blog post about it.

Testing and Continuous Integration

Testing is often one of the most neglected aspects of the applications development process. For our application we are going to implement two main type of test: Integration Test using Espresso (UI test) and Unit Test when relevant with JUnit.

For more information about a good testing strategy take a look to my blog post about it.

Continuous Integration is another key piece of our app development as it allows us to have a build of our app everytime we submit changes to the code repository. This way we can launch our tests suite every time we make a change in the code validating it’s correctness.

For this functionality we are going to use Travis, a CI platform totally free for open source projects. Once again we will be explaining the configuration in next posts.


So that’s it for today, as mentioned before we are going to be publishing blog posts to comment and explain the implementation of the different parts of the new app as we progress coding it.

Stay tuned!

A brief introduction to a cleaner Android architecture: The MVP pattern

As the Android platform has been maturing, developers found that the standard approach to organise the architecture and design of the application code wasn’t the best at all. Usually we ended up having a massive monolithic module, an Activity or a Fragment, containing business and UI logic, creating an unmaintainable and untestable messy project.

Google itself haven’t provided so far a good practice guideline or code examples showing a modular and decoupled approach that implements any of the well known and widely used design patterns, like for example MVC which is encouraged by default on the iOS platform or the common MVVM in Microsoft environments.

One of the most common pattern that the community of Android developers has been using for a while and that has got lot of attention is the Model View Presenter (MVP) pattern and we will focus on it on this post. We will not go through a deep academic description of the pattern but we will focus on the advantages and practical use of it. For an awesome analysis of the MVP and other patterns take a look at this classic post from Martin Fowler about GUI architecture.

So what’s MVP?


Basically MVP is an architectural design pattern that divides our application code in three entities in order to achieve a modular design, implementing the separation of concerns concept, allows an easier implementation of unit tests and making possible to reuse and replace modules either of our UI, data or business layer.

MVP is an evolution of MVC and it has multiple variants and implementations. There has been a lot of conversations and debate about the best and proper way to adopt it on Android. I’m going to expone my way which I have been using in a couple of projects and I reckon works better for me. Of course it doesn’t mean is the best or only one that works on Android, so please leave any comment and suggestions if you find any area of improvement.

Ok so let’s see who is who in this approach.

The View

This entity is going to include the visual part of our app, it is only the UI and it will not have any logic or knowledge of the data displayed. The View doesn’t know anything about the business logic or how to get the data it has to show to the user.

Activities, Fragments, Dialogs, etc… would be included in this category. This elements will contain only initialisation and display functionalities of the visual components and elements to display information to the user. It will not contain any functional or business logic like access to database or web server for example.

This module (Activity, Fragment, etc) exports an interface that will be used by the Presenter, which is responsible and have the knowledge and logic about how, when and what to show in the View. This interface will have methods like “showProgressBar”, “showLoginErrorMessage” or “launchSignupActivity”. Here is an example:

public interface WelcomeView {

    void launchHomeActivity();
    void LaunchSignupActivity();
    void closeActivity();

    void setWrongUsernameError();
    void setWrongPasswordError();

    void showLoginErrorAlertDialog();

The Presenter

As we mentioned before, this entity is going to have all the logic and knowledge about what, how and when to display in the user interface. It will be responsible of capture events raised by the user when interacting with the UI and perform any action.

The presenter also acts as a bridge between the View and the Model fetching any data needed from the data layer, making any transformation and display this info to the user on the View.
This entity ideally shouldn’t have any dependency of the Android SDK such us Context or Activity references.

The Activity will have a reference to the Presenter interface and it will use it to communicate any event occurred on the View, like the user tap on a button or the user enter any data in a TextView and then it will decide what to do in reaction of that event.

Here is an example of a Presenter interface:

public interface WelcomePresenter {
    void onCreateAccountClick();
    void onActivityResultCalled(int requestCode, int result);
    void onLoginClick();

So for example let’s say that if the user tap on a Logout button, the View call the exported method “onLogoutClick” of the Presenter interface. Then the it knows what interactor of the Model layer needs to invoke to perform a Logout action on the app.

Once the log out success callback has been received, the Presenter will perform any action on the View, for example closing the Activity and displaying a home screen Activity.

The Model

In this entity we will include the “interactors” (use cases of our business logic) that will perform and manage any business layer logic and data access, like fetching data from our web service, accessing the database, etc.

Once we have that piece of data the interactor will send it back to the Presenter and this will decide what to do with this data and how to show it to the View as we saw in the previous point.

Here an example of an implementation of an interactor:

public class WelcomeInteractorImpl implements WelcomeInteractor {

    private WelcomeInteractorListener   mListener;

    public WelcomeInteractorImpl(WelcomeInteractorListener listener) {
        this.mListener = listener;

    public void loginWithUserName(String username, String password) {

        ParseUser.logInInBackground(username, password, new LogInCallback() {
            public void done(ParseUser user, ParseException e) {
                if (mListener != null) {
                    if (user != null) {
                    else {


So this is a very brief summary of what is MVP and how to use it on Android to achieve a cleaner, modular and testable source code. This is just an interpretation of the pattern and is not a silver bullet or the perfect solution for our apps, so any comments or critics are more than welcome!

To see an example of this implementation you can take a look to one of my open source experimental apps “Treepolis”. Is still an in progress project and you can find it here in Github
To see a practical example of the pattern used for the Welcome screen and login functionality check this folder.

Tagged , , ,