Сохранять презентер можно с помощью дополнительного фрагмента без Вью с setRetainInstance(true). Рабочую версию можно накатать на коленке за час. Пример реализации можно глянуть в Ferro MVP

А работает ли данный подход с вложенными фрагментами? Например есть фрагмент в котором есть вьюпейджер с несколькими фрагментами. Насколько я помню, данный подход не сработает. Или я не прав?

1. Проверить можно verifyZeroInteractors(mView)
2. Аннотации можно проигнорить/не заметить

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

Про нулевую вьюшку я имел в виду, если она возможна по твоей архитектуре.
Если @NotNull - то не надо, конечно же

Верно

Кстати в Ferro еще описано как удобно работать с rx вместе с переживающим смену конфигурации презентером

Хорошо. Я посмотрю обязательно. А чем решение с ретейн фрагментами лучше допустим некого статического хранилища пресентеров? Например в application классе

Удобно отслеживать полное уничтожение экрана, плюс открываются новые возможности так как можно использовать ActivityProvider в объектах даггер скоупа экрана, к примеру для осуществления навигации

Использовать котлин)

Должны. Это удобнее в конце концов.
Через Даггер 2 это решается довольно просто. Достаточно держать в глобале ссылку на компонент, содержащий Презентер (ну и за одно всю цепочку с Интерактором, Репозиторием и другими необходимыми классами).

Посмотрел семплы. Я правильно понял, что взаимодействие с вьюшкой через фриз-менеджер возможен только в Rx варианте? В простом я сам при каждом обращении к вьюшке должен проверять ее наличие? И не слишком ли сложный жизненный цикл у презентера? У Дорфмана, кажется, была хорошая статья, где он объяснял почему презентер не должен повторять жизненный цикл активити/фрагмента.

Нам и так тяжело с ЖЦ активити и фрагмента, а тут еще ЖЦ презентера =(

Презентер же живет чуть дольше вьюхи, зачем ему свой жц

как вы отностесь к moxy ? на мой взгляд неплохое решение

Именно так сейчас и делаю. Но интересно какие ещё решения у людей есть.

Не понял какого именно экрана. Активити целого?

Стыдно признаться, все руки до него не доходят( Но обязательно поиспытываю его.
Если что, тут есть авторы мокси @senneco @xanderblinov

я еще у Мокси есть свой канал https://t.me/moxy_ru

Да, без фриза придется прийдется проверять Вью на null. Насчет жизненного цикла, это кому как удобнее. В большинстве случаев при имплементации экранов эти методы кроме onLoad не нужны. Удобно когда например потребуется обновление данных на onResume, сразу писать логику в презентере. К тому же метод onViewDetached необходим для отписки от Observables Вью. У нас  проблем с жизненным циклом презентера не было, так как все разрабы и так наизусть знают жизненный цикл экрана.