The Real Kotlin Flow benefits over RxJava

Attempt to analyze the benefits of Kotlin Flow over RxJava.



Recently the article about Kotlin Flow benefits over RxJava was published by Antoni Castejón García :

Though Antoni made a good work and many thanks to him for providing his feedback and experience (we need to share our thoughts, this improves community acknowledgment in various areas) — I found few places in the article with which I don’t fully or partially agree. Some points, in my opinion, were missing. So, I decided to make a follow-up feedback post on what I consider the real benefits of Kotlin Flow over RxJava. Feedback is also a good thing as it helps us to drive forward and maybe look at the same things from a different angle.

I didn’t want to be mean or offend anyone, especially Antoni. So, if one finds that some wording sounds offensive — please blame my English. My goal is not to argue or point to some mistakes, but to provide my humble opinion. At first, I was thinking about writing a comment to the original story, but the comment was too long, so I decided to make it as a separate article.

The format will be simple — I’ll just take some quotes and add my humble comments. In the end, will try to summarize what I have in my head.

I’ll have a three-level comparing:

  • :rotating_light: Kotlin Flow is either not better or worse than RxJava at the given point. Or there are some drawbacks.
  • :ok: Kotlin Flow has some benefit over RxJava
  • :white_check_mark: Kotlin Flow has a clear advantage over RxJava

Let’s go!

Decoding original article

However, if you want to implement a Subject related pattern you will have to use Channels for now. It is not a problem, but you will end up having a lot of ExperimentalCoroutinesApi annotations in your project. The good thing is they announced that they are going to implement a way to catch and share flows in StateFlow ( check here ) so, hopefully, this will be fixed soon.

:rotating_light: Channels are somewhat equivalents of RxJava Subjects. Previously we could use ConflatedBroadcastChannel instead of BehaviorSubject and BroadcastChannel instead of PublishSubject . But with introduction of StateFlow it comes a bit more interesting, as channels seem not that good (open question). Maybe in the future in the standard library there will be something else for PublishSubject as well.

And yes, this API is experimental, so it can be changed at any time.

:rotating_light: Over time many of the ExperimentalCoroutinesApi are promoted to the next level. But now they are FlowPreview which guarantee neither binary nor source compatibility. The simplest examples are debounce and flatMapMerge . They are in preview now.

So, yes, now you will face fewer ExperimentalCoroutinesApi methods, but still many of them are not stable.