Все очень плохо.
По поводу минусов MVP
1.
а. Создание интерфейса View, данные подход помогает в будущем с легкостью поменять реализацию без боли.
б. Сам интерфейс также помогает читать код, посмотрев на View можно предположить что происходить на экране, если это контракт то еще лучше.
в. Если писать код по clean arch, на пакете фичи его presentation слое будет и сам экран(фрагмент или активити) и его View с Presenter, никакой сложной навигаций.
2.
Соглашусь что презентер привязан сильнее к View. Однако переиспользовать Presenter отдельного экрана не стоит. Также это относится и к ViewModel. Проблема в том что логика отображение меняется с изменением бизнес логики, то есть приходится много менять код либо в Presenter-е либо в ViewModel, из за этого обычно больших проектах они очень толстые. Стоит завести Interactor и там прописать бизнес логику и переиспользовать, но отображение должно быть разным.
3.
а. Соглашусь что ViewModel очень упрощяет разработку. Но реализация LiveData где хранятся данные, почти такая же как и ViewState.
б. У presenter-а должны быть методы которые вызываются при onPause где и должны запросы останавливаться. В onResume заново запращивать или делать какую то другую логику. Что и в подходе с ViewModel необходимо реализовывать, остановку запросов в onCleared. Также и в onPause и onResume отписываться и заново подписываться к обсерверам, соответственно.
По поводу минусов MVP
1.
а. Создание интерфейса View, данные подход помогает в будущем с легкостью поменять реализацию без боли.
б. Сам интерфейс также помогает читать код, посмотрев на View можно предположить что происходить на экране, если это контракт то еще лучше.
в. Если писать код по clean arch, на пакете фичи его presentation слое будет и сам экран(фрагмент или активити) и его View с Presenter, никакой сложной навигаций.
2.
Соглашусь что презентер привязан сильнее к View. Однако переиспользовать Presenter отдельного экрана не стоит. Также это относится и к ViewModel. Проблема в том что логика отображение меняется с изменением бизнес логики, то есть приходится много менять код либо в Presenter-е либо в ViewModel, из за этого обычно больших проектах они очень толстые. Стоит завести Interactor и там прописать бизнес логику и переиспользовать, но отображение должно быть разным.
3.
а. Соглашусь что ViewModel очень упрощяет разработку. Но реализация LiveData где хранятся данные, почти такая же как и ViewState.
б. У presenter-а должны быть методы которые вызываются при onPause где и должны запросы останавливаться. В onResume заново запращивать или делать какую то другую логику. Что и в подходе с ViewModel необходимо реализовывать, остановку запросов в onCleared. Также и в onPause и onResume отписываться и заново подписываться к обсерверам, соответственно.