Как передаются данные при mvp

Что такое Minimal Viable Product в программировании

Вы наверняка слышали об MVP. В этой статье мы расскажем, что такое MVP, какие цели преследует и как используется в программировании.

Определение MVP

Аббревиатура расшифровывается как Minimal Viable Product — минимально жизнеспособный продукт. По сути, это тестовая версия товара или сервиса, которая позволяет оценить заинтересованность потребителя в представленном продукте.

Такой подход применим для реализации чего угодно и нередко используется в разработке ПО и цифровых сервисов.

При этом MVP не является прототипом, поскольку содержит лишь самую необходимую функциональность. С ранним релизом также мало общего: релиз хоть и учитывает предпочтения пользователей, но сами пользователи никак не влияют на направление развития продукта.

Цели Minimal Viable Product

1. При минимальных ресурсо- и времязатратах проверить гипотезу успешности продукта.
2. Опередить конкурентов ранним захватом целевого рынка.
3. Создать основу для будущих проектов аналогичного направления.
4. Собрать фокус-группу с возможностью использовать её в дальнейшем развитии продукта.
5. Привлечь денежные средства через инвесторов или по схеме краудфандинга.

В разрезе разработки это также возможность проверить способность команды реализовать целевой проект, что особенно важно, если на старте команда собрана с нуля.

MVP в программировании на примере известных компаний

Наверное, самым известным примером является социальная сеть Facebook. В 2004 году сайт был разработан для общения студентов Гарвардского университета. Тогда профили пользователей содержали минимум информации, а сегодня Facebook является крупнейшей социальной сетью в мире стоимостью в $73 млрд.

В креативности не уступает и Uber. Приложение на первых порах могло лишь соединять клиентов с водителями. Именно эта простота и принесла сервису успех. Теперь же в Uber есть множество функций, начиная отслеживанием автомобиля и заканчивая семейным профилем. На сегодняшний день бизнес Uber стоит $53 млрд.

Snapchat начинался как небольшая утилита для обмена сообщениями, что удалялись через 10 секунд после прочтения. В первой версии на iOS из продвинутых функций была только загрузка изображений. Сейчас Snapchat оценивается в $35 млрд.

Yahoo! на старте был статичной страницей со ссылками на популярные веб-сайты — простейший каталог, который хорошо себя показал на ранних этапах развития интернета. Сегодня же это вторая по популярности поисковая система, ежегодный доход которой варьируется в районе $5 млрд.

Как создать MVP

Для начала вы должны чётко понимать, какую проблему должен решать ваш продукт, и определить функции, которые сделают его жизнеспособным.

Перед непосредственной реализацией Minimal Viable Product стоит исследовать рынок и опросить потенциальных клиентов. Возможно, из опрошенных и будет состоять ваша будущая фокус-группа для оценки MVP.

Далее вооружайтесь полезными сервисами:

— для быстрого создания лендингов.
• QuickMVP — создание лендинга и рекламы в Google, что позволит сразу оценить реакцию людей на бизнес-идею. — для реализации прототипа приложения без привлечения разработчиков и с проверкой на реальном устройстве.

Либо, если у вас уже есть команда программистов, создайте MVP самостоятельно. Выкатывайте, собирайте статистику и добавляйте востребованные функции для создания полноценной версии.

Недостатки MVP

Данный подход не обошла и критика. Например в ряде случаев невозможно урезать те функции, которые должны лежать в основе будущего продукта, и их одинаково сложно реализовать, пусть даже прототип будет с примитивным интерфейсом.

Другая проблема — это плохой UX на фоне хорошо работающей программы. Причин может быть множество, даже всё тот же примитивный интерфейс. В итоге создатель придёт к выводу, что пользователям его проект не нужен, а значит он не взлетит, хотя для удовлетворительного фидбека нужно было подкрутить лишь какую-то мелочь.

По MVP должен быть виден потенциал будущего продукта, пусть он и представлен в бюджетном варианте. Многие об этом забывают и впустую тратятся на то, что после выдаёт плохие результаты. Также это большой риск, ведь низкое качество прототипа может отрицательно сказаться на бренде.

Minimum Valuable Product

Из-за того, что определение MVP многих стартаперов толкает на создание примитивных тестовых продуктов, на арену постепенно выходит MVaP — Minimum Valuable Product или минимальный ценный продукт.

Концепция состоит в том, что необходим не какой угодно результат при низких затратах, а создание ценного для пользователей продукта, который будет соответствовать их ожиданиям и закрывать потребности. Только так можно собрать и проанализировать реальную статистику.

Выводы

Использование MVP включает ряд достоинств, таких как получение реальных отзывов при минимальных затратах и опережение конкурентов. Принцип работы MVP в программировании ничем не отличается от других сфер. К тому же сегодня можно воспользоваться сервисами для быстрого создания прототипа, даже не прибегая к разработке.

Основной проблемой Minimal Viable Product остаётся непонимание того, как правильно использовать данную стратегию, ведь порой в угоду экономии тестовые продукты создаются на отвали и не оправдывают возложенных на них ожиданий.

Что такое MVP и зачем он нужен для стартапа

В далеком 2005 году YouTube задумывался как сайт для видеознакомств. А Instagram изначально назывался Burbn (да, в честь алкогольного напитка) и выполнял роль планера, который позволял пользователям отмечать места, в которых они побывали с друзьями, выгружать фотографии со встреч и зарабатывать очки.

Однако обе концепции не пользовались спросом. Поэтому компании провели анализ своих показателей, прислушались к пожеланиям пользователей и совершили пивот. Видеознакомства и приложение Burbn стали для компаний так называемым MVP — от английского Minimum Viable Product, «минимально жизнеспособный продукт».

Что такое MVP

Термин Minimum Viable Product ввел основатель идеи Lean Startup, известный американский предприниматель Эрик Рис. Он означает самую раннюю версию продукта, доступную для тестирования.

Принцип Minimum Viable Product можно коротко описать как «Мечтай о высоком, начинай с малого». Он основывается на поэтапной разработке продукта, где все итерации проверяются на живых потребителях. При этом обратная связь позволяет компании на ранних этапах исключить риски, устранить ошибки, заранее проверить, имеется ли спрос на их предложение.

Вот три принципа качественного MVP:

1. Этот продукт имеет достаточную ценность, чтобы потребители захотели начать им пользоваться.
2. Он имеет в себе задатки того продукта, который компания планирует разработать в будущем, что заставляет пользователей ждать финального запуска.
3. Он предоставляет компании отзывы о качестве продукта, которые помогают учесть все недоработки и усовершенствовать конечную версию.

Каждый этап разработки продукта улучшает его на еще одну ступень. Затем продукт направляется клиентам, которые тестируют его и сообщают о возможных улучшениях. Таким образом MVP помогает проверить гипотезы и отказаться от неудачных решений до того, как от них пострадает весь бизнес.

Поиск хороших идей — это не линейный процесс. Скорее, он похож на петли, которые то закольцовываются внутри себя, то — гораздо реже — выводят на следующий шаг. Всего таких шагов шесть:

• поиск проблемы;
• поиск решений для найденных проблем;
• прототипирование;
• тестирование;
• обратная связь;
• внесение поправок.

Каждый из них может оказаться петлей. Следует прокручивать тот или иной этап снова и снова, порой возвращаясь на несколько шагов назад, когда гипотеза окажется нерабочей. И если оригинальная идея при тестировании или обратной связи доказала свою несостоятельность — значит, продукт должен совершить пивот.

Какие бывают MVP: тринадцать типов

Основная задача MVP — протестировать будущий продукт на живой аудитории. Следовательно, качество и точность результатов теста могут повлиять на эффективность и скорость процесса разработки. Поэтому виды Minimum Viable Product делятся на две группы: с высокой достоверностью и низкой. Они могут совмещаться между собой и использоваться параллельно.

Высокая достоверность

MVP с высокой достоверностью требуют больше подготовки, ресурсов и аналитических работ. Они используются для:

• определения и оптимизации маркетинговой стратегии;
• тестирования ценностного предложения, каналов коммуникации, CTA;
• поиска потенциальных стратегий роста;
• обретения первичных покупателей и ниши на рынке;
• анализа информации о спросе на разрабатываемый продукт.

Виды MVP с высокой достоверностью:

1. Консьерж — разработчики вручную направляют и контролируют клиента внутри продукта вместо использования автоматизированных алгоритмов. Подходит для разработок в сфере искусственного интеллекта.
2. Волшебник из страны Оз похож на тип Консьерж, но более продвинутый по уровню качества. Управление продуктом также осуществляется за счет человеческого труда, однако сам продукт выглядит и ощущается как реальное решение.
3. Фрагментарный — часть продукта контролируется вручную, однако недостающие фрагменты кода или функционала симулируются автоматизированными алгоритмами.
4. Таблетка обезболивающего сосредоточена на единственной проблеме. Это буквальное упрощенное решение, которое устраняет лишь одну конкретную боль клиента. В дальнейшем возможно развитие и эволюция в более сложный продукт.

Низкая достоверность

Следующая группа MVP отличается низкой достоверностью и упрощенными способами сбора данных. Они не требуют тщательного программирования и крупных финансовых вложений, приводят к менее точным результатам. Их основные задачи:

• изучить практическую ценность продукта;
• найти наиболее эффективные и востребованные решения проблемы;
• помочь с определением и пониманием потребностей клиента;
• провести анализ ниши и понять, стоит ли игра свеч.

Виды MVP с низкой достоверностью:

1. Блоги.
2. Форумы / сообщества.
3. Опросы / анкеты.
4. Посадочная страница.
5. Видеоинструкции.
6. Рекламная кампания.
7. Презентация / макет.
8. Краудфандинговая кампания.
9. Сервисы по обзору новых идей.

Скейтборд-версия продукта

Несколько лет назад консультант по Agile и Lean-производству Хенрик Книберг выпустил книгу о методах разработки продукта. Иллюстрация из этой книги появилась в десятках изданий. На ней отражен основной принцип Minimum Viable Product:

Верхняя строчка: «[Нужно делать] не так…» Нижняя строчка: «А вот так!»

Верхняя половина иллюстрации отражает некорректный и малоэффективный способ создания продукта. Принцип такой: клиент выразил потребность в транспортном средстве, которое поможет ему комфортно и быстро передвигаться на большие расстояния. Выделяем основные характеристики продукта:

• комфортабельность;
• возможность совершения длительных поездок;
• скорость.

Компания предположила, какой продукт в наибольшей степени соответствует запросу клиента: автомобиль. Началась разработка прототипов. Однако каждый прототип, продемонстрированный потребителю, был абсолютно не юзабельным. Вплоть до момента получения финального продукта клиент был недоволен итерациями, потому что не мог ими воспользоваться, чтобы предложить живой фидбэк.

На нижней половине изображения разработчики сперва отправляют клиенту скейтборд. Это все еще далеко от идеала: некомфортно, не поддерживает высокие скорости, не ходит на большие расстояния. Однако это рабочее, пусть и не идеальное, средство передвижения. Клиент уже может прокатиться на нем и предоставить обратную связь.

Скейтборд в данном примере и есть Minimum Viable Product. На его месте может быть любой другой товар. К слову, из-за иллюстрации Хенрика Книберга многие начали называть свой первый доступный к использованию прототип продукта скейтборд-версией.

Особенности работы MVP

Постепенная эволюция товара с сохранением юзабилити помогает разработчикам сразу проверить гипотезы: если передвигаться на скейтборде некомфортно, что насчет самоката? Если самокат не может разогнаться, как с этим справится велосипед? Каждый следующий прототип решает одну из потребностей клиента и/или повышает эффективность уже существующих характеристик.

