Comments 2
One of advantages of coroutines is that they are a Kotlin language feature and are evolving together with the language
Could you extend the thought? Is this only reason to migrate from Rx?
It's not the only reason, but I see it as a huge advantage.
1. As far as I am aware your can't use rxJava in Kotlin multiplatform project.
2. For example we don't return Singles from the retrofit service, we wrap responses manually in the Repository because we don't want to have a dependency on rxJava in Network module. If we would like to reuse it in another project or give it away to our clients we don't want to force them to use rxJava. With coroutines this changes as they are a feature of Kotlin language.
1. As far as I am aware your can't use rxJava in Kotlin multiplatform project.
2. For example we don't return Singles from the retrofit service, we wrap responses manually in the Repository because we don't want to have a dependency on rxJava in Network module. If we would like to reuse it in another project or give it away to our clients we don't want to force them to use rxJava. With coroutines this changes as they are a feature of Kotlin language.
Sign up to leave a comment.
RxJava to Coroutines: end-to-end feature migration