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:
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
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
flatMapMerge . They are in preview now.
So, yes, now you will face fewer
ExperimentalCoroutinesApi methods, but still many of them are not stable.