So, what is Airbnb?
Founded in August 2008 and headquartered in San Francisco, California, Airbnb is a community marketplace for people to advertise, discover and book accommodations around the world, whether through a computer, a mobile phone or a tablet.
It is available in 192 countries, connecting different travellers that can access it anytime, anywhere, that's why Airbnb mobile application is so important. Created in 2013, Airbnb app is available for iOs and Android.
Why use RxJava?
We all know that mobile engineering is hard. Mobile users expect an instant response to everything, and there’s also the need to switch back and forth between different threads. There is the main thread, you need to make network calls, and you need to make different things that happen in the background. On top of that, you cannot block the UI thread.
RxJava is a good candidate for solving it because it is easy to switch back and forth between threads. It is built right into the framework. Async can be very cumbersome and error-prone, and RxJava is one reason we you do not need to do that anymore, and why you can compose different tasks together.
The real reason for Airbnb to implement RxJava? Because as they say "We make shitty software. Why do we have so many bugs? Why do we need crash reporting tools that track how many hundreds of thousands of crashes we had, or how many users are mad at us? Something must be wrong".
They were in a need of a change. As Felipe Lima, Software Engineer at Airbnb, said: "I think imperative programming is not the way we should be doing this. Of course, object-oriented programming has been around for many years. That’s built into our core as modern programmers. Everyone does this with eyes closed, but it isn’t necessarily the way we should be doing software".
Functional programming is the concept behind RxJava, and it is one way you can achieve more solid code that does not keep state around forever. The code is more reliable and you know that works.
The main problem is that we write bad code and mobile engineering is hard, and this is one way of tackling that problem.
Showing some examples
When using RxJava, you are building a stream.
If you do not call observeOn(), everything’s going to run the same thread that is subscribed to the observable. Here, we have subscribe, so if this is called from the main thread, everything will happen from the main thread regardless of what you are doing. So, observeOn() is effectively a way of offloading that work to a different thread, and that’s going to make it asynchronous.
Change the thread that the observable is subscribed to. First, the observable is created affecting subscribeOn(). Then, you have the code that runs upon subscription, the code that runs when you subscribe to it, and all the other mutations on that stream. This changes where the subscription code runs into, not the rest. It doesn’t matter when you call it, it only changes the thread where the subscription is executed.
CompositeSubscription Class that can group multiple subscriptions together, and then you just add the subscription to it. Then, whenever you destroy the activity, you just clear it out.
RxGroups
RxGroups lets you group RxJava Observables together in groups and tie them to your Android lifecycle. This is especially useful when used with Retrofit (Retrofit turns your HTTP API into a Java interface).
For simple scenarios you can probably just let the original request be cancelled and fire a new one. However it is easy to see how this becomes a problem in more complex situations.
Let’s say the user is submitting a payment. You will probably want to to guarantee that you can reattach to the same in-flight or completed request after rotating the screen or leaving the Activity and returning later.
RxGroups will also automatically prevent events from being delivered to your Activity or Fragment before onResume() and after onPause(). If that happens, they will be automatically cached in memory and delivered once the user returns to your screen. If they never return, the memory is then reclaimed automatically after onDestroy().
Where Airbnb uses RxJava?
They are using it around the network layer, not exposing it to the UI, because that is a much bigger bet. The need of getting everyone on board and the knowledge thing comes into play, because if you expose that to your activity layer or your views, then it means that everyone literally has to understand it to use it.
In the network layer, fewer people have tits perception, so you do not have to have everyone understand what is going there.
They just expose an API, and it works. It is like a bridge where we use RxJava on one end, and on the other side it is like normal land. It is kind of limited use, even though it’s a core part of the app.
UI layers does not know anything about it. It just have listeners, and only it cares about callback.
Summarizing it
Overall, the biggest challenge for Airbnb migrating to RxJava was getting everyone up to speed, learning it and understanding it. But it was worth it? It still is a big one but it worth it. You get more benefit once you start to use it more: combine streams, mutate them, etc. With a little piece of code you can achieve a lot, does wonders for you, and it’s really amazing.
