Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Observable with multiple subscribers #14

Open
IlyaEremin opened this issue Jul 26, 2016 · 4 comments
Open

Observable with multiple subscribers #14

IlyaEremin opened this issue Jul 26, 2016 · 4 comments

Comments

@IlyaEremin
Copy link

IlyaEremin commented Jul 26, 2016

Есть один observable, на который подписаны несколько подписчиков.
При отписке любого из них observable должен останавливаться.
Смысл в том, чтобы создавать в одном месте observable и в других классах подписываться на его lifecycle, таким образом добиться модульности.
Пример: начинается загрузка и надо отображать диалог, при отмене которого загрузка прекращается.
Также надо по завершению загрузки отображать данные.
Получается 2 подписчика - экран для отображения и диалог.
Можно это сделать все внутри одного
Subscription subs = observable.doOnEach(../* закрыть диалог */.).subscribe( /* отобразить данные */...) и добавить dialog.setOnDismissListener(() -> subs.unsubscribe());
но если действия в подписчиках не самые тривиальные, это превращается в большую кучу.
И хотелось бы просто отдать lifecycle ивенты в диалог, чтобы он сам решал когда и что с собой делать.
@RuslanZakirov @RamilGabdrakhmanov ваши мысли господа.

@RuslanZakirov
Copy link

Все-таки в терминах rxjava диалог не будет обычным подписчиком. Скорее вьюшкой которая зависит от callback'ов observable. Может есть какой-то конкретный случай, который иллюстрирует неудобство обычного подхода?

@IlyaEremin
Copy link
Author

IlyaEremin commented Jul 27, 2016

Экран, после ввода логина и пароля появляется диалог ожидания, типа "Соединение с сервером".
По закрытию диалога надо отменять запрос.
При завершении\фейлу запроса надо закрывать диалог.
При завершении запроса надо отображать данные.

Неудобство в том, что если все это встраивать в один observable, то он оч большим становится. Хотелось бы о его коллегах знали в других местах, где это надо и соответственно реагировали.

@RuslanZakirov
Copy link

На мой взгляд, не такой уж это и страшно. Если по завершению/фейлу observable нужно много всего делать, то можно все вынести в отдельный метод.

Если я правильно понял идею, то добавив независимых "слушателей" которые сами будут решать, что делать, мы уйдем от функционального к императивному, т.к. добавится состояние.

@IlyaEremin
Copy link
Author

Нуок, может я лучше выражу это в коде. Мне пока самом не понятно чем это облегчит жизнь.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants