Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 8
Я долгое время использовал Moxy, и меня не покидало ощущение, что с этим ViewState я делаю абсолютно тоже самое что и в MVVM. 99% времени я использовал только AddToEndSingleStrategy и OneExecutionStateStrategy (как наверное и все пользователи этой библиотеки).
@StateStrategyType(AddToEndSingleStrategy::class)
fun switchProgress(show: Boolean)
// Тоже самое что и
val progress: LiveData<Boolean> // или BehaviourRelay / StateFlow@StateStrategyType(OneExecutionStateStrategy::class)
fun showToastError()
// Тоже самое что и
val toastError: SingleLiveEvent<Unit>В итоге с кодогенерацией получался некий мост между MVP и MVVM, когда ViewState всегда хранил актуальное состояние экрана и выступал в роли ViewModel, на которую "подписывалась" View, а Presenter менял состояние через ViewState. Так нужен ли этот мост сейчас, когда есть LiveData (либо любой другой Android-независимый Observable) и ViewModel? (раньше точно нужен был, т.к. в то время Jetpack'a еще не было)
Что использовать — MVP или MVVM — дело вкуса и поставленной цели.
Хоть внутри MVP c Moxy и напоминает MVVM, но снаружи, т.е. для пользователя библиотеки, это чистый MVP.
Отсюда и все преимущества MVP — более тщательное покрытие unit-тестами поведения UI. С MVVM можно протестировать модель, но не как она используется в имплементации.
Например, в случае MVVM, в модели может быть метод типа fun getData(): Data. Мы можем протестировать unit-тестом что вернул этот метод, но не то, как его использует View.
В случае с MVP в presenter не может быть get-методов. View очень глупая и только presenter говорит View что делать, а значит можно тщательнее протестировать поведение UI unit-тестом presenter'а.
Так что если покрытие тестами — не важно, то можно использовать MVVM. Если важно — то лучше MVP.
Хоть внутри MVP c Moxy и напоминает MVVM, но снаружи, т.е. для пользователя библиотеки, это чистый MVP.
Отсюда и все преимущества MVP — более тщательное покрытие unit-тестами поведения UI. С MVVM можно протестировать модель, но не как она используется в имплементации.
Например, в случае MVVM, в модели может быть метод типа fun getData(): Data. Мы можем протестировать unit-тестом что вернул этот метод, но не то, как его использует View.
В случае с MVP в presenter не может быть get-методов. View очень глупая и только presenter говорит View что делать, а значит можно тщательнее протестировать поведение UI unit-тестом presenter'а.
Так что если покрытие тестами — не важно, то можно использовать MVVM. Если важно — то лучше MVP.
Например, в случае MVVM, в модели может быть метод типа fun getData(): Data. Мы можем протестировать unit-тестом что вернул этот метод, но не то, как его использует View.
Ну я скажу что в случае с MVP вы так же можете протестировать только то, что презентер сунул данные во view, но не то, как view эти данные использовала
можно тщательнее протестировать поведение UI unit-тестом presenter'а
Тесты presenter не могут проверить правильность реализации view (даже самой глупой).
Я тоже искал возможность сделать view максимально глупыми, чтобы как раз избежать тестирования UI, но потом обнаружил, что проще писать Espresso-тесты и запускать их на Robolectric, чем пытаться избежать этого, усложняя взаимодействие view и presenter.
Вспомнил 2016, когда я перепробовал разные архитектуры для Android, вздрогнул.
Потом вспомнил, как классно всё на JS-фронтенде, где я живу сейчас, порадовался. Потом подумал — а почему до сих пор на Андроиде живут, по сути, в парадигме контроллеров-вью, когда Redux-архитектура была бы намного удобнее, особенно учитывая тот факт, что на мобилках у нас вью постоянно умирает?
Погуглил немного и снова убедился, что я не самый умный человек на Земле и люди уже давно написали даже библиотечки, как под iOS, так и под Android. Ключевые слова
— ReKotlin (Android)
— ReSwift (iOS)
Ключевая особенность Redux-архитектуры — вся логика живет отдельно от вью. Не куча вью каждый со своими презентарами, а вообще отдельно. Есть абстрактный слой с общим состоянием приложения. Есть абстрактная логика обработки. View только подписываются и отписываются от состояния.
У Redux в его подробной нынешней формулировке есть вещи, с которыми я не согласен и о которых умолчу, но сама концепция, что всё состояние приложения хранится в одном месте, а логика живёт отдельно от View и по сути обрабатывает запросы на изменение состояния по паттерну Команда (что даёт заодно гибкие возможности по Undo/Redo) — она даёт намного, намного меньше кода, чем классический подход «1 экран — от 3 обязательных файлов и больше». Будет 1 экран — 1 файл (View), которое подписывается на логику.
Попробуйте, может понравиться. Я признаю, что сам еще не пробовал Redux в Android, некогда ) Но судя по появлению библиотек — люди уже пробуют и находят более мощным и удобным, чем классические MVP, MVVM и тд, и тп
Потом вспомнил, как классно всё на JS-фронтенде, где я живу сейчас, порадовался. Потом подумал — а почему до сих пор на Андроиде живут, по сути, в парадигме контроллеров-вью, когда Redux-архитектура была бы намного удобнее, особенно учитывая тот факт, что на мобилках у нас вью постоянно умирает?
Погуглил немного и снова убедился, что я не самый умный человек на Земле и люди уже давно написали даже библиотечки, как под iOS, так и под Android. Ключевые слова
— ReKotlin (Android)
— ReSwift (iOS)
Ключевая особенность Redux-архитектуры — вся логика живет отдельно от вью. Не куча вью каждый со своими презентарами, а вообще отдельно. Есть абстрактный слой с общим состоянием приложения. Есть абстрактная логика обработки. View только подписываются и отписываются от состояния.
У Redux в его подробной нынешней формулировке есть вещи, с которыми я не согласен и о которых умолчу, но сама концепция, что всё состояние приложения хранится в одном месте, а логика живёт отдельно от View и по сути обрабатывает запросы на изменение состояния по паттерну Команда (что даёт заодно гибкие возможности по Undo/Redo) — она даёт намного, намного меньше кода, чем классический подход «1 экран — от 3 обязательных файлов и больше». Будет 1 экран — 1 файл (View), которое подписывается на логику.
Попробуйте, может понравиться. Я признаю, что сам еще не пробовал Redux в Android, некогда ) Но судя по появлению библиотек — люди уже пробуют и находят более мощным и удобным, чем классические MVP, MVVM и тд, и тп
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MVP для Android — преимущества использования Moxy в качестве вспомогательной библиотеки