Ситуация все таже. Сейчас прихожу к тому, что добавив воспроизведение и паузу анимации в фрагмент сам (ровно как и если из презентера вызывать их), возникает сложность с тем, что происходит быстрая смена onPause на onResume и снова на onPause. Лишние операции, но все бы нормально, если бы Value Animator  возобновлял бы работу с того места, где он останавливается. В итоге через раз его прогресс видимо из-за быстрой смены уезжает вперёд на 20-50%.

Если начинаю вызывать debounce на rxjava для исключения лишних вызовов onResume и onPause, то по идее анимацию теперь нужно вызывать из презентера, переключившись на главный поток, а такое переключение занимает время. Из чего следует, что пауза анимации выполняется иногда после onStop уже...

Чтобы анимация воспроизвелась с того места, где остановилась, даже после быстрой смены состояний фрагмента

Никто не запрещает использовать во фрагменте RxJava (:
// DJI не постеснялись и в кастомные вьюшки засунули RxJava...

А если серьезно, то надо смотреть код, так как немного странное поведение. Может с FragmentManager что-то не то, либо как-то странно сделана анимация

Ооохх... Спокойно заснуть будет не просто 😄

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

Звучит костыльно...

Реализовать можно, конечно, со @SkipStrategy, но нужно ли так изворачиваться?..

Вот уже попробовал сделать getViewState для паузы и воспроизведения. Value animator успевает отрабатывать до onStop, все хорошо. Происходит следующее: после onPause, onResume, onPause, onResume (где переход со второго состояния на третье происходит очень быстро), value animator некорректно рассчитывает значение прогресса. Т.е. прогресс корректен на втором состоянии и третьем, а после последнего onResume выдает иногда странное значение...

я может чего не понял, но как связана анимация и частые вызову onPause?

Вот в том то и дело, что по идее значение прогресса рассчитывается внутри самого аниматора. Но ощущение, что есть какой-то внешний фактор, который влияет на этот прогресс

Причем если просто onPause и onResume с паузой/воспроизведением анимации, все отрабатывает корректно, прогресс тот, который был

Прогресс получаю по getAnimatedValue

Это наверно, не столь ситуация с moxy, но если пробую выкинуть эти лишние обработки, то появляется задержка, которая при простом сворачивании фрагмента не позволяет иногда выполнить getViewState до onStop...

Добрый день!

Есть фрагмент
class ThemesListFragment extends MvpAppCompatFragment implements ThemeListView {...}

Где интерфейс:
interface ThemeListView extends MvpView  {...}

Фрагмент содержит презентер
@InjectPresenter
ThemesListPresenter mPresenter;

И есть такое:
@ProvidePresenter
ThemesListPresenter providePresenter(){
  return new ThemesListPresenter(....);
}

Сам презентер такой:
@InjectViewState
сlass ThemesListPresenter extends MvpPresenter<ThemeListView> {...}

В целом работает. Но есть проблема.
1. Открываю диалог для выбора файла через Intent.ACTION_GET_CONTENT
2. Выбираю файл с Google.Drive
3. При закрытии диалога и возврата к моему фрагменту - презентер почему-то пересоздается.
В чем может быть причина?
Странно, что при дебаге иногда презентер не пересоздается и работает нормально.

Так ты же в providePresenter создаёшь новый экземпляр презентере,  вот он и пересоздается.

Он разве не должен жить до реальной смерти активити? Я думал, что providePresenter нужен только для передачи агрументов через конструктор презентера?  
А что делать с этим?

Так и должно быть

С помощью providePresenter я кастомизирую создание презентера, разве это должно влиять на логику его жизненого цикла?

В этой ситуации, презентер не должен пересоздаваться, по идее.
Don't keep activities не включено в опциях разработчика?

>1. Открываю диалог для выбора файла через Intent.ACTION_GET_CONTENT
>2. Выбираю файл с Google.Drive

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