на самом деле их мало

Прочитал - и легко используешь, по РХ прочитал - ищешь что-бы ещё прочитать, мы тут сравниваем порог вхождения и освоение

> очень давно вожусь
> что такое мультикаст?

Эту тему даже Елизаров раскрывал в серии статей про корутины

кароч вылетаю из спора, вопрос то был про обсервер vs сингл, а как обычно в холивар уехали

Проблема в том, что

Maybe<T> ~ Single<T?>
Completable ~ Single<Unit>

А Flowable - это Observable с бекпрешуром

Проблема #2, что если выражать всё это дело вот так, то на самом деле получается монад кейк (см. mtl, Arrow-mtl) с вложенными флатмапами, которая решается нормальной системой типов. Эрго - джависты/котлинисты страдать

так часто в клиентском приложении (андроид) бекпрешер вылезает?

Понятия не имею, я просто хотел уточнить, что обзервабл не нужен

Типо любой, кто юзает каналы, должен до дыр затереть каждую статью Елизарова? Зачем? В моём кейсе всё покрывается каналами и флоу.

Если было бы только сингл и фловабл это было бы лучше, да

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

А в чем проблема собственно?
Есть некий продюсер, порождающий нотификацию.
Есть консьюмер, который её обрабатывает.

Если логика зависимого модуля зависит от количества нотификаций - это уже плохо пахнет, если честно.

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

"логика может сильно меняться в зависимости от количества событий". Вот именно это и есть странно.
А можно пример такого случая?

Ну я же писал. Возвращается одно событие написал флетмап. Внезапно стало возвращаться много

Лучше чтобы в это случае был только флетмап и сингл

И просто если событий больше чем надо это плохо. Больше перерисовки например

Ну во-первых ничего внезапоного тут нет. Вы же написали флет-мап и видимо намеренно преобразовали сингл в обыкновенный обсервабл) Решение проблемы элементарно - если вам нужен сингл с одной нотификацией - не нужно флет-мапить его наблюдаемыми , с N нотификаций и все будет здорово)

Ну я об этом и говорю. Плохо если везде только observable

нет, ничего плохого в этом нет. Это говорит, о том, что ваш код(в контексте реактивного стиля программирования) построен граммотно. И в случае изменения внешних условй(ТЗ например), когда некое событие, возникающее сегодня 1 раз за сессию, вдруг начнет возникать множество раз - вы к этому готовы.
Если же событие должно возникать 1 и только 1 раз - это уже бизнесс-правила о который собственно и должен позаботиться продюсер. Если консьюмер нуждается в предоставлении каких-то гарантий  ... я бы пересмотрел организацию кода на всякий случай.

consumer должен понимать время жизни подписки. Если допустим после нажатия кнопки создается подписка, и внезапно туда стали приходить очень долго изменения это не оч. И от этого лучше защититься