Moxy. Как правильно пользоваться? / Юрий Шмаков (Arello Mobile)Ontico
РИТ++ 2017, AppsConf
Зал Касабланка, 6 июня, 16:00
Тезисы:
http://appsconf.ru/2017/abstracts/2704.html
В последнее время паттерн MVP будоражит Android-комьюнити. Уже есть несколько довольно приличных библиотек, которые помогают использовать этот подход. Но с ними вам придётся писать много boilerplate-кода. Поэтому я хочу познакомить вас с Moxy. Покажу, как использовать её компоненты для решения задач, которые будут вставать перед вами, когда вы решите использовать паттерн MVP. И расскажу, как устроены эти компоненты, и почему именно так, чтобы вы не боялись использовать Moxy из-за потенциальных подводных камней.
«Как я научился не волноваться и полюбил Android-MVP», Никита Бартишок, ABBYYMail.ru Group
Доклад о подходе к разработке Android-приложений с использованием MVP и Clean Architecture. Никита рассмотрит преимущества этого подхода перед традиционным, уделит отдельное внимание вопросам сохранения состояния в Android-MVP, а также особенностям взаимодействия между V и P.
Разработка WPF приложений в стиле ViewModel FirstDenis Tsvettsih
Презентация к докладу «Разработка WPF приложений в стиле ViewModel First» с одиннадцатой конференции dotnetconf (Челябинск, 31 октября 2015)
http://dotnetconf.ru/materialy/viewmodelfirst
Moxy. Как правильно пользоваться? / Юрий Шмаков (Arello Mobile)Ontico
РИТ++ 2017, AppsConf
Зал Касабланка, 6 июня, 16:00
Тезисы:
http://appsconf.ru/2017/abstracts/2704.html
В последнее время паттерн MVP будоражит Android-комьюнити. Уже есть несколько довольно приличных библиотек, которые помогают использовать этот подход. Но с ними вам придётся писать много boilerplate-кода. Поэтому я хочу познакомить вас с Moxy. Покажу, как использовать её компоненты для решения задач, которые будут вставать перед вами, когда вы решите использовать паттерн MVP. И расскажу, как устроены эти компоненты, и почему именно так, чтобы вы не боялись использовать Moxy из-за потенциальных подводных камней.
«Как я научился не волноваться и полюбил Android-MVP», Никита Бартишок, ABBYYMail.ru Group
Доклад о подходе к разработке Android-приложений с использованием MVP и Clean Architecture. Никита рассмотрит преимущества этого подхода перед традиционным, уделит отдельное внимание вопросам сохранения состояния в Android-MVP, а также особенностям взаимодействия между V и P.
Разработка WPF приложений в стиле ViewModel FirstDenis Tsvettsih
Презентация к докладу «Разработка WPF приложений в стиле ViewModel First» с одиннадцатой конференции dotnetconf (Челябинск, 31 октября 2015)
http://dotnetconf.ru/materialy/viewmodelfirst
Разработка Web-приложений на Angular JS. Архитектурные семинары SoftengiSoftengi
Разработка Web-приложений на Angular JS — доклад Бориса Левицкого, архитектора ПО в команде портфеля проектов Enviance компании Softengi.
Видео с докладом от автора можно посмотреть по ссылке: http://youtu.be/oTXxrmIxo8Y
Презентация ответит на вопросы:
- что такое Angular?
- для чего он используется и что с ним можно делать?
- как работает Data-Binding?
- кастомные фильтры
- структура Angular приложения
Архитектурные семинары Softengi - еженедельные встречи, на которые приглашаются ведущие разработчики/архитекторы Softengi и других компаний нашего консорциума Intecracy Group.
Все проведенные семинары мы записывали, и теперь хотим поделиться опытом и знаниями с такими же профессионалами.
Подписывайся на канал Softengi https://www.youtube.com/user/softengi и узнай первым о новых семинарах.
http://www.softengi.com
В лекции рассказано о доступных средствах по отладке веб-сайтов, их возможностях, а также способах их использования. Также речь пойдет о том, как искать ошибки у пользователей в продакшене и контролировать качество продукта.
Разработка Enterprise-приложения на основе Spring FrameworkCUSTIS
Открытый семинар для студентов в компании CUSTIS (9 апреля 2015 года).
Лектор: Вячеслав Муравлев, ведущий Java-разработчик.
Аннотация: За 11 лет своего существования Spring Framework превратился в настоящий кладезь решений типовых задач, возникающих при разработке Enterprise-приложения. Прежде чем разрабатывать свои механизмы работы с БД, авторизации и аутентификации, имитации промышленного окружения для проведения тестирования, пакетной загрузки данных, запуска заданий по расписанию, асинхронного взаимодействия компонентов системы и т. д. — посмотрите в Spring повнимательнее, там это уже есть и готово к использованию. На семинаре мы создадим Enterprise-приложение «с нуля», решая в процессе типовые задачи с помощью готовых компонентов Spring Framework.
Видеозапись семинара: https://vimeo.com/125020967.
55+1 прием для улучшения Javascript-кода / Татьяна Бабич (Simbirsoft)Ontico
В докладе будут рассмотрены приемы, практики и «фишки», которые полезно использовать для создания любого Frontend-приложения.
Мы поговорим об организации модульности и компонентов на примере приложений с Angular, React и Polymer. Обсудим, как использовать особенности JavaScript, и рассмотрим особые случаи, когда фреймворки действительно приходят на помощь.
Dnepr iOS Club #2
Speaker - Александр Колесник, middle iOS developer at WOXAPP
Тема: “MVVM vs Viper. Что и как выбирать?”
Тезисы:
- подробно разберем каждый из паттернов проектирования
- определим минусы и плюсы использования MVVM
- определим минусы и плюсы использования Viper
- проведем сравнение - определим как выбирать архитектуру для своего проекта.
Уровень: middle и выше.
Разработка Web-приложений на Angular JS. Архитектурные семинары SoftengiSoftengi
Разработка Web-приложений на Angular JS — доклад Бориса Левицкого, архитектора ПО в команде портфеля проектов Enviance компании Softengi.
Видео с докладом от автора можно посмотреть по ссылке: http://youtu.be/oTXxrmIxo8Y
Презентация ответит на вопросы:
- что такое Angular?
- для чего он используется и что с ним можно делать?
- как работает Data-Binding?
- кастомные фильтры
- структура Angular приложения
Архитектурные семинары Softengi - еженедельные встречи, на которые приглашаются ведущие разработчики/архитекторы Softengi и других компаний нашего консорциума Intecracy Group.
Все проведенные семинары мы записывали, и теперь хотим поделиться опытом и знаниями с такими же профессионалами.
Подписывайся на канал Softengi https://www.youtube.com/user/softengi и узнай первым о новых семинарах.
http://www.softengi.com
В лекции рассказано о доступных средствах по отладке веб-сайтов, их возможностях, а также способах их использования. Также речь пойдет о том, как искать ошибки у пользователей в продакшене и контролировать качество продукта.
Разработка Enterprise-приложения на основе Spring FrameworkCUSTIS
Открытый семинар для студентов в компании CUSTIS (9 апреля 2015 года).
Лектор: Вячеслав Муравлев, ведущий Java-разработчик.
Аннотация: За 11 лет своего существования Spring Framework превратился в настоящий кладезь решений типовых задач, возникающих при разработке Enterprise-приложения. Прежде чем разрабатывать свои механизмы работы с БД, авторизации и аутентификации, имитации промышленного окружения для проведения тестирования, пакетной загрузки данных, запуска заданий по расписанию, асинхронного взаимодействия компонентов системы и т. д. — посмотрите в Spring повнимательнее, там это уже есть и готово к использованию. На семинаре мы создадим Enterprise-приложение «с нуля», решая в процессе типовые задачи с помощью готовых компонентов Spring Framework.
Видеозапись семинара: https://vimeo.com/125020967.
55+1 прием для улучшения Javascript-кода / Татьяна Бабич (Simbirsoft)Ontico
В докладе будут рассмотрены приемы, практики и «фишки», которые полезно использовать для создания любого Frontend-приложения.
Мы поговорим об организации модульности и компонентов на примере приложений с Angular, React и Polymer. Обсудим, как использовать особенности JavaScript, и рассмотрим особые случаи, когда фреймворки действительно приходят на помощь.
Dnepr iOS Club #2
Speaker - Александр Колесник, middle iOS developer at WOXAPP
Тема: “MVVM vs Viper. Что и как выбирать?”
Тезисы:
- подробно разберем каждый из паттернов проектирования
- определим минусы и плюсы использования MVVM
- определим минусы и плюсы использования Viper
- проведем сравнение - определим как выбирать архитектуру для своего проекта.
Уровень: middle и выше.
В рамках доклада я хотел бы рассмотреть сложности, которые мы испытываем с построением инфраструктуры распределенных систем.
Можно ли строить приложения и не думать о серверах и контейнерах? Насколько это будет дорого?
Ответить на эти вопросы помогут принципы «Бессерверной архитектуры». На простых примерах мы рассмотрим из чего состоит приложение, не зависящее от серверов. А также, рассмотрим возможности, которые предоставляют популярные провайдеры облачных сервисов, для построения таких приложений.
Видео с доклада: http://getdev.net/Event/asp-net-mvc-4
Доклад об ASP.NET MVC, откуда и зачем он появился, какие задачи решает, какой подход к разработке исповедует. Этот доклад больше пригодится тем, кто хочет углубить и структурировать свои знания об ASP.NET MVC
Внедрение зависимостей в ASP.NET MVС и ASP.NET vNextGoSharp
По мере развития веб-проекта сложность бизнес-логики неизбежно растёт. Это замедляет темпы разработки, системы становятся непонятными и запутанными. Связной – не исключение. Одним из наших решений проблемы является Dependency Injection. В докладе вы узнаете о том, как DI понижает сложность бизнес-логики, почему мы в Связном считаем DI DI в ASP.NET MVC эффективным решением и что нового для DI появилось в ASP.NET vNext.
Секционный доклад
Экскурс в мир WEB разработки
Дмитрий Лаабе
Генеральный директор и основатель рекрутинговой компании IT-Доминанта
Технический директор и программист
портала Айти-Событие
Россия. Санкт-Петербург
http://it-sobytie.ru/events/3120
Модульное приложение на Xamarin. От идеи до реализации.Денис Кретов
В презентации говорится платформе-конструкторе мобильных приложений для интернет магазинов, которая разработана на базе Xamarin+MvvmCross. Платформа состоит из ядра и набора подключаемых модулей. Между модулями нет прямой зависимости. Это позволяет вносить изменения в каждый из компонентов, менять их состав и создавать новые.
17. Moxy – пример
:Задача сделать экран авторизации
• :По нажатию на кнопку входа
– Показать прогресс запроса
– Начать асинхронный запрос авторизации
• :После завершения асинхронного запроса авторизации
– Скрыть прогресса запроса
– ,Если авторизация прошла успешно то перейти на главный
экран
– ,Если пришла ошибка то показать диалог с ошибкой
18. Moxy – пример
:Задача сделать экран авторизации
:Решение
•Сделать SignInView
•Сделать SignInActivity
•Сделать SignInPresenter
19. Moxy – пример
@StateStrategyType(AddToEndSingleStrategy.class)
public interface SignInView extends MvpView {
void showProgress();
void hideProgress();
void showError(Throwable exception);
void hideError();
@StateStrategyType(SingleStateStrategy.class)
void onSignIn();
}
public class SignInActivity extends MvpActivity implements SignInView, UsersCounterView {
@InjectPresenter
SignInPresenter mSignInPresenter;
@InjectPresenter
UsersCounterPresenter mUsersCounterPresenter;
...
20. Moxy – пример
@InjectViewState
public class SignInPresenter extends MvpPresenter<SignInView> {
@Inject
Repository mRepository;
public SignInPresenter() {
SampleApplication.getAppComponent().inject(this);
}
public void auth(String login, String password) {
getViewState().hideError();
getViewState().showProgress();
mRepository.authentication()
.signIn(login, password)
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
↓↓↓
↓↓↓
.subscribe(
ignored -> {
getViewState().hideProgress();
getViewState().onSignIn();
},
throwable -> {
getViewState().hideProgress();
getViewState().showError(throwable);
});
21. MoxyЖизненный цикл компонентов
View == Activity
PresenterStore: ,пока жив процесс получить доступ можно
через MvpFacade.getInstance().getPresenterStore()
Presenter:
LOCAL(default): пока View не финиширует
GLOBAL: пока живёт процесс
WEAK: пока не финишируют все View
ViewState: пока жив Presenter(в save state не сохраняется)
22. Советы
Presenter Presenter.init()Для инициализации сделайте метод
,Автокомплит работает сразу без компиляции проекта
Проект соберется даже без кодогенерации
Можно не использовать аннотации
MvpDelegate Viewпоможет превратить любой класс во
23. Как наладить диалоги
View:Между разными фантомный диалог
View1 Presenter1 Model Presenter2 View2→ → → →
Presenter:Между разными
Presenter1 Model Presenter2→ →
Как не :стоит делать
Presenter1 View Presenter2→ →
Editor's Notes
Всем привет,
Меня зовут Юра и я хочу рассказать вам о Moxy, о том как она устроена и как этим пользоваться
Вообще Moxy – это библиотека, реализующая MVP под Android. Поэтому для начала напомню, что такое MVP.
MVP – это шаблон проектирования пользовательского интерфейса. Почему именно пользовательского интрефейса, а не всего приложения?...
View – отвечает за пользовательский интерфейс приложения. Она отвечает только за передачу команд ... Хочется заметить, что в качестве устройства ввода/вывода может выступать не только дисплей …
И наконец Presenter. Presenter это по сути логика пользовательского интерфейса, логика View. Это связующее звено, которое знает как отреагировать на событие, произошедшие во View…
Довольно легко написать код, основанный на MVP. Для этого достаточно...
Но мы пришли к MVP по другой причине. Нам хотелось уйти от неудобных лоадеров. Лоадеры ... И в MVP мы нашли решение своей проблемы. Ведь если Presenter...
Отсюда появились такие требования к компонентам MVP:
1. Presenter должен спокойно переживать пересоздание View
2. В то же время, пересозданная View должна подключаться к уже работающему презентеру, а не создавать новый
3. А значит View при подключении к презентеру должна принять такой вид, который он от неё ожидает на данный момент. Например, если Presenter ожидает, что приаттаченная View показывает прогресс, то, как только View приаттачится к презентеру, она должна тут же показать прогресс.
Ну и конечно нам хотелось избежать boilerplate-кода. И вообще, чтобы все эти требования выполнялись сами собой. А нам не пришлось об этом беспокоиться.
Исходя из этих требований, мы решили сделать библиотеку Moxy.
Для начала рассмотрим схематично её компоненты, и как они взаимодействуют.
С моделью, вью и презентером вы уже знакомы. Ещё у Moxy есть ViewState. Можно подумать, что он хранит в себе флажки, которые говорят о том, как должна выглядеть View. Но это не так, потому что это не удобно. Поэтому ViewState помнит команды, которые Presenter передавал для View. И в тот момент, когда к презентеру цепляется новая View, ViewState отправляет к ней сохранённые команды, чтобы выполнив их, она стала выглядеть так, как этого ожидает Presenter. Хочется отметить, что у команд есть одна особенность: они умеют менять очередь команд вью стэйта. Например, команда может удалить себя из очереди команд после того, как будет первый раз применена ко View. Или полностью очистить очередь команд.
Теперь давайте рассмотрим схематичный пример, как работает Moxy.
Предположим, пользователь делает что-то со вью. Это событие передаётся в Presenter.
Presenter получив это событие, генерирует какую-то команду для View(предположим, «показать прогресс»).
Но эта команда уходит не напрямую во View, а сперва попадает во ViewState.
ViewState сохраняет её в очередь команд
И после этого передаёт её во View, которая применяет эту команду к себе
После этого наш Presenter делает какой-то асинхронный запрос в модель
И в результате этого запроса, презентер отправляет сперва одну команду во View(например, «скрыть прогресс»)
Которая так же уходит в очередь команд вью стэйта
И меняет очередь команд, удаляя оттуда команду «показать прогресс»
После чего команда «скрыть прогресс» применяется ко View
Затем Presenter отправляет очередную команду во вью(например, «покажи данные»), которая добавляется в очередь команд вью стэйта и применяется ко View.
И вдруг происходит вот что: пользователь поворачивает устройство
И View теряет своё правильное состояние.
Но тут ViewState замечает, что к презентеру приаттачилась новая вьюшка. Поэтому он применяет к ней последовательно хранившуюся очередь команды. И таким образом View принимает то самое состояние, которое у неё было до пересоздания.
Теперь давайте разберём пример, который покажет, как эта схема выглядит на деле.
Предположим, у нас есть экран авторизации, и нам нужно, чтобы у него было следующее поведение:
При нажатии на кнопку авторизации, нужно показать пользователю прогресс и начать асинхронный запрос авторизации
После завершения запроса, нужно скрыть прогресс и если авторизация прошла успешно, то провести пользователя внутрь приложения. Иначе, нужно показать пользователю ошибку.
Для того, чтобы нам реализовать такое поведение, придётся сделать три вещи:
Во-первых, написать интерфейс SignInView. Он будет просто описывать поведение View, чем позволит Moxy сгенерировать класс вью стэйта и его команды.
Затем нам нужна Activity, которая будет выступать в качестве View.
И наконец нам нужен Presenter, который будет реализовывать логику экрана
Вот непосредственно код, который придётся создать.
…….
Затем у нас определена Activity. Она наследуется от MvpActivity. Это позволяет не беспокоиться о том:
когда создавать Presenter или какой …
когда приаттачиться и детачиться от него
и в какой момент нужно сказать презентеру, что View финиширует и он может уничтожаться.
Дальше у нас определены поля с презентерами…
Так вот, оба эти презентера помечены аннотацией InjectPresenter. За счёт этого Moxy сама подставит в них нужные экземпляры презентеров, и мы сможем с ними взаимодействовать после вызова метода MvpActivity onCraete().
Приводить реализацию этой Activity я не буду, потому что во всех методах просто переключается visibility разных android-вью. Отмечу только то, что по клику на кнопку авторизации, в Presenter уходит соответствующая команда с данными из полей ввода логина и пароля.
Теперь мы приступаем к самому интересному компоненту - к презентеру.
… @InjectViewState, .. сгенерирует …, создаст экземпляр … сложит его в Presenter. Благодаря чему, метод презентера getViewState() всегда
…Repository, авторизуй пользователя асинхронно
И затем, ViewState, если …
Во-первых: логика экрана авторизации не привязана к тому, что и как отображается на дисплее. Может даже вовсе не быть ...
А также, за счёт того, что Presenter не привязан к .., вы можете смело использовать любой способ реализации ..
Ещё можно увидеть плюсы в удобстве тестирования такого презентера. Вы можете даггером подставлять нужный шедулер в Rx. И в момент теста инжектить синхронный шедулер. Тогда асинхронность превратится в синхронность, и не будет никаких проблем её протестировать.
В принципе текущих знаний вам должно хватить, чтобы начать успешно использовать Moxy.
Теперь я расскажу дополнительную информацию о Moxy, которая наверняка вам пригодится.
Сперва расскажу о продолжительности жизни основных компонентов Moxy.
Так же есть такая сущность как PresenterStore. Именно в ней хранятся все презентеры. Этот компонент живёт тоже до тех пор, пока не будет остановлен процесс, в котором он существует.
Интересней выглядит период жизни презентеров. В Moxy есть презентеры трёх типов, и у каждого из них свои правила существования.
локальные презентеры. чаще всего. Локальный Presenter живёт пока не финиширует View, для которой он создавался. Но он не будет уничтожен, если View будет пересоздаваться. Причём, этот механизм реализован довольно просто. ..
Напомню, что во вью стэйте живут не какие-нибудь флажки, говорящие о том, как должна выглядеть View, а список команд, применив которые, …. Поэтому довольно логично, что ViewState не может жить больше, чем живёт Presenter. Иначе что он будет собой отображать? Так же он не может жить меньше соответствующего презентера, т.к. в таком случае вновь приаттаченная вью не сможет получить список команд, чтобы принять актуальное состояние презентера.
А вот некоторые советы и замечания по поводу работы Moxy:
Если вам нужно для начала работы презентера какие-то входные параметры, то сделаете метод инициализации презентра.
[пример про детали новости]
Не смотря на большую роль кодогенерации, все автокомплиты будут работать из коробки. У вас не будет такого, что зафейленная кодогенерация будет мешать вам использовать автокомплит.
Мало того, проект даже будет собираться без кодогенерации. Правда, он будет падать в рантайме, но это другое дело =)
Ещё, можно совсем не пользоваться аннотациями, и кодогенерацией. Moxy позволяет вам всё делать самостоятельно: определять презентеры, писать код вью стэйта, самостоятельно создавать экземпляр вью стейте и складывать его в презентер. Или даже вовсе не использовать вью стэйт. Поэтому если вы захотите отказаться от мокси, мы сможете просто убрать аннотации и выключить кодогенерацию. Тогда у вас получится чистый MVP, и вам останется только связать между собой его компоненты….
Так же есть delegate..
На самом деле View не должна знать, что есть другая View. И тем более не должна хотеть что-то ей сообщить.. View может только передать действие пользователя в Presenter.