bigbone

bigbone copied to clipboard

By replacing RxJava code with Kotlin coroutines, we can get rid of one big dependency.

Also coroutines code is easier to understand.

More details following.

Check this out: https://www.codemotion.com/magazine/frontend/mobile-dev/async-code-on-kotlin-coroutines-vs-rxjava/

~~A good first step could be using the bridging utilities of kotlinx-coroutines-rx3 which allow you to turn Rx Flowable/Observable/Maybe/Single/Completable into Kotlin equivalents and vice versa.~~

~~This could allow you to first change the outward-facing interface to use Coroutines and then give you time to do the actual implementation using “plain” Coroutines little by little.~~

~~Smaller pull requests for each change would also be a result of that approach as otherwise, you’d have one mega PR with loads of changes across many, many files.~~

~~Not sure which one you’d prefer though. 😊~~

I wrote this before actually checking the code base a bit more. As the Rx functionality is in a separate module anyway, my suggestion doesn’t make too much sense.

What should the suspend functions return then?

1. Unit (Completable), the previously wrapped type (Single), Kotlin Flows (Observable/Flowable) and exceptions are thrown
2. Arrow’s Either with an error type as the Left, and the aforementioned types as the Right
3. Kotlin’s Result, which would be similar to Either, but more bare-bones

Thinking about it a bit more: How well can Coroutines be used from Java? Maybe we should just have an additional module for coroutines? (We should then upgrade RxJava to v3 though as v2 is end of life)

Interoperability is a major concern here, true. I have opened this issue to find out / research, whether there are better ways of implementing bigbone-rx than RxJava. But if the answer is, RxJava is still the way to go, because it is easy to use from Java, and is still supported and accepted, then that is fine for me of course.

I have found this interesting article this morning: https://kt.academy/article/cc-other-languages

I think, what we are doing is not so bad.

P.S. We are already on RxJava 3 (3.1.8).

Opinions?

I’m not sure about the current landscape of Java development. I’ve been a Kotlin-only Android developer for the last few years, and even before that I solely developed Android apps and never Java (enterprise) apps where surely other restrictions or preferences apply (e.g.: Guava might be used heavily where Android apps at least in the past tried to not use it due to its massive method count and overhead).

The Coroutines-to-Rx bridge works quite well, I can say from personal experience. So that could be an option for us to recommend instead of trying to keep two implementations—both Coroutines and Rx.

P.S. We are already on RxJava 3 (3.1.8).

Whoops, missed that. Even better. 👍