Архитектура Android-приложений - какова предлагаемая модель?

Ответ 1

Действия, представления и действия в Android - это запекание в работе с Android UI и реализация шаблона model-view-viewmodel, который является структурно схожим (в том же семействе, что и) контроллер представления модели.

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

Вы можете найти MVC в следующих файлах:

• Вы определяете свой пользовательский интерфейс в различных файлах XML по разрешению/оборудованию и т.д.
• Вы определяете свой resources в различных файлах XML по языку и т.д.
• Вы сохраняете данные в SQLite или свои пользовательские данные в /assets/folder, читайте больше о ресурсы и активы
• Вы распространяете кланы типа ListActivity, TabActivity и использовать XML файл inflaters
• Вы можете создать столько классов, сколько пожелаете для своей модели, и иметь свои собственные пакеты, которые будут действовать как структура.
• Много Utils уже написаны для вас. DatabaseUtils, Html,

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

Но тем не менее, способ Android имеет дело с классами и ресурсами, иногда вы даже вынуждены следовать шаблону MVC. Более сложными в моей работе являются действия, которые иногда отвечают за представление, но тем не менее действуют как контроллер одновременно.

Если вы определяете свои представления и макеты в файлах xml, загружайте свои ресурсы из папки res, и если вы избегаете более или менее смешать это в своем коде, тогда вы все равно следуете шаблону MVC.

Ответ 2

IMHO, Android "хочет" следовать шаблону MVC, но просмотр и контроллер обычно связаны друг с другом в действиях.

Это делает unit test сложнее, и ему трудно подчиниться принцип единой ответственности.

Я нашел действительно красивую архитектуру Android, представленную здесь, может возникнуть идея. Все слабо взаимосвязано, так проще тестировать и редактировать.

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

Ответ 3

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

Я работаю над Android уже 9 месяцев со стороны сервера, где полно модульное тестирование и многоуровневые архитектуры являются общими и работают хорошо.

Через множество проб и ошибок, и я настоятельно рекомендую использовать шаблон Model View Presenter, а не Model View Controller.

Огромная проблема, которую я обнаружил, заключается в том, что Activities/Fragments имеет жизненный цикл, который находится вне вашего контроля и может привести к неожиданным проблемам.

Например, наше основное приложение для Android требует использования в ландшафтном режиме на планшетах. Мы делаем это в OnCreateView() или OnCreate().

В представлении Nexus 7 по умолчанию отображается портрет, поэтому происходит то, что он начинает свою деятельность в портретном режиме, и наш код говорит, что переход к пейзажу, и андроид в конечном итоге создает класс activity 3 раза!

Мы подключили сетевые запросы к onCreate, и в этом случае они заканчиваются 3 раза.

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

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

Когда результаты от сетевых вызовов возвращаются, либо сообщение на шину, такое как Otto, которое зарегистрировало активность (регистр для события на onResume() и отменит регистрацию в течение onPause()), или убедитесь, что интерфейс обратного вызова реализован активность была обновлена ​​до последней активности в презентаторе.

Таким образом, код в presenter вниз является тестируемым модулем и не зависит от проверки сломанного уровня пользовательского интерфейса.

Ответ 4

MVP - это последняя архитектура, за которой следуют большинство людей Вот небольшая документация Как Чистая архитектура дяди Боба говорит: "Архитектура - это намерение, а не рамки"

Посмотрите это видео, это просто разумно.

Ответ 5

Вот выделенный проект для схемы архитектуры Android с хорошо документированными исходными кодами. Все они основаны на шаблоне MVP с несколькими завихрениями. Также проверьте сравнение различных решений на основе строк кода, тестируемости, стоимости обучения, их поддержки для увеличения сложности данных. Это зависит от специально разработанного приложения и контекста (время выхода на рынок, разработчиков, планы на будущее и т.д.), Который лучше всего подходит.