
Adopting RxJava on the Airbnb App - astigsen
https://realm.io/news/kau-felipe-lima-adopting-rxjava-airbnb-android/
======
muraiki
I've prototyped UIs with RxJS (the javascript version of reactive extensions)
both by itself and with Cycle.js. I've also used reactive programming in Perl
6. There are a lot of things to like about reactive programming, but anymore
I'm not sure if it's the right answer. Let me first preface this by saying
that I'm building upon thoughts presented (by someone else) here:
[http://blog.paralleluniverse.co/2015/08/07/scoped-
continuati...](http://blog.paralleluniverse.co/2015/08/07/scoped-
continuations/)

One problem with reactive programming (and also with promises), is that you
are essentially using monadic composition in an imperative language. Because
of the lack of special support for monads that you have in a language like
Haskell, you have.to.chain.flow.control.methods. As a result of this, you lose
access to the standard flow control the imperative language provides you, and
you also generally end up with mangled stack traces. Now I know that rxjs5 is
working on the stack trace problem through the usage of a recursive scheduler,
but I'm not sure how this works on the Java side of things.

An alternative approach can be found in languages like Go and Erlang. In these
languages you generally do not need to worry about exhausting a thread pool
because they have made creating "threads" extremely cheap. As such, you can
write normal imperative code that blocks, potentially indefinitely, and also
still preserves stack traces and which uses the plain flow control structures
(and error handling) of imperative programming.

Furthermore, if you couple this approach with CSP, you can leverage
specialized systems that can "prove" (to a "good enough" level vs a
mathematical proof level, although the latter is probably possible) that your
design is correct. I'm not certain if a similar capability exists for reactive
streams. See [http://reaktor.com/blog/why-csp-matters-ii-how-do-i-know-
syn...](http://reaktor.com/blog/why-csp-matters-ii-how-do-i-know-sync-works/)

Now granted, this discussion may be overkill for a small app that needs a
little bit of reactivity. The article does mention that they are using this
only for networking code. I've tried to use it in a much more general way, and
I'm not yet fully convinced that it's the right approach in a typical
imperative/OO language. Of course, if it seems like adding green threads to
the language is nontrivial, as may be the case with javascript, then perhaps
rxjs is the best option after all. :)

~~~
_pmf_
> One problem with reactive programming (and also with promises), is that you
> are essentially using monadic composition in an imperative language. Because
> of the lack of special support for monads that you have in a language like
> Haskell, you have.to.chain.flow.control.methods. As a result of this, you
> lose access to the standard flow control the imperative language provides
> you, and you also generally end up with mangled stack traces. Now I know
> that rxjs5 is working on the stack trace problem through the usage of a
> recursive scheduler, but I'm not sure how this works on the Java side of
> things.

Your point is kind of validated by C#'s introduction of async/await at the
language level. If Rx extensions for .NET would have lived up to their promise
(and those are much, much more mature that the poor man's imitation that is
RxJava), there would have been no need to introduce a completely unrelated
mechanism for doing async work (and mandate its usage in the Universal Windows
Platform).

~~~
bsaul
I'm having trouble following this thread of conversation : isn't reactive more
about restructuring your app as a composition of event streams that trigger
actions and GUI state changes, rather than just simply performing async tasks
?

Fwiu, It tries to have you build your app as a static tree of flows, in a
descriptive manner. It's a much broader goal.

------
wiradikusuma
I want to integrate RxJava in my Android app, but I can't seem to find an up-
to-date, cohesive tutorial to do exactly that. Most tutorials I read usually
step 1. very basic reactive concept, step 2. ..., step 3. profit.

~~~
tartuffe78
We ran into that as well integrating it into a 3 year old Android codebase.

We followed these tutorials at first, but it definitely just took a lot of
time and trying things out. [http://blog.danlew.net/2014/09/15/grokking-
rxjava-part-1/](http://blog.danlew.net/2014/09/15/grokking-rxjava-part-1/)

RxJava + Retrolambda has accelerated our development speed once we got a grip
on it, but it does complicate our build process.

~~~
j_horvat
+1 for Grokking RxJava, really great set of intros, especially from an Android
perspective. Gonna pile my two cents on this as well. I think the easiest
place to add RxJava in an existing Android app would be your networking code.
Square's Retrofit works really really well with Observables and you can do
some very interesting things that imo are more immediately graspable than say
writing reactive UI code.

[https://joluet.github.io/blog/2014/07/07/rxjava-
retrofit/](https://joluet.github.io/blog/2014/07/07/rxjava-retrofit/)

This is a short post that I think nicely shows how Retofit+RxJava fit together

------
ghuntley
For Rx w/Xamarin (iOS, Android) and Windows Platforms check out
[http://reactiveui.net/](http://reactiveui.net/) :-)

