спасибо

доклад суперский, кстати, очень полезный

Я использую, и как у автора вопроса выше такая же задача.
У меня такая логика, как срабатывает аутентификатор (ну он вызывается по 401 http error ) лезу на бак - пытаюсь рефрешить токены, если фейлится эта затея, то чищу всю пользовательскую инфу и на окно авторизации интентом перехожу

У нас к примеру на одном проекте сделали максимально просто. Мы отлавливали ошибку 401 в CallAdapterFactory ретрофита, пытались восстановить сессию, если получалось, повторяли запрос, причем для подписчика все выглядело так что запрос проходил без ошибки. Если восстановить сессию не получалось то дергали метод GlobalNavigator'a чтобы он открыл экран авторизации. Это конечно серьезное нарушение архитектуры, но как уже обсуждалось, архитектура должна помогать, а не вставлять палки в колеса, так что подобное, в порядке исключения, приемлемо. Естественно что такие вещи лучше заносить в ТехДокументацию проекта.

Кстати тут кто нибудь ведет тех документацию проекта, и из чего она у вас состоит?

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

А аутентификатор тоже позволяет повторить изначальный запрос?

Да

Спасибо, похоже я для этого свой велосипед придумал)

А как быть при 401 ошибке/expired-token'e в случае, если сворачивать тапки особо не нужно, а нужно показать экран авторизации и если юзер вошел, то продолжить выполнение всех запросов?

Я пока делал так, в аутентификаторе стартовал логин скрин, если юзер авторизоваться успешно, то ему опять показывался предыдущий экран, но запросы повторялись когда он пытался покинуть экран, если он закрывает логин, то экран либо отрисовывал новую модель для не авторизованных юзеров, либо и вовсе закрывался, если он не может быть показан не авторизованным

Есть пара вопросов по архитектуре. Влился в чатик после последнего dev подкаста и возможно вопросы обсуждались и я их пропустил.
1. https://github.com/grandstaish/hello-mvp-dagger-2 может кто-то использовал похожую архитектуру MVP, domain, interactor etc. Она в примере больше заточена под rx и хранение Subject, которое происходит в Interactor, а Presenter (пере-)подписывается на него. Я таким образом решил проблему переворота экрана и переподски на длительные сетевые операции, но ссылку на Subject пока храню в Presenter.
2. В недалеком будущем предстоит рефакторинг большого проекта с довольно сложной навигацией (стек в стеке, перепрыгивания в стеках через несколько шагов как вперед так и назад). Кто-нибудь использовал conductor (https://github.com/bluelinelabs/Conductor) или вместе в связке с Mosby (https://github.com/sockeqwe/mosby)?

Презентер должен переживать переворот.
Subject лучше не использовать (особенно в таких простых ситуациях), посмотрите доклад Матвея Малькова об Rx.

В терминах dagger2, мы тогда компонент сохраняем, который провайдит презентер и тд? кстати кто нибудь в компоненте создает например адаптер для списка?

Я презентер создаю и инъецирую через Moxy и не парюсь.
Dagger2 использую только для построения слоя модели.

а как вы стартовали логин скрин? У вас в аутентификаторе был калбэк для вызова логина? и как вы показывали ему предыдущий экран? Как восстанавливали стек?

хороший момент кстати

как вызвать аутентификацию в неожиданны момент отваливания токена

из любой точки