Category Archives: RxJava

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!


Introduction to RxJava for Android by examples (I)


Reactive programming is one of the hottest topics amongst the Android community these days. Lot of big guys in the industry are embracing and using RxJava in their platforms and applications, even Google has release their own version of a reactive library called Agera.

One of the problems of Rx programming is the initial learning curve, the complexity of the paradigm itself and the extension of the library operators and classes.

The goal of this post is to make a very simple and easy to understand introduction with some examples and be able to start programming and design our apps using RxJava.

What is RxJava?

RxJava is just a library that implements ReactiveX extensions, which basically facilitate the implementation of  asynchronous programming using observables data streams.

It can be described as a combination of the Observer (there is one entity emitting data and one or many listening or it) and Iterator (the data flow are dispatched in onNext events sequences)  patterns using the Functional Programming paradigm (we get data in declarative style methods and avoiding mutable objects).

RxJava is one of the language implementations of the ReactiveX libraries. At the moment there are also other versions available for languages like JavaScript, C#, C++, Swift, Kotlin, etc…

Why RxJava?

So if there is the learning curve and complexity issue, why to bother learning RxJava? These are some of the main reasons:

  • Abstraction of complexity of async data flows and events. It’s quite common to fall into the hell of nested and multiple listeners, the hell of multiple events from everywhere when using an event bus, etc. With RxJava we can simplify all this using just asynchronous stream of transformable data.
  • Filtering, composition, transformation. Thanks to the massive amount of operators we can easily transform any stream of data transmitted. As we will see later we can filter, combine, transform, create, etc. any kind of data stream.
  • Error handling.  Very straightforward error handling by centralising in a single callback method any error, stopping the data sequence.
  • Easy testing. Having a single source/destination of the data source and testing helper classes make it quite easy to test.
  • Light and high performance. RxJava is light and fast, at the moment it weights around 1 MB and it’s quite fast streaming our data.


The key components

So let’s take a quick look to the key elements that compose the RxJava library.

The Observable

This is the data source, the object that will be emitting the sequences of data items that the entities who are interested in the data they provide, will be subscribing.  It implements all the operators mentioned before to be able to transform the data streams. Observables can be divided in two types: “Hot” observables which might emit data as soon as they are created  and “Cold” observables which wait until an Observer subscribes to it.

The Observer

This is the type of object that will be subscribing and “observing” the data emitted by the Observable, they will “react” somehow using the data provided. Typically they implement the three main events OnNext, OnError, OnComplete as we will see later.

More info in the official reference here.


These is one of the key and most powerful features of RxJava. There are quite a lot operators of different types that will help us to manipulate and transform in many ways the data streams. We can group them in different categories such as Creating, Transforming, Filtering, Combining, Mathematical, etc.

For a complete list of operators take a look to the documentation following this link.


The Schedulers will help us to implement multithreading in our data streaming. Calling the Observable method “SubscribeOn” and indicating one of the Schedulers we can select in which thread the Observable will do it’s data stream job. On the other hand, calling the method “ObserveOn”, will set up the thread where we will be receiving and observing its data stream.

In RxJava the most common Schedulers are “NewThread” (create a new thread for each job), “io” (for input/output operations), “computation” (event-loops, callbacks processing, etc), “immediate” (perform the job immediately in the current thread), etc.


A Subject is object that is able to act as Observable and Observer. It can emit data streams and at the same time can subscribe to another data stream source (Observable), so we can think in it like a sort of bridge between two data streams.

Example 1: Simple subscription to a source of data

For our first example, we have a method that create a list of numbers and in order to simulate a long operation, we have added a 100 milliseconds thread pause in the loop.

The method look like this:

private List<Integer> getOddNumbers() {
    List<Integer> numbers = new ArrayList<>();
    for(int i=0; i<100; i++) {
        if(i%2 == 0) {
            try {
            } catch (InterruptedException e) {
    return numbers;

Now we create the Observable that is going to emit that list of numbers. To accomplish this, in this example we use the “fromCallable()” method that is going to build an observable which will emit the list of numbers retrievedby the callable method:

private Observable<List<Integer>> getOddNumbersObservable() {
    return Observable.fromCallable(new Callable<List<Integer>>() {
        public List<Integer> call() throws Exception {
            return getOddNumbers();

Right, so now that we have an Observable which is going to emit some data, what we need next is to create an Observer that is going to subscribe to that source of data and receive the numbers list. Let’s have a look to a standard Observer:

private Observer getOddNumbersObserver() {
    return new Observer<List<Integer>>() {
        public void onCompleted() {
            LogHelper.addLog(mTvLog, "getOddNumbers() - onCompleted()");

        public void onError(Throwable e) {
            LogHelper.addLog(mTvLog, "getOddNumbers() - onError()");

        public void onNext(List<Integer> integer) {
            LogHelper.addLog(mTvLog, "getOddNumbers() - onNext()" + integer);

As we can see, the Observer implements three fundamental methods: onNext will be called when the Observable emit an item. onCompleted will be called when the Observable has finished emitting data. And finally onError will be called if there has been any exception or error when emitting data.

We can simplify the Observer in case we just want a single event that will receive the list of numbers and we don’t need to know about the OnComplete and OnError events. To accomplish this we just need to create an Action instead of the Observable, something like this:

private Action<List<Integer>> getOddNumbersAction() {
    return new Action<List<Integer>() {
        public void call(List<Integer> integers) {
            LogHelper.addLog(mTvLog, "getOddNumbersAction() - call: " + integers);

So the last step would be to subscribe this Observer to the Observable, and it would be as simple as this:


And that’s it! When the getOddNumbers() method has finished the calculation of numbers and return, the Observable will dispatch the list of numbers and the Observer will receive the data.


So this has been the introduction and basic operations with RxJava.
You can find all the examples in this public repository.

In next posts we will be looking deeper into more elements of the Reactive extension, like the Operators and Schedulers, etc.

In the mean time please leave here any comments, suggestion or corrections you might find!

Tagged ,