Архитектура приложения Android - какова предложенная модель? [закрытый]
Таким же образом веб-приложение или настольное приложение могли бы иметь три или уровни n - UI, Бизнес, Данные, например - какова предложенная структура для приложения Android? Как Вы собираете в группу классы, какие слои Вы имеете и т.д.?
Я только запускаю Android dev (основанное на Интернете приложение, которое должно ответить на входящие уведомления), и не имейте никакого реального чувства для структуры, к которой я стремлюсь. Предложения ценятся.
1 ответ
Действия, представления и действия в Android запрограммированы в способе работы с пользовательским интерфейсом Android и являются реализацией шаблона модель-представление-модель просмотра, которая структурно аналогична (в том же семейство как) контроллер представления модели.
Насколько мне известно, выйти за рамки этой модели невозможно. Вероятно, это можно сделать, но вы, вероятно, потеряете все преимущества существующей модели, и вам придется переписать свой собственный слой пользовательского интерфейса, чтобы он заработал.
Вы можете найти MVC в следующем:
- Вы определяете свой пользовательский интерфейс в различных файлах XML по разрешению / оборудованию и т. Д.
- Вы определяете свои ресурсы в различных XML-файлы по языку и т. Д.
- Вы храните данные в SQLite или ваши пользовательские данные в папке / assets /, подробнее о ресурсах и активах
- Вы расширяете классы, такие как ListActivity , ] TabActivity и использовать XML-файл с помощью надувных модулей
- . Вы можете создавать столько классов, сколько хотите для своей модели, и иметь свои собственные пакеты, которые будут действовать как структура
- Много of Utils уже написаны для вас. DatabaseUtils, Html,
Не существует единого шаблона MVC, которому вы могли бы подчиняться. MVC просто более или менее заявляет, что вы не должны смешивать данные и представление, так что, например, представления отвечают за хранение данных или классов, которые обрабатывают данные, непосредственно влияющие на представление.
Но, тем не менее, то, как Android работает с классами и ресурсами, иногда даже заставляет следовать шаблону MVC. На мой взгляд, более сложными являются действия, которые иногда отвечают за представление, но в то же время действуют как контроллер.
Если вы определяете свои представления и макеты в файлах xml, загружаете свои ресурсы из папки res, и если вы избегаете более или менее смешивать эти вещи в своем коде, то вы в любом случае следуете шаблону MVC.