architecture-components-samples
architecture-components-samples copied to clipboard
RxJavaKotlin vs Kotlin Coroutines
There is a sample "BasicRxJavaKotlinSample"
But do we really need it if we have Kotlin Coroutines?
I see this Rx Vs Co-routines debate pretty high these days. IMHO, I don't see Co-routines as a complete replacement to Rx. Naturally, I think comparing them is just unfair in the first place. Co-routines are amazing, light-weight, structured, easy-looking I love using them all the time. But practically looking they help me to beautify my rather ugly looking async code and save me from CallBack Hell(they still have many advantages over normal threads. Channels, Structured Concurrency, Scopes, Cancellation, etc ). But they don't provide me with all the rich operators featured by Rx to manipulate my data provided by streams.
Let's consider a scenario, Rx provides an operator(subscribeOn(//Thread of your choice)) to schedule your work on one thread and an operator(observeOn(//Thread of your choice)) to observe it on some other thread. Now luckily even Co-routines allows you to do that with the help of withContext(//Thread of your choice){ //your work} . In this situation, Co-routines help you to achieve your desired task(of just creating a background thread ) with a minimal amount of code. The same thing in Rx would have taken triple the configuration along with the ugliness of callBack code to observe the results. In this scenario, Co-routines are a clear winner but when it comes to modifying or playing with the data received from your source, or chaining multiple jobs(where output of one function is fed to another one), Rx has no match, with such a great set of Rx operators you can enhance your data or chain your jobs the way you want, Co-routines are no way near Rx in this case.
This difference lies because fundamentally they're designed to solve different problems.
TLDR;
Use Rx - For constantly playing with data from streams(source/observable), chaining jobs, functional style behaviour for your work.
Use Co-routines - For Asynchronous Programming in synchronous style, Structured Concurrency, Sharing Mutable State Between Threads.
check this thread where the masters speak themselves for Rx Vs Co-routines
You basically mean comparing Rxjava vs Flow. Flow is a reactive api built on top of coroutines. Implementation wise is more performance, in rxjava every time you chain an operator you create a new Observable object and at least 3 subscriber objects, one use to intercept existing chain, one to receive the event and usually one that wraps the second one called SafeSubscriber to garante no events are delivered after onComplete/onError are called. Flow leverage a single CoroutineScope object to perform multiple operations so the amount of created objects decreases considerably. This is the selling point of Flow over other rx implementations. In terms of operators they are now almost the same. Error handling is slightly different, you catch exceptions by placing a catch operator in the stream, after the catch nothing is guarded. It means your final observer is not exception protected like in rxjava, it is considered to be outside the stream. This point of view makes it easy to find throwing code in the final observer, something that is hard in rxjava.
If you are interested to look how flows work, I have been implementing flows over LiveData using the Github browser sample https://github.com/juanmendez/android-architecture-components. I have tested most of the core classes but having to test screens is quite a lot of work when switching from LiveData. I am implementing this functionality in a current project. If chaining multiple network flows, I have found transform operator helpful in filtering while emiting only the resource data downstream. Just like @pablichjenkov mentioned handling erorrs is done via try/catch. If you have any questions just reply.