Какой принцип шаблона дизайна в Android-разработке?

Ответ 1

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

• Активность == Контроллер
• Модель == Подкласс приложения
• Все, что подклассы View == View

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

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

Проблемы с Android - это то, что он смешивает контроллер и просматривает довольно сильно. Например, подклассы типа TabActivity, ListActivity подразумевают использование определенного вида. Так что обмен мнениями довольно востребован. Также Контроллер делает очень конкретные предположения о том, что представляет собой представление, даже если вы используете Activity. Он содержит прямые ссылки на объекты пользовательского интерфейса, такие как TextView и т.д. И он регистрирует события низкого уровня, такие как клики, клавиатура и т.д.

Было бы лучше, если бы активность могла регистрироваться для событий более высокого уровня, таких как "Вход", "Обновить баланс аккаунта" и т.д., которые будет отображать представление в ответ на серию кликов, событий клавиатуры, касания. Таким образом, контроллер работает на уровне, который вы могли бы описать, а не на конструктивных особенностях.

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

Ответ 2

Действия, представления и действия в 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.

Ответ 3

Разработка Android - это прежде всего разработка графического интерфейса, которая, как Swing/AWT в Java, состоит из множества анонимных внутренних классов, реагирующих на события GUI. Его одна из вещей, которая действительно мешала мне много работать с Swing.... но у меня есть телефон для Android, поэтому я собираюсь порезать зубы и просто пережить это, так много поклонников Apple сказал о проблемах с антенной.;)

Ответ 4

Android делает типичное решение сделать контроллер и просмотр одного класса. Это стимулирует слишком многого в том же месте. Активность соответствует экрану, каждый вид которого относится к области экрана (иногда по всему экрану), каждый контроллер к жесты пользователя из этой области экрана, а модели - это только модели, иногда поддерживаемые службами из среды или какой-либо другой сумасшедший набор функций полезности. Я использую Activity для координации одного или нескольких трио MVC. Это помогает решить проблему Android, чтобы просто бросить все в одном месте.

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

Ответ 5

Извините за мой английский.

Android имеет очень хорошую модульность (Activities, Fragments, Views, Services и т.д.). Поэтому в MVC нет необходимости.

Конечно, существует разделение на ввод данных (Activities, Fragments), логика, представление (xml или java) и данные (базы данных, файлы, предпочтения). Но это не MVC. Вы не должны пытаться использовать MVC, это только усложнит вашу архитектуру.

Вместо того, чтобы хранить что-то в глобальном масштабе, Android мотивирует вас держать объекты как можно глубже в своих областях (члены класса, локальные переменные), а также передавать объекты в/из видов деятельности или фрагменты, используя Intents/Bundles. Это также связано с ограничением памяти.

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

Поэтому небезопасно хранить не-постоянные (изменяемые) объекты как глобальные (статические) объекты. Обычно вы используете static для неизменяемых констант.

Проще говоря, вы отделяете свое приложение от экранов (Activities). Затем каждый экран - на фрагменты (фрагменты). Чтобы выполнить последовательность действий на экране, вы также можете разделить их с помощью фрагментов (пример).

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

Ответ 6

Мое впечатление, что модель программирования андроида имеет много общего с MS WPF. Определения макета XML, код, который всегда связан с одним из этих определений... Итак, если вы спрашиваете о шаблонах проектирования, потому что хотите улучшить свои текущие или в проектах разработки Android, возможно, вам стоит взглянуть на методы и шаблоны WPF для улучшения архитектуры, например MVVM.

Ознакомьтесь с этими ссылками:

http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

существует небольшой проект, который уже пытается использовать подобную вещь:

http://code.google.com/p/android-binding/

веселит