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

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

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

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

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

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

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

Что относительно Presenter против адаптера?

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

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

Модель-View-Presenter – это действительно плохая идея для Android? Или это хорошо подходит для Android Framework?

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

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

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

Solutions Collecting From Web of "Модель-View-Presenter и дизайн приложений для Android"

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

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

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