Комментарии 9
В корутинах есть важное преимущество перед операторами в RxJava/Reactor: все операторы могут быть асинхронными. Т.е. можно написать что-то вроде:
.map { httpUrl -> loadRemoteData(httpUrl }Если loadRemoteData асинхронный, то можно делать неблокирующий pipe.
Однако есть еще важное отличие тех же корутин от RxJava/Reactor: корутины создаются "горячими" (сравнение горячих и холодных подписок). То есть когда вы возвращаете produce { ... }, вы можете начать публиковать данные до того, как на канал подпишутся.
В отличии от Kotlin Channels, в классических холодных Observable вы возвращаете класс, на который:
- Пока не подпишутся — публикации не запустятся
- Если будет пять подписчиков, то метод "onSubscribe" вызовется пять раз, т.е. будет пять независимых каналов. Однако в Channels все пятеро подпишутся на один канал и будут драться за данные
В RxJava для этих целей есть Connectable Observable и Subject
Что насчет combineLatest ?
А как насчет back pressure в корутинах?
Автор — "Использование rxJava для вызова асинхронных методов — оверхед"
Тоже автор — "Тут я написал базовый класс для UseCase"
Если рассматривать «RxJava» как единственное на чем замыкается данная технология то это изначально не правильный подход. «Rx» это гораздо большее чем одна библиотека. Rx поддерживает множество языков. Если вы переключаетесь между 3-4 языками каждый день то это достаточно экономит время на унификации подхода.
С помощью корутин вы можете выполнить все тоже самое (ну или почти тоже самое) что и с помощью Rx. Допустим Observable.withLatestFrom(Observable.timer(...), somePublishSubject). Мне кажется что данная конструкция на корутинах будет выглядеть слегка странно.
Однако, любая технология должна использоваться под нужны. Если в нашем приложении просто запросы на API и маппинг в обьект — зачем усложнять если корутины идут из коробки.
Обе технологии имеют право и место на существование.
Как я заменил RxJava на корутины в своем проекте и почему вам вероятно также стоит это сделать