Как стать автором
Обновить

Комментарии 5

Все таки в андроид система с жизненными циклами по сравнению с ios выглядит удобнее - передал view lifecycle owner, а эти все подписки сами отпишутся по окончании.

Так же для меня остался открытым вопрос - есть ли разделение на холодные/горячие потоки или все в одной куче?

Что там с обработкой ошибок - в rx, да и в flow есть нюансы с их обработкой.

Можно ли эту штуку тестировать - в андроид созданы отдельные rule для всего этого добра.

Спасибо за вопросы!)
В Combine есть разделение на горячие/холодные потоки, а также механизмы «ожидания» подписки до выполнения блока кода.
Также есть разные виды паблишеров, по типу эмита событий: one-shot и continuous broadcasting. Для обработки ошибок и дебага тоже есть инструмены, например, операторы .replaceError(), а также .print() и .breakpointOnError().

Ответы на ваши вопросы остались за пределами вводной части, поскольку заслуживают отдельной статьи. Мы их осветим в следующем материале о Combine.

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

Подписки удалились, а задача остановится? Если нет, то что будет при падении?

У Rx есть такая особенность, при падении задачи, у которой нет подписок, нужен глобальный перехватчик.

Еще сильно не погружался в реактивщину. Но вокруг слышу от ребят, кто ее потрогал, что сложно дебажить. Это так? Особенно, когда какая-то случайная цепочка событий дает креш. В случае с делегатами и всякими направленными архитектурами понятно, как разматывать, а тут нет. Рассуждаю пока гипотетически, буду признателен если направите, где про дебаг реактивщины почитать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий