MVVM — это модификация более общего паттерна Presentation Model, со специфической реализацией автоматического связывания данных. Причем датабиндинг зависит от конкретной UI-платформы. В случае с RxPM мы имеем полуавтоматический биндинг: приходится вручную подписываться на Observable и отписываться от него. Стоит различать форму связывания, поэтому не совсем корректно называть представленный паттерн как RxMVVM.
А как вам поможет интерфейс презентера в тестировании? Протестировать вьюху? Но смысл MVP в том, чтобы вынести всю логику в презентер. Подставлять другие презентеры во вью тоже сомнительная идея. Другой презентер — другая вью — другой интерфейс у вью.
В приведенных примерах код страны захардкожен в маске, но что если я хочу форматировать номер телефона динамически, в зависимости от набранного кода страны? Аналогично с номером банковской карточки – он может быть произвольным от 12 до 19 цифр.
Мне нравится MVP. Очень хорошо себя зарекомендовала Moxy. Ничего лишнего, простая в использовании библиотека, избавляет от написания рутинного кода. Ты применяешь MVP на практике и не беспокоишься о том, как реализовать этот паттерн. Киллер-фича Moxy — это восстановление состояния. Советую!
На самом деле, в андроиде уже есть свой MVP: если из фрагмента вынести весь UI-код в кастомные View, то он по сути станет презентером. Только связь со View будет жесткая, а не через интерфейс. У такого подхода на фрагментах есть проблемы:
Фрагменты сложно тестировать, так как они тянут много android-зависимостей и самостоятельно создают View
У фрагментов сложный жизненный цикл и они умирают вместе с Activity. При поворотах можно воспользоваться setRetainInstance(true), но это не работает на child-фрагментах.
Нужно писать много рутинного кода для восстановления View
Жесткая связь со View
Про MVVM ничего не могу сказать, но писать связывание данных в xml меня напрягает. Если интересно, то мой коллега написал хорошую статью про проблемы с ним в андроиде.
Есть еще интересный паттерн Presentation Model, о котором мало кто знает и мало кто говорит. В нем нет тех проблем, что есть в MVVM, но приходится писать код связывания самостоятельно, практически для каждого свойства. Я планирую написать несколько статей о том, как его можно реализовать на андроиде.
1) По-хорошему этим должен заниматься презентер или вьюмодель. Например, хранить позицию выбранного элемента в списке. На практике это легче реализовать во вьюхе, но тогда вы не сможете протестировать восстановление состояния. Это та самая UI-логика, ради которой и создавались эти презентеры и вью-модели.
2) Нужно восстанавливать состояние вручную и проверять, что вьюха привязывается после восстановления. Запоминать команды с анимацией — плохая идея. Можно передавать команду скролла с анимацией, а в стейте сохранять без нее, только позицию.
Залил примерчик на гитхаб https://github.com/dmdevgo/RxPM-Demo
Ответил выше
Чуть позже выложу
MVVM — это модификация более общего паттерна Presentation Model, со специфической реализацией автоматического связывания данных. Причем датабиндинг зависит от конкретной UI-платформы. В случае с RxPM мы имеем полуавтоматический биндинг: приходится вручную подписываться на Observable и отписываться от него. Стоит различать форму связывания, поэтому не совсем корректно называть представленный паттерн как RxMVVM.
А как вам поможет интерфейс презентера в тестировании? Протестировать вьюху? Но смысл MVP в том, чтобы вынести всю логику в презентер. Подставлять другие презентеры во вью тоже сомнительная идея. Другой презентер — другая вью — другой интерфейс у вью.
В приведенных примерах код страны захардкожен в маске, но что если я хочу форматировать номер телефона динамически, в зависимости от набранного кода страны? Аналогично с номером банковской карточки – он может быть произвольным от 12 до 19 цифр.
Загляните в wiki, там все достаточно просто. Только про стратегии сохранения стейта почитайте отдельно.
Мне нравится MVP. Очень хорошо себя зарекомендовала Moxy. Ничего лишнего, простая в использовании библиотека, избавляет от написания рутинного кода. Ты применяешь MVP на практике и не беспокоишься о том, как реализовать этот паттерн. Киллер-фича Moxy — это восстановление состояния. Советую!
На самом деле, в андроиде уже есть свой MVP: если из фрагмента вынести весь UI-код в кастомные View, то он по сути станет презентером. Только связь со View будет жесткая, а не через интерфейс. У такого подхода на фрагментах есть проблемы:
setRetainInstance(true), но это не работает на child-фрагментах.Про MVVM ничего не могу сказать, но писать связывание данных в xml меня напрягает. Если интересно, то мой коллега написал хорошую статью про проблемы с ним в андроиде.
Есть еще интересный паттерн Presentation Model, о котором мало кто знает и мало кто говорит. В нем нет тех проблем, что есть в MVVM, но приходится писать код связывания самостоятельно, практически для каждого свойства. Я планирую написать несколько статей о том, как его можно реализовать на андроиде.
2) Нужно восстанавливать состояние вручную и проверять, что вьюха привязывается после восстановления. Запоминать команды с анимацией — плохая идея. Можно передавать команду скролла с анимацией, а в стейте сохранять без нее, только позицию.