Comments 35
Сразу две статьи про архитектуру Android приложений. Будет чем занять себя на выходные.
Moxy довольно легко расширяется до VIPE®. Правда, Router там особо не нужен, но может и он войдёт.
Разница между статьями в том, что эта статья – про архитектуру. А статья про Moxy – больше про то, как используя Moxy построить приложение, подходящее под паттерны MVP & Co. Так что эта статья вам очень пригодится ;)
Разница между статьями в том, что эта статья – про архитектуру. А статья про Moxy – больше про то, как используя Moxy построить приложение, подходящее под паттерны MVP & Co. Так что эта статья вам очень пригодится ;)
Молодцы! Давно ждал когда кто-нибудь выложит хоть какой-то материал по VIPER в Android.
P.S. Статейку бы подкрепить полезными ссылками по теме.
P.S. Статейку бы подкрепить полезными ссылками по теме.
Вот зачем? давайте тогда уже MVVM — это лучше будет чем вайпер. На сколько я знаю VIPER мало где прижился и кто его использует…
MVVM — это вырожденная форма MVP, где VM несколько интерактивней работает с View нежели Presenter, поэтому если для какой-то View необходима большая отзывчивость, например форма с валидацией полей, то Presenter можно заменить View Model, VIPER же, это несколько более широкое понятие, где помимо MVP есть Interactor и Router.
Почему мало где прижился?
Очень приятно, что статья оказалась полезной :) про реализацию VIPER в Android действительно очень мало материала, но если внимательней посмотреть, например, на android clean architecture, то можно увидеть что, там реализуется этот паттерн, правда Router называется Navigator :)
А полезные ссылки были набросаны по ходу статьи) Но наверно вы правы лучше вынести в отдельный блок, спасибо.
А полезные ссылки были набросаны по ходу статьи) Но наверно вы правы лучше вынести в отдельный блок, спасибо.
А почему Router в Activity? Мне кажется он должен быть в Presenter.
Странно, что View может управлять переходами.
Странно, что View может управлять переходами.
Router и так находится в Presenter, просто в данном конкретном случае Router осуществляет навигацию между фрагментами в Activity, соответственно ему необходимо знать об Activity для добавления фрагментов в back stack, поэтому для удобства интерфейс Roter имплементит MainActivity, но конечно это может быть и отдельный класс, у нас во многих проектах — это, как раз, отдельный класс.
А как вы боритесь с жизненным циклом Fragment/Activity?
У Presentor есть соответсвующие методы, в данном случае onStart, onStop достаточно, но можно расширить.
1. Вы каждый раз пересоздаете Presenter?
2. Почему только Start/Stop?
2. Почему только Start/Stop?
1. Presenter создаётся в onActivityCreated во фрагменте, так как в этот момент уже произошло onCreateView и мы можем работать с визуальными контролами
2. В onStart Presenter уже создан и View готова, можно например уже запустить первичную загрузку данных, в onStop фрагмент уже не виден пользователю, поэтому можно освободить ресурсы
2. В onStart Presenter уже создан и View готова, можно например уже запустить первичную загрузку данных, в onStop фрагмент уже не виден пользователю, поэтому можно освободить ресурсы
Start/Stop вызывается довольно часто, к примеру при переходе к следующей Activity у текущей будет вызван Stop, а потом при возвращении будет вызван Start, в итоге если в Presenter мы грузим данные при onStart будут выполнены лишние запросы.
Тут все от реализуемого use case зависит, в любом случае если у Аctivity вызвался onStop, то её состояние лучше сохранить и в onStart восстановить, а как мы будем его восстанавливать: делать запрос к серверу или локальной БД решить должен Interactor
ОК, а что делать с данными которые не закешированы.
Чтобы не потерять их при смене конфигурации, я обычно кладу их в Bundle.
Однако при использовании данного подхода, Activity/Fragment не лучшее место для сохранения состояния.
Чтобы не потерять их при смене конфигурации, я обычно кладу их в Bundle.
Однако при использовании данного подхода, Activity/Fragment не лучшее место для сохранения состояния.
Закешировать)
Хорошее предложение, но бывают результаты, которые не нужно кешировать. Они нужны здесь и сейчас.
Хотелось бы рассказать как мы решили этот вопрос в Moxy (т.к. мы решили что это главная проблема, которая стоит перед нами) — View аттачится в onStart(только если до этого был onCreate), а детачится в onDestroy. Так и утечек памяти нет, и лишний раз не применяются команды ко View из ViewState. В то же время, т.к. ViewState храниться в Presenter, а не во View, он не должен быть сериализуемым :)
Это все хорошо, но использовать библиотеку для построения Архитектуры…
За это дядюшка Боб может и в угол поставить))
За это дядюшка Боб может и в угол поставить))
А что такое VIPER? по сути это все та же Архитектура Дядюшки Боба.
Зачем только для нее новое название придумали? Из-за Router?
Зачем только для нее новое название придумали? Из-за Router?
Что такое «реактивное» программирование? С React.js оно никак не связано?
И кто такой «Presenter»? Очень похож на ViewModel в MVVM.
И кто такой «Presenter»? Очень похож на ViewModel в MVVM.
Жаль нету ссылки на проект.
А Interactor получается является оберткой над observable? Если я правильно понял по базовому interactor'у, то он являпется связным между презентером и datalayer, а так же берет на себя работу по созданию observable. В таком случем Presenter, только хранит состояние фрагмента и прокидывает полученые данные с interactor'а в view?
А Interactor получается является оберткой над observable? Если я правильно понял по базовому interactor'у, то он являпется связным между презентером и datalayer, а так же берет на себя работу по созданию observable. В таком случем Presenter, только хранит состояние фрагмента и прокидывает полученые данные с interactor'а в view?
Вот ссылка на проект: https://github.com/VictoriaSlmn/Android-VIPER, а в остальном вы все поняли верно, так же в данной реализации Interactor настраивает планировщики потоков для выполнения операций в Observable и Subscription. Presenter скорее хранит не состояние фрагмента, а зависит от него, то есть в нужный момент запускает Interactor и останавливает.
Каждый Presenter использует один или несколько Interactor для работы с данными.
А можете привести пример когда одному презентеру надо несколько интеракторов? Потому что мне казалось, что как раз нужен только один, который и инкапсулирует разнообразную логику получения данных, например, один интерактор с несколькими провайдерами данных…
Sign up to leave a comment.
Android VIPER на реактивной тяге