Непрерывный контакт с потребителем дает доступ к сведениям о возможных багах и недоработках. Но когда прототипы не тестируются на непосредственных пользователях, конечный продукт наследует ошибки первых этапов. Устранение багов после запуска продаж ударит по бюджету сильнее, чем если бы этот идеальный продукт разрабатывался с нуля. В этом смысле метод Minimum Viable Product соответствует принципам «бережливого производства»: он обнаруживает самые простые и дешевые решения в короткие сроки.

В некоторых случаях клиент может выразить полное удовлетворение продуктом уже на стадии мотоцикла. Значит, нет смысла совершенствовать его до стадии автомобиля. Этот этап называется Minimum Loveable Product — минимальный продукт, который способен вызвать у покупателя чувство удовлетворения. Умение находить этот рубеж сэкономит стартапу немало ресурсов и времени.

Но даже когда конечным продуктом становится тот самый автомобиль, который разработчики описали клиенту в начале пути, уравнение складывается в пользу всех участников рынка. Ведь в процессе создания продукта были собраны полезные инсайты, устранены баги. А значит, клиент получит автомобиль более высокого качества, чем планировалось изначально.

Преимущества и недостатки создания MVP

Вот список основных плюсов внедрения Minimum Viable Product в свои бизнес-процессы:

1. Оптимизация ресурсов. Благодаря тестированию Minimum Viable Product на живых покупателях компания выявляет ошибки на ранних этапах. Это позволяет лучше спланировать бюджеты, скорректировать бизнес-модель, затратить меньше времени. Каждая следующая итерация оказывается эффективнее предыдущей. Клиенты получают качественный продукт, который соответствует их потребностям.
2. Раннее обретение потребителя. Тестирование каждой итерации на живых клиентах помогает найти потенциальных покупателей еще до старта продаж. Когда потребители пользуются минимальным набором характеристик и функций MVP, у них есть возможность оценить потенциал будущего продукта.
3. Возможность повысить соответствие предложения и спроса. Согласно статистике CB Insights, 42 % стартапов закрываются в связи с отсутствием спроса на рынке. Это значит, что проблема, которую решал продукт фаундера, оказалась недостаточно болезненной для потребителя. Очень важно понимать и выслушивать боли клиента. Minimum Viable Product помогает компании максимально приблизить свой продукт к нуждам рынка.
4. Улучшение инвестиционных перспектив. Инвесторы охотнее рассматривают реальное MVP, чем нереальные фантазии, существующие лишь на бумаге. Возможность использовать прототип продукта и ознакомиться с его базовыми характеристиками делает проект более привлекательным для вложений.

Что касается недостатков, их всего два — и оба существенные.

1. Software > hardware. Задача по созданию MVP наиболее выполнима при разработке софта. Однако это не значит, что MVP невозможно применить к материальным предметам. Например, крупнейшие автомобильные концерны (Toyota, Tesla и др.) создают десятки прототипов, прежде чем выпустить новую модель.
2. Несовместимость с инновационными продуктами. Когда Генри Форд изобретал автомобиль, общение с клиентами не принесло бы ему никакой пользы: в то время люди еще передвигались на лошадях и предпочли бы улучшать кареты, колеса, повозки. Поэтому революционные решения, которые способны изменить рынок или даже весь мир, плохо поддаются прототипированию.

Как создать MVP для своего бизнеса

CEO известного акселератора Y Combinator Майкл Сейбел выделил четыре фактора идеального MVP:

• быстрое выполнение работы в пределах недель, а не месяцев;
• крайне ограниченный функционал MVP, который решает лишь некоторые проблемы;
• целевая аудитория MVP — узкая категория пользователей, а не все потенциальные пользователи разом;
• MVP предоставляет отправную точку для дальнейших итераций.

