вот кстати в соседнем скала чате как раз про это речь и идёт - архитектурирование топ-даун вс боттом-ап

Ну тут мы уже уходим от контекста.
Смотри(давай на ты, 'те' дописывать надоело). Если я меняю тип возврата в консьюмера - я ведь меняю контракт, а не реализацию.
Возвращая observable вместо single, я отказываюсь от клнкретики касательно поведения на уровне зависимого класса.
 Конечно, мне придется учитывать это поведение в любой альтернативной имплементации. Но это будет справедливо в любом случае, что бы не скрывалось за фасадом. Даже если я впринципе уйду от rxjava в kotlin(что я собсно и сделал) ситуация не изменится.

На уровне же консьюмера мне достаточно знать, что любой observable создаст н нотификаций и завершится(ну или отвалится).
  Пока что этого было всегда достаточно и необходимости знать наперед, когда именно он завершится, у меня не возникало.
  Можешь навести пример, когда эта необходимость действительно возникает в связи с ТЗ, а не с имплементации?

Что нибудь, например адрес раньше приходил один раз от запроса, теперь приходит переодически во времени, getAddress изменился

для каждого запроса держать свой disposable неудобно

Значит есть некий Repository, DataSource, "ВашВариант", который является поставщиком адресса.
Есть набор бизнесс-правил по которым этот самый адресс может измениться.
В момент времени А эти бизнесс-правила предполагают изменение адресса один раз при регистрации пользователя к примеру.
В момент времени Б ТЗ меняется. К примеру появляется UI аля "edit user profile". Соответсвенно меняются бизнесс-правила.
А значит меняется поведение источника данных. Если для источника данных способа взаимодействия мы использовали возврат Single - мы влипли. Т.К. зависимые модули в хооде разработки могли расчитывать, на поведение "1 эммит и terminate сразу за ним".
Если мы вернули Observable - зависимые модули не могли расчитывать на конкретное поведение. А значит мы можем смело заменять Single на любой другой частный случай Observable и абсолютно легально расчитывать на то, что никаких багов это за собой не потянет.

Для каждого запроса держать свой disposable необходимо. Другой вопрос - где его держать.
Лично я предпочитаю разруливать эту логику на уровне интерактора.
К примеру "при поступлении нового запроса на выполнение, существующий процесс должен быть отменен и запущен заново с новыми аргументами". Ну или наоборот. Новый проигнорирован. Или же оба должны выполниться параллельно.

Я видел имплементации, где этим занимается слой интерфейс-адаптеров. Тоже имеет право на жизнь и свои преимущества, хотя мне лично кажется спорным.
Но так или иначе, в условиях RxJava, если есть прослушиваемая операция - должен быть disposable под нее.

Но в любом случае, где бы не жил disposable - разруливание бизнесс-правил - не его задача.
Это должно быть решено на уровне продюсера(По моему скромному, или не очень, мнению).

Консьюмеру же( в нашем случае классу,  зависимому от адресса), плевать на А и Б. Ему придет N эммитов, а потом операция завершится. Это легально как для случая А, так и для случая Б. Т.К. косьюмер работает по контракту и абстрагирован от того, что происходит в продюсере. Его интересует только результат.
На мой взгляд, это правильно.

1 Интерактор может это делать а может и нет. Он не знает о всех подписчиках и как все используется. В вашем случае нет гарантии что придет то что ожидаемо

2 Консьюмер может подписываться в двух местах, перевод сингла на фловабл  озачает что изменяется место подписки в консьюмерах, что значит те же изменения

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

Удобнее иметь для всех запросов один compositedisposable и им управлять

Если они разные для каждого запроса чистить их при повторении слишком сложно

Ну... Лично мне идея кажется очень спорной.
Если будете пробовать централизованное управление всеми запросами в одном месте - дайте знать, что из этого получилось. Любопытно жи)

Привет.
Есть библиотека авторизации через гугл. она требует Context, причем это скорее всего Activity Context. Скорее всего это нужно лишь для того, чтобы вернуть информацию в onActivityResult().
есть смысл посылать туда Application Context?
Как вообще работают с такими библиотеками? не хочется же держать эту логику на уровне представления(

sso либы обычно довольно близко к UI из-за того, что показывают свои окна пользователю. Мне нравится как сделано у фейсбука, например. Саму логику можно завернуть, но так или иначе какой-то хэндлер, коллбэк будет торчать в onActivityResult. Гугловский GoogleSignIn вроде может принимать как активити так и аппликейшн контекст.

да, я проверю, можно ли там Application Context, пока нет возможности. Просто вот этот вот результат чтобы возвращался обязательно в активити - вообще не нравится такое подход(
мельком глядел на фейсбучную авторизация - вроде примерно так же как и у гугла.

Ребят, а на сколько корректно в адаптер recyclerview прокидывать контекст? Нужно как-то получить доступ к ресурсам. Как это красиво решается?

прокидывайте с чистой совестью. Но вообще у вас View создано уже, и контекст там есть.

спасибо

а зачем его проктдывать, если можно его взять у вью?