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

не совсем понял.

Если надо ещё вручную трогать mvpDelegate - то это телодвижения лишние

Просто проверьте будет ли работать так как вам надо

попробую , но не совсем понял как getMvpDelegate().onDestroy(); работает. Он вызывается во вью и уничтожает текущий презентер ?

Не знаю интересна ли эта каша, но напишу, вдруг от этого мне самому умная мысль придет)  способ с фрагмент менеджером у меня почти что сработал.. Алгоритм был такой: после ответов на все табы переход на новую активность, после по нажатию Показать ошибки, посылаю интент к прошлой активности, поднимаю ее с backStack и после onResume , зануляю текущий адаптер, у фрагментов которые в данный момент в памяти вызывается detach. сохраняю в массив нужные фрагменты из фрагмент менеджера. Очищаю все фрагменты из фрагмент менеджера, подаю новый адаптер , который берет фрагменты из массива. И беда в том, что в массиве те фрагменты которые были в памяти перед занулением адаптера, хоть и имеют нужное состояние, но при отображении , у них вызывается метод @ProvidePresenter и создается новый презентер... Я пока не понял почему так происходит именно с этими фрагментами, ведь у них ровно так же как и остальных вызвался detach.

Подскажите, а что такое могло произойти в плане жизненного цикла с экземпляром фрагмента, что у него повторно вызвался @ProvidePresenter.

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

Здравствуйте, подскажите , пожалуйста как мне для фрагмента создать свой презентер? Есть ли пример ?

ну значит это типа совсем новый фрагмент, у которого нет сэйв стейта. или до этого у фрагмента каким-то образом не был вызван сэйв стейта

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

мокси тут не при чём =) делай так, как хочешь

понял:)

Ну это ясно, просто дело в том что это не новый фрагмент. Это фрагмент в котором уже инициализировано поле презентера в котором есть нужный стейт.  Поэтому интересно стало выполняется  проверка перед тем как выполнить @ProvidePresenter. Наверно смотрится в какое то локальное хранилище презентеров

дело в сэйв стейте. а в ProvidePresenter не делается никакой проверки. Этот метод вызовется тогда, когда мокси решит, что нужно проинициализировать это поле. И решает это исключительно на основании данных в сэйв стейте. Если нужно проверку на то, проинициализированно ли поле, то это можно написать самостоятельно в теле этого метода 😉

Не хотел отдельный класс для хранения того какие кнопки чекнуты, если хранить в статик поле сам фрагмент, то опять же при использовании этих фрагментов выполняется @ProvidePresenter и поле презентера новое.  Это я только недавно понял в чем причина того что состояние не сохраняется. А так вы правы, сохранил в статик поле и когда не нужно анулировал.

Ах точно.. Можно же от себя доп. проверку замутить ) что то не подумал сразу.  Но вариант с тем чтобы сделать презентер глобальным тоже хороший. Я бы по номерам табов по тегу метил вью. Но только вопрос в том,  как очистить глобальные презентеры разом да еще и из активности на которой эти презентеры не используются?

Есть такая штука: https://github.com/Arello-Mobile/Moxy/blob/master/moxy/src/main/java/com/arellomobile/mvp/MvpFacade.java#L41 но очень не рекомендую делать через неё - сделайте нормально, через локальные презентеры + слой модели, в которой хранится то, что нужно + модел ьочищается когда надо.

Ок,спасибо