Как утверждает Майкл, большинство стартапов могут чрезвычайно быстро открыть рабочую деятельность — достаточно лишь лендинга и таблицы Google. Он также поясняет: MVP — это просто исходный рубеж, в нем не должно быть никакого волшебства, никакой особенности. Просто нужно с чего-то начать. И это начало должно быть максимально заурядным.

Четыре лайфхака для быстрого запуска

Чтобы создать MVP в короткие сроки, Майкл предлагает следующие шаги:

1. Определить временные рамки ТЗ. Предположим, первое тестирование Minimum Viable Product запланировано через три недели. Тогда сроки подзадач внутри ТЗ тоже должны уложиться в три недели. Это задаст рабочему процессу некую конечность и определенность, позволит отказаться от излишне трудоемких шагов.
2. Записать свое ТЗ. Изначальная идея MVP может многократно меняться. Иногда — в процессе разработки. Представим ситуацию: фаундер рассказывает о своей концепции инвесторам, но в ответ слышит: «Это в жизни не вырастет в хорошую компанию!» Тогда фаундер начинает «подкручивать» настройки своего MVP, и трехнедельный срок выполнения растягивается до трех месяцев. При этом внесенные изменения могут быть незаметны ни для команды, ни для фаундера. Если записать идею MVP на бумаге, это предоставит стабильную нулевую точку, к которой можно вернуться в любое время.
3. Сократить ТЗ. Трехнедельный срок близится к концу, а команда не завершила даже половины запланированных работ. В таком случае нужно выбросить из ТЗ все неважные шаги и сосредоточиться на том, что осталось. Когда закончатся неважные задачи, придется выбрасывать и важные тоже. Стартапу в этот момент необходимо хоть что-то показать миру: даже недоработанный Minimum Viable Product поможет набрать инерцию, начать развиваться. Бесконечно откладывать старт намного проще, но этот путь никуда не ведет.
4. Не влюбляйтесь в MVP! Это всего лишь основа, от которой вы будете развиваться дальше — часто через пивоты и полную смену концепции. Вряд ли вы влюбились бы сейчас в сочинение, которое написали в первом классе. Оставьте себе пространство для роста и не задерживайтесь в точке начала.

Правило: всегда дели MVP на восемь

Создатель концепции Lean Startup Эрик Рис сообщает: главная задача Minimum Viable Product — предложить потребителю тестируемый минимум, пригодный к использованию, чтобы запустить цикл изучения его потребностей и реакций. Однако, по его словам, фаундеры обычно начинают со слишком крупных проектов. В них больше характеристик и функций, чем необходимо для старта. И чем крупнее проект, тем сложнее становится понять, что именно не пришлось потребителям по вкусу.

Эрик Рис приводит формулу вычисления идеального MVP: «Возьмите то, что вам сейчас кажется хорошей идеей, и поделите пополам. Потом повторите это еще два раза. И отправляйте!»

Скорее всего, клиенты воспримут минимальный продукт негативно. В конце концов, он в 8 раз меньше того, что планировался изначально. Но основная цель при разработке MVP — сделать так, чтобы потребители испытывали конкретные эмоции по отношению к продукту, конкретное «нравится» или «не нравится». В этом смысле худший враг фаундера — индифферентность.

Примеры MVP успешных компаний

Buffer

Buffer — это приложение по управлению аккаунтами в соцсетях и созданию отложенных публикаций в Twitter, Facebook, Instagram, Pinterest и на других платформах. Имеются функции аналитики и интерактивного взаимодействия с аудиторией.

В самом начале развития их сайт выглядел так (слева). Однако эта версия была недостаточно эффективна, да и сложно назвать ее полноценным MVP. Поэтому предложение получило апгрейд в виде дополнительной страницы (справа):

Уровень заинтересованности клиента сразу поднялся с уровня «Это любопытно» до «Я хочу это приобрести». Фаундер компании Buffer Джоэль Гаскон утверждает: «После таких результатов я не стал медлить. Мы начали создавать первое MVP нашего реального, рабочего продукта».

