Нужно ли хранить презентер MVP?

#android #mvp

В разных описаниях архитектуры MVP встречал разный подход к хранению\уничтожению
presenter. Кто-то сериализует его, и затем в onCreate() восстанавливает. Кто-то никак
не сохраняет и каждый раз в  onCreate() создает новый. 

Вопросы:


Зачем кто-то хранит peresenter, в нем ведь никогда не будет закешированных данных.
Плюс, который я вижу, это не тратить каждый раз ресурсы на создание нового presenter
в onCreate(). Но вместо этого нам придется каждый раз сериализовывать и десераилизовывать
его. Оно того стоит?
Зачем некоторые перед созданием presenter проверяют поле mPresenter в нашей вьюхе
на null, ведь если вызывается onCreate(), то вьюхи либо не было никогда, либо она была
уничтожена вместе со всеми полями и
mPeresnter в любом случае будет null.
Зачем вызывается detachView() в onDestroy(), если после
уничтожения активити ссылка на presenter перестанет существовать
и GC скорее всего удалит его, вместе с ссылкой на view. Чтобы
это было не скорее всего,а наверняка?


Лучшая практика - это создавать новый presenter в onCreate() или восстанавливать
старый и атачить к нему новый экземпляр view?
    

Ответы

Ответ 1

Часто нужно чтобы презентер жил во время процесса смены конфигурации, смены ориентации
экрана, например. В этом случае какой-то длительный сетевой запрос может быть начат
при одной ориентации, а закончен быть при другой или в процессе смены ориентации. В
таких случаях презентеры хранят не в активти/фрагментах, но в отдельном месте, кое
не зависит от жизненного цикла. Например в синглтоне, коий содержит мапу с презентерами
по их ID. При таком подходе презентер создаётся если его нет в мапе, уведомляетя о
прикреплении вьюхи и об откреплении оной. Так он сможет обработать ситуацию прихода
данных во время "мёртвой вью" не нарвавшись на NPE и сможет продолжать работу пока
пересоздаётся активити.

В любом случае подходов много на разные случаи. В каких-то случаях поворотов экрана
не будет, в других же надо данные пришедшие во время поворота отобразить и используют
ViewState для хранения состояния вьюхи, кое к ней применяют после её прикрепления к
презентеру.


Ответ 2

На мой взгляд пересоздание самый простой сценарий. Умер фрагмент - убили презентер. 
Да, можно хранить в мап синглтона, а можно доверить управление жизненным циклом презентера
dagger с его скоупами. Тогда останеться только аттачить и детачить созданные и убиваемые
вью к презентерам.
Хороший подход использовать вместо presenter новый компонент viewModel с его liveData.
Можно очень просто сэттить закешированные данные если вью умерало и восстанавливалось.
ViewModel не привязано к жизненному циклу вью. очень удобно. 
Для сэттинга закешированных данных классно использовать паттерн MVI. Подробно есть
в блоге Тинькофф на хабре.