Как реализовать MVP Passive View в приложении для Android?

Question

Я недавно начал создавать приложение для Android, и я хотел бы использовать шаблон проектирования с нуля. Мне сказали, что MVP (Model-View-Presenter) - это хороший шаблон для приложений для Android.

Мне было интересно, возможно ли реализовать вариант "пассивного просмотра" шаблона MVP? Если бы я мог, я бы показал любой код ... но сейчас я понятия не имею, как пассивное представление должно выглядеть в приложении для Android. Также ... какую роль будет играть MainActivity в сценарии пассивного просмотра?

Буду признателен за любые объяснения, учебные пособия или примеры того, как реализовать пассивное представление.

Answer 1

Шаблон MVP в Android предполагает, что ваши классы View (фрагменты, действия) не содержат какой-либо презентации или бизнес-логики, но вся логика делегирована классу Presenter. В свою очередь, Presenter обычно вызывает void методы, предоставляемые представлением, когда инициализируется представление, происходит событие или уничтожается представление.

Итак, представьте, что View и Presenter реализуют следующие интерфейсы:

public interface Contract {

    interface View {

        void initView();

        void setTextColor();

    }

    interface Presenter {

        void init();

        void onButtonClicked();

    }
} 

В нашем упрощенном примере представление инициализирует Presenter (внедрение зависимостей выходит за рамки этого поста), а затем вызывает метод Presenter initView. Докладчик будет нести ответственность за всю логику инициализации, такую ​​как выборка данных из сети / хранилища и, при необходимости, обновление представления. Когда пользователь, в свою очередь, нажимает кнопку, представление будет делегировать действие докладчику, вызывая метод onButtonClicked() докладчика. Ведущий может выполнить некоторую обработку и, в зависимости от результата, может вызвать метод View setTextColor().

Самая важная причина использования MVP - это возможность проверить свою логику с помощью Junit и фреймворка Mockito. Ваш Presenter должен быть написан на чистом Java или Kotlin без каких-либо зависимостей от библиотеки фреймворка Android. Тогда вы можете просто протестировать ваш Presenter, используя JVM и не подключая устройство. Это все часть рекомендаций по чистой архитектуре дяди Боба .

Два лучших ресурса для MVP - блог Антонио Лейвы post и примеры архитектуры Google в github

Answer 2

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

Докладчик должен сделать одну вещь: представить. Это должно быть единственной целью. Многие люди по незнанию реализуют архитектуру MVC, называя ее MVP, с ограничением потока данных следующим образом: View <-> Controller / Presenter <-> Model. Теперь в этом шаблоне нет ничего плохого, поскольку он разделяет слои вашей системы. , если все сделано правильно. Вы должны быть в состоянии поменять свои уровни домена и данных (разработчики Android обычно называют слои уровнем Presenter и Model) в другую систему, и код все равно должен работать без каких-либо проблем с зависимостями. Чтобы достичь этого, вы должны избегать любых зависимостей, которые могли бы вызвать привязку к так называемой детализации (пользовательский интерфейс, база данных, фреймворки, оборудование, браузеры, операционная система). Теперь, говоря о слоях, у нас обычно была такая иерархия потоков данных: UI -> Domain -> Data, где в приложениях Android мы помещали весь наш код UI в компонент UI. Теперь есть 2 варианта позиционирования докладчика: Вы можете абстрагировать представление, введя интерфейс для конкретного представления докладчиков. Избегайте любых специфичных для Android / аппаратных зависимостей (например, контекстов) внутри докладчика. Если вы достигнете этого, то можете сказать, что ваш докладчик принадлежит вашему слою домена. Если ваш Presenter знает какие-либо подробности Android (или, что еще хуже, базу данных), то вы автоматически помещаете их в слой View (или даже нарушаете свою архитектуру, если пытаетесь получить доступ к базе данных из нее). Теперь давайте предположим, что вы абстрагировали свой View и ваш Presenter является объектом Domain. Ваш Presenter больше не заботится о фактической реализации своего представления представления, у него есть своя абстракция, и он знает, куда передать значение. Будь то мобильное, веб-приложение или встроенное приложение, больше не имеет значения. Теперь, как Presenter получает данные с уровня данных и заполняет пользовательский интерфейс данными? Мы делаем ту же технику, что и с View: абстракции. Мы создадим интерфейсный / абстрактный класс репозитория, шлюза, службы данных или, как вы хотите, вызвать интерфейс уровня данных / модели. У вас есть POJO, ваша логика доступа к данным, кеширование и т. Д. Обратите внимание, что до сих пор мы работали с POJO! У нас нет зависимостей от какой-либо привязки к платформе (как описано выше). Но поскольку сейчас нам нужно немного кешировать, нам придется использовать SQLite Manager из Android (или Room). Как это сделать? абстракции. Абстрагируйте любую деталь, которая заставляет ваш код быть привязанным к любой платформе.

Ниже вы можете увидеть картинку, предложенную дядей Бобом для создания надежной архитектуры программного обеспечения. Внутренние слои не должны иметь никаких знаний о внешних слоях. Эта картина отражает технику разработки, которую я только что описал здесь, которая является той же техникой, описанной в книге дяди Боба. Мы избегаем любых зависимостей от деталей, используя их абстракции. Реальные реализации (Деятельности, Фрагменты, SQLiteDatabase) «подключаются» к внутренним слоям снаружи посредством внедрения зависимостей. Этот метод также называется инверсией зависимостей.

Я бы порекомендовал вам прочитать книгу Роберта Мартина «Чистая архитектура», чтобы глубже понять ее.

Answer 3

Работать с MVP не так уж сложно

Во-первых, в пакете Model вы будете хранить все виды классов POJO, которые имеют сеттеры, геттеры и всю структуру данных вашего приложения

Затем приходит докладчик, где вы связываете эти объекты и делаете с ним некоторую логику.

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

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

вы можете использовать MVC, MVP, MVVM, но если вы хотите начать, я бы посоветовал вам начать с MVP

Посмотрите на это изображение MVP

Вы также можете проверить ЭТО учебник о MVP