Airbnb

Так выглядел Minimum Viable Product от Airbnb:

В самом начале у сервиса не было функции встроенной оплаты, и пользователи напрямую встречались с хозяевами собственности и отдавали им деньги. Также на веб-сайте не было встроенных карт, которые позволяли бы наглядно увидеть расположение арендуемых квартир и домов. Наконец, CTO компании, который отвечал за код, работал на полставки.

Twitch

Стриминг-сервис Twitch начинал как платформа для трансляции онлайн-шоу Justin TV. Тогда был доступен лишь один канал: прямое включение из жизни Джастина. Если пользователям не нравился Джастин, им больше нечего было делать на этом сайте: весь функционал ограничивался одной трансляцией.

При этом само видео было чрезвычайно низкого качества — как вспоминают основатели, на нем едва можно было распознать лицо главного героя. И, безусловно, Justin TV был чрезвычайно далек от гейминг-индустрии и видеоигр.

Подведение итогов

Minimum Viable Product, или минимально жизнеспособный продукт, — это прототип вашего продукта, демоверсия, которую можно протестировать на реальных клиентах. Каждая итерация получает обратную связь от потребителей. Это позволяет изучить недостатки продукта и с каждым новым этапом предлагать все более эффективную версию.

Три важнейших вопроса, на которые должен ответить фаундер перед созданием МVP:

1. Какую проблему я пытаюсь решить?
2. Для кого я пытаюсь ее решить? Кто потребитель?
3. Как выглядит моя скейтборд-версия продукта?

Minimum Viable Product должен быть максимально упрощенным и примитивным. Его основная задача — запустить цикл общения с клиентами, инициировать старт рабочего процесса.

Android MVP пример для начинающих. Без библиотек и интерфейсов.

В этом посте описывается несложный пример MVP, без использования запутывающих интерфейсов и сложных библиотек.

Что такое MVP

Сначала немного теории о MVP. Схематично это выглядит так:

MVP расшифровывается как Model-View-Presenter (модель-представление-презентер). Если рассматривать Activity, которое отображает какие-то данные с сервера, то View — это Activity, а Model — это ваши классы по работе с сервером. Напрямую View и Model не взаимодействуют. Для этого используется Presenter.

Если в Activity пользователь нажал кнопку Обновить, то Activity сообщает об этом презентеру. При этом Activity не просит презентер загрузить данные. Оно просто сообщает, что пользователь нажал кнопку Обновить. А презентер уже сам решает, что по нажатию этой кнопки надо делать. Он запрашивает данные у модели и передает их в Activity, чтобы отобразить на экране.

Если экран отображает данные из базы данных, то модель — это база данных. Презентер может подписаться на уведомления модели об обновлении. В случае, когда данные в БД изменятся, модель оповестит об этом презентер. Презентер получит эти изменения и передаст их в Activity.

Можно сказать, что презентер — это логика, вынесенная из Activity в отдельный класс. А Activity остается для отображения данных и взаимодействия с пользователем. Если вы решили сделать другое Activity для отображения данных, то вам уже не нужно будет переносить логику в новое Activity, можно будет использовать готовый Presenter. А если вы решили поменять логику, то вам не нужно будет лезть в Activity и там, среди кода, который отвечает за отображение данных и взаимодействие с пользователем, искать логику и менять ее. Вы меняете код в презентере.

Важное замечание! Пример реализации, который мы сейчас будем рассматривать, не является единственно правильным вариантом, выполненным по канонам MVP. В разных случаях могут быть шаги влево и вправо. Но общую концепцию этот пример отражает.

Практика

Я создал небольшое приложение и залил на гитхаб.

Приложение умеет добавлять, хранить и отображать список пользователей.

Чтобы наглядно показать отличие MVP, я сделал этот экран в двух вариантах: Activity и MVP. Вы можете выбрать нужный вариант при запуске:

