RxAndroid, автобус событие и активность Жизненный цикл

Question

Я нашел несколько статей, говорить о том, как RxJava/RxAndroid может заменить шины событий (например otto)

• https://lorentzos.com/rxjava-as-event-bus-the-right-way-10a36bdd49ba#.7a4619qva
• https://medium.com/mobiwise-blog/use-rxjava-instead-of-event-bus-libraries-aa78b5023097#.ew28h2urf

цитата из первая статья:

Отто с площади официально устарел в предыдущие дни. В мире Android мы можем подбодрить теперь что-то вроде «EventBusses мертвы долго живут RxJava».

Существует одна вещь, которую я пропускаю, хотя:

Одним из преимуществ автобусов событий является то, что они помогают много с жизненным циклом деятельности в том, что вам не нужно управлять регистрацией/регистрацией для обратных вызовов вручную (и, таким образом, избежать утечек памяти легко)

Пример потока:

• активность присоединяется к событию, для получения композиций (скажем, SongsAvailableEvent)
• Мы просим песню (мы делаем запрос сети)
• Меняют устройство ориентации в середине запрос
• Деятельность умирает, и новая построена, который также подписался на SongsAvailableEvent
• Новая активность получает событие и обновляет интерфейс, а старая активность (который теперь мертв) не получает событие (яй!)

статьи выше, делают его похожим на этот поток будет «решена» по RxAndroid/RxJava, но при использовании Rx вам все равно необходимо подписаться/отказаться от подписки на Observable вручную, когда вы измените ориентацию устройства. Более того, если я хочу «повторно использовать» запрос, сделанный в Observable, мне нужно как-то его сохранить, чтобы я подписался на тот же Observable в новом действии (я не совсем уверен, как это сделать, но это не точка :)).

Мой вопрос: эта проблема легко разрешима с помощью чистого RxAndroid/RxJava, или мне все еще нужно использовать Rx с шиной событий/расширением Rx, используя что-то вроде RxLifecycle (что усложняет ситуацию, так как я не управляю своими наблюдениями в уровень представления)?

Answer 1

Ваша деятельность onDestroy всегда может быть отписана.

Что касается работы над повторным использованием запроса - посмотрите на Loaders и LoaderManager. EventBus и RxJava решить, что никогда не было необходимо.

Answer 2

Я бы рискнул сказать, что нет никакого выхода из того факта, что в какой-то момент цепи Observable должен быть привязан к жизненному циклу какого-либо объекта платформы Android, такого как Activity. Кроме того, поскольку вы не упомянули это как частичное решение, я предполагаю, что вы избегаете использования сохраненных фрагментов. Если вы создаете и сохраняете ссылку на Наблюдаемый только в пределах своей деятельности, невозможно, чтобы результаты запроса в полете выдержали разрушение Деятельности и автоматически подписались на новый.Кроме того, в какой-то момент, либо во время изменения ориентации, либо в завершении деятельности в середине сетевого запроса, ваш Observable будет утечка ссылки на Activity (через его обратный вызов subscribe()), если он не отменит подписку на onDestroy().

Я нашел RxLifecycle прост в использовании. Моя база Activity класс имеет метод на нем:

public <T> Observable.Transformer<T,T> bindLifecycleOnMainThread() { 
    return o -> o.compose(lifecycleProvider.bindToLifecycle()) 
     .observeOn(AndroidSchedulers.mainThread()); 
} 

lifecycleProvider создается в соответствии с инструкциями для RxLifecycle, в зависимости от того, как вы создаете ваш провайдер. Эта конкретная реализация использует bindToLifecycle() вместо указания явного события жизненного цикла, поэтому ее использование является контекстуальным. Вызов его во время onResume приведет к его завершению на . Вызов его во время onStart приведет к его завершению на onStop. Вызов его в другое время приведет к его завершению на onDestroy. Поскольку эта подписка будет обновлять пользовательский интерфейс, она должна наблюдаться только в потоке пользовательского интерфейса.

, который затем может затем использоваться в деятельности следующим образом:

yourObservable.compose(bindLifecycleOnMainThread()) 
    .subscribe(event -> handleEvent(event)); 

Теперь, где же это наблюдаемое взялось? Ну, еще нет волшебства, и если вы хотите, чтобы Observable имел более продолжительный срок службы, чем Activity, это означает, что Observable должен удерживаться компонентом, который живет дольше, чем Activity. Существует много способов сделать это, но ваш конкретный пример использования хорошо отображает новую библиотеку ViewModel, включенную в структуру Android Architecture. Если бы вы использовали ViewModels, ваш ViewModel имел бы метод, который начнет сетевой запрос, и будет иметь PublishSubject или PublishRelay, который испустил бы SongsAvailableEvent объектов (хотя я рекомендую подвергать его вашей Деятельности только Observable<SongsAvailableEvent>, а не теме, для хорошая инкапсуляция!). Ваша ViewModel сделает сетевой вызов и перенаправит результаты на ваш объект.

Наконец, ваша деятельность, когда она создана, немедленно получит свой ViewModel из реестра ViewModel и подписаться на Observable<SongsAvailableEvent> (который является объектом/ретранслятором), который был открыт ViewModel, а затем привязать его к жизненному циклу Activity, как в пример выше. ViewModel выдержит любые изменения ориентации Деятельности, и поэтому будет наблюдаться. Наблюдатель никогда не будет пытаться доставить событие к уничтоженной Деятельности, и новое действие немедленно начнет прослушивать события.

Я считаю, что эта стратегия способствует хорошему инкапсуляции, поскольку Activity не относится к тому, как создается сетевой запрос, и не относится к тому, как создается источник Observable. Единственный способ, которым Activity манипулирует Observable, - это выбрать, что происходит, когда оно получает событие, и привязать подписку к жизненному циклу Activity.

Это может быть бесконечно изменено и утончено составлением ваших наблюдений, но это должно помочь вам в пути.