Как упоминалось в моем предыдущем блоге, RxJava упрощает многопоточность. Позвольте мне поделиться еще одним преимуществом RxJava - подключение к сетям стало намного проще.
Ниже приведены 3 сценария.
1. Сетевой вызов, зависящий от другого: flatMap
Существуют различные случаи, когда вам необходимо иметь такую цепочку, как показано на диаграмме. Например, получение сайта по URL-адресу, затем использование URL-адреса для выполнения другой выборки, затем получение токена доступа и предоставление его для второй сетевой выборки и т. Д.
Мы могли бы использовать вызов оператора flatMap
val disposable = firstNetworkCall()
.flatMap{ secondNetworkCall(it) }
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe { it -> doSomethingWithResonse($it) }
2. Подключите сетевые вызовы к одному и тому же наблюдателю: mergeWith
Предположим, мы получаем данные из двух сетей, которые не зависят друг от друга, но хотели бы передать результат одному и тому же наблюдателю.
Мы могли бы использовать вызов оператора mergeWith
val disposable = firstNetworkCall()
.mergeWith(secondNetworkCall())
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe { it -> doSomethingWithIndividualResponse($it) }
При этом будут наблюдаться данные из firstNetworkCall, а затем будут наблюдаться secondNetworkCall данные. Оба наблюдаются одним и тем же наблюдателем.
3. Объедините результаты сетевых вызовов вместе: zipWith
Иногда вместо того, чтобы отправлять наблюдателю индивидуальный результат, мы хотим объединить их перед отправкой. Это было бы очень полезно, когда нам не нужно беспокоиться об ожидании и синхронизации на стороне наблюдателя.
Мы могли бы добиться этого, используя zipWith
val disposable = firstNetworkCall()
.zipWith(secondNetworkCall(),
BiFunction{
firstResonse: ResponseOneType,
secondResponse: ResponseTwoType ->
combineResult(firstResponse, secondResponse) })
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe { it -> doSomethingWithCombinedResponse($it) }
Очень похоже на mergeWith, функция zipWith также принимает ссылку на первую наблюдаемую и вторую наблюдаемую. После подписки он сначала получает firstResponse, а затем secondResponse. После этого BiFunction используется для сбора обоих результатов, а затем вы можете объединить результат (например, функцию combineResult) перед передачей его в Observer.
Хорошо, но еще не идеально…
С flatMap, mergeWith и zipWith мы теперь могли легко связывать сетевые вызовы перед отправкой в функцию наблюдателя, которая их использует.
Отлично. Но есть один недостаток - они по-прежнему выполняются последовательно. Например. если firstNetworkCall занимает 5 секунд, а secondNetworkCall - 5 секунд, то общий процесс до достижения Наблюдателя составляет 10 секунд.
Для сценария 1 это имеет смысл, поскольку один зависит от других. Но для сценария 2 и 3 оба сетевого вызова должны выполняться параллельно.
Посмотрите ниже, чтобы узнать, как заставить их работать параллельно:
Надеюсь, этот пост будет вам полезен. Вы можете ознакомиться с другими моими интересными темами здесь.
Следуйте за мной в medium, Twitter, Facebook или Reddit за небольшими советами и изучение Android, Kotlin и т. д., связанные темы. ~ Эли ~