Оба этих режима внешне будут выглядеть и работать одинаково, но «под капотом» они разные.

Первый вариант реализован с помощью одного Activity — SingleActivity. В нем реализовано следующее:
— вывод информации на экран и обработка нажатий
— логика (что делать по нажатию на кнопки и что/когда показывать)
— работа с базой данных.

Такой вариант реализации считается тяжелым и неудобным. Слишком много всего возложено на один класс.

Второй вариант реализован с помощью MVP — mvp.

В этом варианте я просто разделил код из SingleActivity на три класса в соответствии с MVP:
— в UsersModel — работа с базой данных (Model)
— в UsersActivity — вывод информации на экран и обработка нажатий (View)
— в UsersPresenter — логика (Presenter)

Давайте немного пройдемся по ключевым моментам кода. Сначала рекомендую вам посмотреть код SingleActivity, чтобы понять основные механизмы работы приложения. А я дальше буду описывать, как это было разделено по разным классам.

UsersModel

Это Model (модель). В модели обычно реализована работа с данными, например: запрос данных с сервера, сохранение в БД, чтение файлов и т.п.

Здесь находятся все операции с базой данных. Этот класс имеет три public метода, которые вызываются презентером:
loadUsers — получение списка пользователей из БД
addUsers — добавление пользователя в БД
clearUsers — удаление всех пользователей из БД

Что происходит внутри этих методов — касается только модели. Презентер будет просто вызывать эти методы и его не должно интересовать, как именно они реализованы.

Методам на вход можно передавать колбэки, которые будут вызваны по окончанию операции. Асинхронность работы с БД реализована с помощью AsyncTask. В методы добавления и удаления добавлены секундные паузы для наглядности.

UserActivity

Это View (представление). Представление отвечает за отображение данных на экране и за обработку действий пользователя.

Здесь есть несколько public методов, вызываемых презентером:
getUserData — получение данных, введенных пользователем
showUsers — отображение списка пользователей
showToast — отображение Toast
showProgress/hideProgress — скрыть/показать прогресс-диалог

В представлении не должно быть никакой логики. Это только инструмент для отображения данных и взаимодействия с пользователем.

Действия пользователя передаются в презентер. Обратите внимание на обработчики для кнопок Add и Clear. По нажатию на них, представление сразу сообщает об этом презентеру. И презентер уже будет решать, что делать.

Повторюсь, т.к. очень важно понимать это правильно. По нажатию на кнопки, Activity не просит презентер добавить пользователя или удалить всех пользователей. Т.е. оно не указывает презентеру, что ему делать. Оно просто сообщает, что была нажата кнопка Add или Clear. А презентер принимает это к сведению и действует по своему усмотрению.

UsersPresenter

Это Presenter (презентер). Он является связующим звеном между представлением и моделью, которые не должны общаться напрямую.

От представления презентер получает данные о том, какие кнопки были нажаты пользователем, и решает, как отреагировать на эти нажатия. Если надо что-то отобразить, то презентер сообщает об этом представлению. А если нужно сохранить/получить данные, он использует модель.

Давайте по шагам рассмотрим взаимодействие представления, презентера и модели на нашем примере. Возьмем сценарий добавления новых данных в базу.

1) Пользователь вводит данные в поля ввода. Это никак не обрабатывается и ничего не происходит.
2) Пользователь жмет кнопку Add. Вот тут начинается движ.
3) Представление сообщает презентеру о том, что была нажата кнопка Add.
4) Презентер просит представление дать ему данные, которые были введены пользователем в поля ввода.
5) Презентер проверяет эти данные на корректность.
6) Если они некорректны, то презентер просит представление показать сообщение об этом.
7) Если данные корректны, то презентер просит представление показать прогресс-диалог и просит модель добавить данные в базу данных.
8) Модель асинхронно выполняет вставку данных и сообщает презентеру, что вставка завершена
9) Презентер просит представление убрать прогресс-диалог.
10) Презентер просит свежие данные у модели.
11) Модель возвращает данные презентеру.
12 Презентер просит представление показать новые данные.

