flatMap () и порядок событий — RxJava FAQ

Как мы уже обнаружили, flatMap() не сохраняет порядок исходного потока. Давайте проиллюстрируем это на примере API GeoNames из предыдущей статьи :

Запрашивая население нескольких городов с помощью flatMap() мы не гарантируем, что они будут доставлены в следующем порядке:

Вывод несколько удивителен:

Через некоторое время мы получаем ответ для Мадрида, затем Лондона, который позже получает подписчик. 7556900 (население Лондона) и 3255944 (Мадрид) идут первыми. Через некоторое время прибывают также Париж и Варшава. С одной стороны, хорошо, что мы можем приступить к каждой популяции сразу после ее прибытия. Это делает систему более отзывчивой. Но мы что-то потеряли. Входным потоком были "Warsaw" , "Paris" , "London" , "Madrid" тогда как результирующий поток содержит население "London" , "Madrid" , "Paris" , "Warsaw" . Как мы можем сказать, какое число представляет какой город?

Очевидно, что следующее решение совершенно неверно , но оно не является неслыханным в реальных базах кода:

Он компилируется, работает, он даже дает некоторые результаты. К сожалению, эти результаты совершенно неверны:

Мы объединяем города с некоторой случайной перестановкой населения. Что еще хуже, мне удалось получить неправильные результаты после десятка попыток. По какой-то причине эта программа работала на моей машине большую часть времени. Худший вид ошибки, которую вы можете себе представить.

Проблема с flatMap() заключается в том, что он теряет исходный запрос. Представьте себе асинхронную систему, в которой вы получаете ответ в какой-то очереди, но не знаете, что это был за запрос. Очевидное решение состоит в том, чтобы каким-то образом прикрепить какой-либо идентификатор корреляции или даже весь запрос к ответу. К сожалению, populationOf(String city) не возвращает исходный запрос ( city ), только ответ ( population ). Было бы намного проще, если бы он возвращал что-то вроде CityWithPopulation значения CityWithPopulation или даже Pair<String, Long> . Итак, теперь представьте, что мы улучшаем оригинальный метод, прикрепляя запрос ( city ):

Теперь мы можем воспользоваться этим методом для большого потока городов:

… или чтобы избежать дополнительного вспомогательного метода:

На этот раз переменная result — Pair<String, Long> но вам рекомендуется использовать более выразительный объект значения.

Я обнаружил, что flatMap() с вложенным map() добавляющим дополнительный контекст, является наиболее эффективным способом борьбы с flatMap() результатами. Конечно, это не самый читаемый кусок реактивного кода, поэтому убедитесь, что вы скрываете эту сложность за некоторым фасадом.

ОБНОВИТЬ

Как отметил Давид Карнок в своем комментарии к этому посту , оператор map() внутри flatMap() является настолько распространенной идиомой, что существует специальная перегрузка flatMap() . Помимо стандартной функции преобразования (в нашем случае String -> Flowable<Long> ) она также принимает би-функцию комбинатора (например, (String, Long) -> SomeType ). Цель этой функции — предоставить преобразование, которое объединяет входной элемент с каждым выходным элементом, сгенерированным преобразованием. Это именно то, что мы сделали с вложенной map() (обогащение населения названием города, которому она соответствует), но намного короче:

Второе лямбда-выражение ( (city, pop) -> Pair.of(city, pop) ) выполняется для каждого последующего события, генерируемого (city, pop) -> Pair.of(city, pop) populationOf() . Если вы идете до крайности, вы можете использовать ссылки на методы:

Найдите минутку, чтобы изучить последний пример, на самом деле это очень просто:

• для каждого city найти свое население pop
• для каждого населения объедините его с city , сформировав Pair<String, Long>

PS: это был 200-й пост за 9 лет!