События на базе LiveData Android

[agent10]

Почему не RX? LiveData это же не до RX.
Под требования «оповещает только активных подписчиков, в момент подписки не оповещает о предыдущих данных» в RX уже всё есть. PublishProcessor

[proninyaroslav]

Для тех проектов, где применяют mvvm и тащить rx ради фетчинга данных из базы или сети нет смысла, и при этом всё несколько проще чем в rx.

[agent10]

rx никак не связан с MVVM. Как раз сейчас у меня в одном из проектов MVVM вместе с Rx. Rx всё таки обладает более полноценной поддержкой ReactiveStreams. Всякие zip, combineLatest и многие прочие другие операторы…

[ar2code]

Я пишу большую статью об архитектуре и дизайне Android – приложения, где собраны многие инструменты: ViewModel, LiveData, RX и т.д. Там я отвечу на этот вопрос подробно. Но, если коротко, то RX используется, например, внутри UseCases или провайдеров для асинхронной работы, маппинга и прочих прелестей, которые дает RX. Но когда данные выводятся пользователю, то данные прослаиваются через LiveData. И именно эта прослойка позволила избежать множества ошибок, связанных с жизненным циклом. Поэтому статья про события на основе LiveData, если нужно опять же работать в контексте жизненного цикла. А других независимых способов передачи событий полно: RX, какой-нибудь EventBus, что угодно.

[agent10]

Не понял, либо использовать везде rx либо LiveData. Если использовать и то и то, то опять будет эта граница с проблемами ЖЦ.

[ar2code]

Нет, смотрите: если грубо, сделайте во ViewModel вызов RX, внутри subscribe, когда RX успешно вернула результат своего запроса, данные выведите в LiveData. А LiveData уже сам оповестит своих подписчиков, если такие есть, т.е. где-то в фрагменте есть подписка на эту LiveData. И с ЖЦ проблем нет. Например, такой кейс: RX возвращает данные в момент переворота девайса, View уже уничтожена, если бы вы напрямую из RX обновляли View, то будет ошибка. А так, с LiveData, все пройдет как надо, переворот девайса завершится, View будет создана заново, и View обновит свое состояние из LiveData. LiveData и RX работают вместе.

[agent10]

1) У вас также будет проблема кто будет вызывать dispose() в RX
2)

View уже уничтожена, если бы вы напрямую из RX обновляли View

Тут не так, в этом случае есть другая прослойка в виде того же DataBinding. Поэтому RX меняет View не напрямую, а через DataBinding. В этом случае LiveData уже лишняя

[ar2code]

1. Не вижу проблемы, вызываем Dispose, операция просто отменяется
2. Тогда вы заменяете LiveData на DataBinding, а не LiveData на RX. В общем, такой вариант тоже рабочий, никто с этим не спорит.

[proninyaroslav]

Вопрос в том, целесообразны ли эти лишние конвертации, или проще везде использовать rx. Всё зависит от задачи.

[ar2code]

Да, абсолютно с вами согласен. Все всегда зависит от задачи, вариантов решения может быть множество, в статье я описал лишь один из них.

[anegin]

Целесообразно, когда приложение модульное, и не хочется тянуть в domain/data модули андроидовские зависимости (LiveData)

[proninyaroslav]

Ну так можно и не использовать livedata, его пока не навязывают как обязательную зависимость. Я имел ввиду что не всегда имеет смысл работать с livedata, если в проекте уже rx.

[advance]

Почитал ветку. Попробую дать наиболее корректный ответ.
Rx (если говорить об RxJava) не только про реактивщину, но еще и про функциональщину.
Функциональный подход имеет свои преимущества и недостатки в равной степени с другими. Если Вам функциональный подход больше нравится- то да, возможно, LiveData Вам использовать смысла нет.
Зато LiveData хорошо стыкуется с корутинами (которые, на сегодняшний день, являются рекомендуемым подходом к построению многопоточности). Такая связка хорошо укладывается в императивный или декларативный стиль.
Сам имел опыт работы с приложениями, построенными на Rx (включая mvp на rx). И связка Android Architecture Components + корутины, на мой личный взгляд, имеет больше преимуществ.

[ar2code]

Потому что нужна привязка к LifecycleOwner. Нужно получать сообщения, когда LifecycleOwner активен. RX может прислать событие уже после того, как LifecycleOwner будет уничтожен. У LifecycleOwner много нюансов. Когда появились LiveData, жить с фрагментами и активити стало заметно легче.

[proninyaroslav]

Разве в rx после dispose(), к примеру, в onStop(), будет продолжать отправлять события?

[agent10]

Но надо в ручную дёргать dispose(). А LiveData сама обработает состояния из LifecycleOwner

[ar2code]

В общем, можно вызвать самому dispose. Но LiveData и сделана для того, чтобы нам забыть про ручную обработку жизненного цикла. Кстати, не всегда dispose решает некоторые тонкие моменты. Например, если использовать LiveData, то после OnStop, данные придут в LiveData, и при следующем OnResume наш observer сработает и мы увидим сообщение. RX и LiveData решают разные задачи, на мой взгляд.

[anegin]

Например, если использовать LiveData, то после OnStop, данные придут в LiveData, и при следующем OnResume наш observer сработает и мы увидим сообщение.

Для этого в Rx есть BehaviorSubject/BehaviorProcessor — хранит текущее значение и возвращает его сразу при подписке на него (и само собой все последующие изменения тоже эмитит)