Из этой схемы видно, что презентер рулит всем происходящим. Он раздает всем указания, решает, что делать и как реагировать на действия пользователя.

Обратите внимание на методы презентера: attachView и detachView. Первый дает презентеру представление для работы, а второй говорит, что представление надо отпустить. Эти методы вызывает само представление. Первый метод — после своего создания, а второй — перед своим уничтожением. Иначе, если презентер будет держать ссылку на представление после его официального уничтожения, то может возникнуть утечка памяти.

Метод viewIsReady вызывается представлением, чтобы сообщить о том, что представление готово к работе. Презентер запрашивает у модели данные и просит представление отобразить их.

Плюсы MVP

Кратко напишу преимущества MVP по сравнению с Activity.
— легче писать тесты
— в небольших классах искать что-либо и вносить изменения легче, чем в одном большом
— бывает так, что одно представление используется разными презентерами, или наоборот — один презентер используется для разных представлений. Если у вас все в одном Activity — вы не сможете так сделать.

Все плюсы вытекают из того, что вместо одного класса, мы используем несколько.

Что дальше?

Я создал этот пример, чтобы максимально просто показать реализацию MVP. Реальный рабочий пример будет содержать несколько важных дополнений. Кратко расскажу о них, чтобы вы представляли себе, куда двигаться дальше.

Интерфейсы.

Это то, что очень запутывает новичков в примерах MVP, но действительно является очень полезным инструментом.

Обратите внимание на взаимодействие презентера и представления в нашем примере. У представления есть несколько методов, которые вызывает презентер: getUserData, showUsers, showToast, showProgress, hideProgress. Вот эти методы — это все что должен знать презентер. Ему не нужны больше никакие знания о представлении. А в текущей реализации презентер знает, что его представление — это UsersActivity. Т.е. это целое Activity с кучей методов, которые презентеру знать незачем. Использование интерфейсов решает эту проблему.

Мы можем создать интерфейс UsersContractView

Добавить этот интерфейс в UsersActivity

Теперь в презентере можно убрать все упоминания о UsersActivity, и оставить только UsersContractView.

Плюс такого похода в том, что теперь в этом презентере вы можете использовать любое представление, которое реализует интерфейс UsersContractView. И вам не придется ничего менять в презентере.

А если презентер завязан на конкретный класс, например, UsersActivity, то при замене представления, вам придется открыть презентер и поменять там UsersActivity на другой класс.

Асинхронные операции

Для реализации асинхронности я здесь использовал AsyncTask. Но не помню, когда последний раз использовал его в рабочем коде. Обычно используются различные библиотеки, которые удобнее в использовании, гибче и дают больше возможностей. Например — RxJava.

Создание объектов

В UsersActivity мы создаем презентер следующим образом:

Это не очень хорошая практика. Рекомендуется не создавать объекты внутри вашего класса, а получать их уже готовыми снаружи. Для реализации этого принципа существуют различные библиотеки. Самый распространенный пример — это библиотека Dagger 2.

Поворот экрана

В этом примере нет обработки поворота экрана. Если ваш презентер выполняет какую-то долгую операцию, и вы повернете экран, у вас просто создастся новый презентер, а результаты работы старого презентера могут быть потеряны.

Есть различные способы, как этого избежать. Один из них — не пересоздавать презентер, если представление пересоздается. При этом, презенетер отпускает старое представление (метод detachView), и получает новое представление (метод attahcView). В итоге, результаты работы долгой операции будут отображены уже в новом представлении.

Если тема MVP стала вам интересна, то посмотрите этот пример. Он посложнее и более приближен к реальному коду.

Присоединяйтесь к нам в Telegram:

— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.

— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование

— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня

— новый чат Performance для обсуждения проблем производительности и для ваших пожеланий по содержанию курса по этой теме