Архитектура Android-Приложений. Часть Ii. Архитектурные Стили И Узоры

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

Возможно, я плохо искал, но в документации Android ни о каких шаблонах не упоминается.

Несмотря на это, в Android реализованы некоторые шаблоны и архитектурные стили, о которых мы сейчас поговорим.

Архитектура Android основана на фреймворке, в отличие от архитектуры свободного стиля.

В чем разница? Фристайл-приложения, написанные на Java, начинаются с класса, у которого есть метод. основной() , и разработаны в полном соответствии с настроением разработчика.

Напротив, приложения, ориентированные на платформу, основаны на существующей платформе.

Их разработка сводится к расширению определенных классов или реализации интерфейсов, предоставляемых фреймворком.

Такое приложение невозможно запустить вне или без фреймворка.

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

Архитектура, ориентированная на фреймворк, ограничивает свободу разработчиков, говоря им, что и как делать.

Но со временем шаблонный код исчезает, и разработчикам приходится (будем надеяться) тщательно следовать шаблонам проектирования.

Существует множество фреймворков для Java. Однако команда Android решила создать свою собственную.

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

В «обычной» Java объекты остаются в памяти до тех пор, пока к ним не доберется сборщик мусора.

Это происходит только тогда, когда нет ни одной ссылки на объект со стороны «живых» объектов (подробнее можно прочитать о Здесь ).

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

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

То же самое справедливо и для процессов.

Процесс, который в данный момент не показывает пользователю какой-либо графический интерфейс, может быть завершен ОС Android на абсолютно законных основаниях (из этого правила есть одно исключение — Услуги ; мы поговорим об этом позже).

Давайте посмотрим на пример.

Пусть в нашем приложении есть экраны A и B. Пользователь сначала открывает экран A, а затем экран B; с этого момента экран А стал невидимым.

Это означает, что экран A и вся содержащаяся в нем логика могут находиться или не находиться в памяти.

Таким образом, нет никакой гарантии, что объекты, связанные с экраном A, находятся в памяти, пока экран B виден.

Логика экрана B не должна быть привязана к поиску объектов экрана A в памяти.

Побочным эффектом является то, что архитектура Android требует использования архитектуры стилей.

"ничего не делил" .

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

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

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

Подобная обработка сокрытия пользовательских интерфейсов и наличие кнопки «Назад» на устройствах Android приводит к необходимости куча пользовательские интерфейсы, в которых текущий видимый интерфейс размещается сверху, а все остальные опускаются вниз (операция «толкания» стека).

Нажатие «назад» удаляет интерфейс из вершины стека и показывает элемент, который находился за ним (операция «выталкивания» стека).

Похожий стек существует в Android. В документации это называется «стек активности» или иногда "задняя стопка" .

Что касается взаимодействия между пользовательским интерфейсом и его логикой, Android следует архитектурному шаблону.

«Модель-Представление-ПредставлениеМодели» (МВВМ).

Это хорошая новость для разработчиков, поскольку MVVM — лучшая архитектура приложений с графическим интерфейсом, доступная на сегодняшний день.

Архитектура MVVM была создана для разделения труда между проектировщиком и программистом, что невозможно, когда разработчик Java пытается создать графический интерфейс в Swing или разработчик Visual C++ пытается создать пользовательский интерфейс в MFC. Разработчики — умные ребята и обладают множеством навыков, но создание удобных и привлекательных интерфейсов требует совсем других талантов, чем те, которыми обладают разработчики.

Эта работа больше подойдет дизайнерам интерфейсов.

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

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

Архитектура MVVM решает эту проблему за счет четкого разделения обязанностей:

Разработку пользовательского интерфейса осуществляет дизайнер интерфейса с использованием более или менее естественной для такой работы технологии (XML).
Логика пользовательского интерфейса реализована разработчиком в виде компонента ViewModel.
Функциональные связи между пользовательским интерфейсом и ViewModel реализуются через привязки, которые по сути представляют собой правила типа «если была нажата кнопка A, должен быть вызван метод onButtonAClick() ViewModel».
Привязки можно писать в коде или определять декларативно (Android использует оба типа).

Архитектура MVVM в той или иной форме используется всеми современными технологиями, например Microsoft WPF и Silverlight, Oracle JavaFX, Adobe Flex, AJAX. Мы упоминали, что разные части Android-приложения могут вызывать друг друга и взаимодействовать друг с другом только формально.

Как это достигается? Платформа Android использует несколько шаблонов взаимодействия: