RxJava VS Coroutines: Which One Should You Pick? (Part II)

We’re back for the second part of RxJava & Coroutines 101 – join us while we keep exploring this theoretical analysis: 

Chapter II
(Check Part I here)

What is RxJava?

RxJava is a library that targets the use of reactive programming in the Java programming language. Rx stands for Reactive Extensions (ReactiveX), which is a project that provides the implementation of reactive programming for different programming languages. RxJava is a generic, well-documented API that allows functional, declarative representation of any operation as an asynchronous stream of data, which can be created in any thread and consumed by multiple objects from different threads. With RxJava one gets access to a framework capable of reactively managing and handling items, allowing complex event manipulations and management of schemas in a very programmer-friendly interface. RxJava is already quite well established prompting many organizations to specifically look for developers who are comfortable using this library.

Coroutines

Coroutines, unlike RxJava, focus on offering a mechanism to write asynchronous code that may also run partially sequentially, allowing the omission of callbacks in code which translates to more compact code that is easy to generate and refactor. Kotlin Coroutines are still experimental, meaning they may undergo changes through the hands of Kotlin creators, but nevertheless, they already present stable features, providing a compact way to solve the most common problems when working with asynchronous software which is not an easy task. This article only scratches the surface of the capabilities and intricacies of Coroutines without addressing more complex scenarios.

Coroutines workaround the use of recycled callbacks by making them into more sequential code through the use of Suspend Functions for more concurrent code that can still switch through threads easily. Coroutines have the benefit of being integrated directly into the Kotlin language and while they are very recent, there are already multiple applications and even other libraries that are supporting them.

Advantages and Disadvantages

Kotlin and Coroutines are a way to write cleaner code and they are quite intuitive for a programmer already familiar with object-oriented programming and concurrency/multithreading/asynchronism. As Coroutines are written using standard Kotlin, this library is suitable for new Android projects since Google announced Kotlin as the new language for Android.  Google has already added strong documentation support for Kotlin in its Android API, so it may be a better idea to dive right into it.

When it comes to Coroutines, they provide an easy way to manage threading and are perfectly suitable for processes execution on background threads when needed. This paradigm also provides an easy implementation of concurrency and structured concurrency. It is easily scalable and maintainable, which makes production cycle and efficiency of programmers’ time writing code, solving bugs or organizing and cleaning code better. Coroutines can significantly improve code performance and, as in Java and RxJava, there is the ability to use it as a stream. On the other hand, this language and Coroutines aren’t entirely perfect: they are not yet fully adopted by the community, and information online is not as complete compared to the longer-standing Rx API. Besides, although Kotlin and Coroutines are easy to write and the code is really clean, there is a learning curve for Coroutines, which can become even trickier if Kotlin is not a language the developer already dominates.

RxJava supports Java first, but through RxKotlin it can could also be easily used on Kotlin. It allows easy handling of cache without creating caching classes for instance. One of the most important things and a great advantage of RxJava is the decreasing of the memory leak in 90%, possible by replacing standard Android mechanisms, which much like garbage collection was important in C, becomes really useful when you are developing Android applications that no longer need to take that into much consideration . It could optimize code to improve an application’s responsiveness and it’s very easy to scale yet, really hard to maintain due to the over usage of it. Its’ complexity is challenging and the tendency to use it everywhere makes the code very complex, harder to debug and, consequently, making the programmer waste more time on it to solve bugs, develop new code around that, or even to maintain or rewrite code, since it doesn’t return errors and the only way to debug is quite primitive. This happens because the studio debugger cannot attach to a Rx chain and you need logs to see what is happening. Other point about this library: is not possible to emit null, although is not a great thing, since the probably of it emit null could be handled easily with errors. Coroutines can only be used in Kotlin, but maybe the main point that makes Coroutines not so used yet is that RxJava is already a known library, then probably you will never need to use Coroutines, because you can also use RxJava with Kotlin.

In terms of performance, Coroutines is more efficient than RxJava as it uses less resources to execute the same task while also being faster in doing so. RxJava uses greater amounts of memory and requires more CPU time, which translates into higher battery consumption and possible UI interruptions for the user.

In Conclusion…

So, Coroutines or RxJava? It is a difficult choice and also hard to compare them because Kotlin Coroutines are a thin language feature, while RxJava is a pretty heavy library with quite large variety of ready-to-use operators.

Both are designed to solve the same problem, asynchronous programming, however their approach to this is quite different. After all of the overview about Coroutines and RxJava, one might ask which solution is the best one. In terms of methods count, RxJava is bigger and a really powerful than a solution based exclusively on Coroutines. However, this difference can be eliminated by using Proguard and its code optimization. Bare in mind that Coroutines are currently experimental, which explains prospect deficiencies, especially regarding the overhead, but we’re positive it will be resolved eventually.

So, who wins, or which approach should we use in production code? Well, it is a case-to-case scenario, but if the app is already running with RxJava and it works, don’t bother switching. If the app runs network calls once or twice per activity creation, use Coroutines. If the app needs to be simple and easily read by less experienced coders, use Coroutines. If the app runs any sort of real-time feature, use RxJava. If the app needs high levels of data manipulation between fetching and emitting, use RxJava. If the app has the architecture based on reactive stream, use RxJava. If it is a multiplatform project based on Kotlin Native, use Coroutines. But keep in mind, it is possible to use both of them together, at least if the programming language is Kotlin.

Check our blog for more posts like the one you just read!