Модель-View-Presenter и дизайн приложений для Android

Проблема: действительно большие и запутанные классы активности. Трудно читать, понимать и модифицировать. Трудно проверить.

Возможное решение: Model-View-Presenter (возможно, с инъекцией зависимостей). И Mock Test Objects!

Я планирую реализовать Model-View-Presenter в своем приложении для Android. Это в основном вариант Model-View-Controller. По существу, сделайте операцию прославленный менеджер макетов и отложить любую бизнес-логику до Ведущего. Еще один способ взглянуть на Presenter - это то, что он как класс Helper, созданный в рамках Activity для выполнения тяжелой работы с активностью, обеспечивающей интерфейс/обратный вызов, который может использовать Presenter.

Я хотел бы получить некоторые мысли сообщества об этом. Например: Какие интерфейсы подразумеваются этим?
Какие обязанности будут иметь Модель и Вид против Ведущего.

Для Presenter, я полагаю, что Activity будет реализовывать интерфейсы, необходимые для Presenter?
Какие вещи должны идти в "Презентер" или "Активность"?

Будет ли ведущий быть единоличным с Activity? Что относительно Activity с несколькими фрагментами, отображающими разные виджеты, каждый со своим адаптером? Нужно ли нам сейчас несколько презентаторов или еще один?

Как должен докладчик рассказать о деятельности с помощью ListView и ListViewAdapter? Что входит в презентацию против адаптера?
Должна ли презентатор выбрать адаптер для использования? Или если мероприятие примет это решение? Должна ли презентатор обрабатывать данные модели или адаптер? Существует ли конфликт между адаптерами и докладчиками? Являются ли адаптеры ведущими? или что-то меньшее/больше. Обычно адаптеры предназначены только для виджетов, таких как ListViews в рамках Activity. Они не выполняют вызовы, которые сами получают данные.

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

Является ли Model-View-Presenter просто плохой идеей для Android? Или это хорошо подходит для Android Framework?

Имейте в виду, что есть множество примеров вне Android от очень зрелого SDK, которым по-прежнему нужна микро-архитектура, например MVP. На самом деле примеров много: например. Flex был очень зрелым SDK для Flash, и все же он по-прежнему нуждался в MVP и MVC-фреймворках практически для любого крупного приложения.

EJB необходимо Spring, чтобы упростить и упорядочить его. MFC/Struts и т.д., И список можно продолжать и продолжать. Почему Android должен быть другим? Почему мы должны предположить, что SDK имеет все необходимое для Android без шаблона проектирования, такого как MVP?

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

Ответы

Ответ 1

Android наказывает плохой дизайн MV (P | C) больше, чем любая платформа, с которой я когда-либо сталкивался. Забудьте о неуклюжих методах, которые он предоставляет для передачи состояния вверх и вниз по стеку действий. Получите как можно больше состояния и логики из своей деятельности. Переместите его в Службы, ContentProviders и SharedPreferences, если это необходимо. Постарайтесь сделать вид деятельности чистой. IMO, службам никогда не уделялось достаточного внимания в обучающих программах Android. Даже книга O'Reilly Programming Android дает только четверть страницы!

Будьте осторожны с расширением Приложения. Если вы когда-либо запускаете Сервис в своем собственном процессе (например, чтобы он был изящно закрыт при сбое Activity), то у Службы будет своя копия вашего Приложения.

Ответ 2

Просто чтобы предоставить ссылку другим, которые могут быть заинтересованы. Я думал то же самое несколько лет назад. Когда мы применяем MVC/MVVM/Модель представления в приложение для Android, то, что мы действительно хотим, это иметь четкий структурированный проект и, что более важно, для модульных тестов. На данный момент, без сторонней структуры, у вас обычно есть много кода (например, addXXListener(), findViewById()...), который не добавляет никакого бизнес-значения. Что еще, вам нужно запускать тесты на Android-версию вместо обычных тестов JUnit, которые требуют времени для запуска и делают блок-тесты несколько непрактичными. По этим причинам несколько лет назад мы начали проект с открытым исходным кодом RoboBinding - Структура модели Presentation-binding для платформы Android. RoboBinding помогает вам писать код пользовательского интерфейса, который легче читать, тестировать и поддерживать. RoboBinding устраняет необходимость ненужного кода, такого как addXXListener или так, и переносит логику пользовательского интерфейса на модель представления, которая является pojo и может быть протестирована с помощью обычных тестов JUnit. RoboBinding поставляется с более чем 300 тестов JUnit для обеспечения его качества. Другие альтернативы: Android-Binding, Bindroid и MvvmCross.