Having worked on a large number of mobile applications I am well aware of the complexity introduced by having to deal with multiple asynchronous event sources. To that end I have been experimenting recently with the use of Reactive Extensions on both iOS and Android, using ReactiveCocoa and RxJava respectively. Android developers who have followed a similar path will be familiar with the name Matthias Kappler, a core contributor to and proponent of RxAndroid. Matthias recently kindly agreed to a Q&A session with myself for InfoQ, an extract of which is included below, along with a link to the full article.
InfoQ: Why should Android developers who are comfortable with AsyncTask or Loaders invest time in learning RxJava?
Matthias Käppler: We adopted RxJava because there are limitations to AsyncTask, Loaders, and Handler/Message which made them unsuitable for us as a means of transporting data in a resilient and reusable way. The primary reason is their lack of compositional APIs, which prevented us from expressing asynchronous operations as what they typically are: a sequence of steps where inputs and outputs are handed over from one step to the next. Closely related to this is the idea of performing such steps in a fault tolerant way, however, none of the above mentioned framework classes can express the fact that even an individual step failed, let alone an entire sequence. Since we frequently need to compose multiple data sources such as database and web API calls, and since furthermore mobile is an environment that is inherently prone to failure of many kinds (flaky networks, device fragmentation, etc.,) AsyncTask, Loaders, or Handler/Message alone can not be considered suitable tools. RxJava addresses this by providing a uniform way to describe a piece of work to be executed, how to transform or compose its result, all the while making sure that either result or failure end up safely at the subscriber, no matter if or where the sequence failed.