В этой статье мы поговорим об архитектурных шаблонах, используемых в Android-приложениях.
Почему важно понимание шаблонов, реализованных в рамках некой архитектуры? Потому что таким образом изучаемая нами новая архитектура укладывается в контекст нашего предыдущего опыта и позволяет нам более эффективно использовать накопленные знания и навыки.
Возможно, я плохо искал, но в документации Android нет упоминания о каких-либо шаблонах. Не смотря на это, в Android реализованы некоторые шаблоны и архитектурные стили, о которых мы сейчас и поговорим.
Архитектура Android является фреймворк-ориентированной (framework-based), в противовес вольной (free-style) архитектуре.
В чём разница? Вольные приложения, написанные на Java, начинаются с класса, имеющего метод main(), и разрабатываются в полном соответствии с настроением разработчика.
В противоположность этому фреймворк-ориентированные приложения основываются на существующем фреймворке. Их разработка сводится к расширению неких классов или реализации интерфейсов, предоставленных фрейморком. Такое приложение не может быть запущено вне фреймворка или без него. Примером могут быть веб-приложения на Java, в которых разработчики реализуют интерфейс Servlet или расширяют одну из его реализаций, или приложения Eclipse RCP, в котором разработчик расширяет один из классов Editor или View.
Фреймворк-ориентированная архитектура ограничивает свободу разработчиков, предписывая им что и как следует делать. Но, в итоге, исчезают повторяющиеся участки кода (boilerplate code), и разработчикам приходится (хотелось бы в это верить) тщательно следовать шаблонам проектирования.
Для Java существует множество фреймворков. Тем не менее, команда Android решила создать свой собственный. Возможно, одной из причин, по которой они так поступили, была необходимость поддерживать уникальную систему управления памятью.
В «обычной» Java объекты находятся в памяти до тех пор, пока сборщик мусора не доберётся до них. Происходит это только тогда, когда на объект нет ни одной ссылки от «живых» объектов (подробнее можно почитать здесь). В Android это не так. Если некий интерфейс пользователя скрывается (то есть он более не видим на экране), то нет никакой гарантии, что он находится в памяти, даже есть приложение в дальнейшем собирается использовать его. Если у ОС Android есть достаточно свободной памяти, эти объекты могут храниться в ней, но сборщик мусора может уничтожить их в любой момент, когда ОС решит, что памяти осталось слишком мало. То же верно и для процессов. Процесс, который в данный момент времени не показывает пользователю никакого графического интерфейса, может быть уничтожен ОС Android на абсолютно законных основаниях (есть одно исключение из этого правила — сервисы; об этом мы поговорим позже).
Рассмотрим пример. Пусть наше приложение имеет экраны A и B. Пользователь сначала открывает экран A, а затем экран B; с этого момента экран A стал невидим. Это означает, что экран A и вся логика, содержащаяся в нём, может находиться в памяти, а может и не находиться. Так, нет гарантий, что объекты, связанные с экраном A находятся в памяти, пока виден экран B. Логика экрана B не должна завязываться на нахождение объектов экрана A в памяти. Побочный эффект состоит в том, что архитектура Android принуждает к использованию архитектурного стиля стиля «shared nothing». Это означает, что разные части Android приложения могут вызывать друг друга и взаимодействовать между собой только формально; ни один из них не может обратиться к другому напрямую.
Хорошо, а что случится, если пользователь решит вернуться на экран A? Наверное, он захочет увидеть его в том же состоянии, в котором он оставил его, верно? Вот как фреймворк Android решает эту проблему: для каждого состояния жизненного цикла существуют методы, каждый из которых может быть переопределён разработчиком. Эти методы вызываются фреймворком в заранее определённые ключевые моменты, например, когда пользовательский интерфейс показывается на экране, прячется и т.п. В этих методах разработчик может реализовать логику для хранения и восстановления состояния объектов.
Подобная обработка скрытия пользовательских интерфейсов и существование кнопки «назад» на Android-устройствах приводит к необходимости наличия стека пользовательских интерфейсов, в котором текущий видимый интерфейс помещается на вершину, а все остальные сдвигаются вниз (стековая операция «push»). Нажатие «назад» удаляет интерфейс с вершины стека и показывает элемент, который был за ним (стековая операция «pop»). Подобный стек существует в Android. В документации он называется «activity stack» или иногда «back stack».
В плане обработки взаимодействия между пользовательским интерфейсом и его логикой Android следует архитектурному шаблону «Model-View-ViewModel» (MVVM). Для разработчиков это хорошая новость, поскольку MVVM — самая лучшая архитектура GUI-приложений на настоящий момент.
Архитектура MVVM была создана с целью разделения труда дизайнера и программиста, которое невозможно, когда Java-разработчик пытается построить GUI в Swing или разработчик на Visual C++ пытается создать пользовательский интерфейс в MFC. Разработчики — сообразительные парни и имеют множество навыков, но создание удобных и привлекательных интерфейсов требует абсолютно других талантов, нежели те, которыми они обладают разработчики. Эта работа больше подходит для дизайнеров интерфейсов. Хорошие дизайнеры интерфейсов лучше знают, чего хотя пользователи, нежели эксперты в области проектирования и написания кода. Понятно, будет лучше, если дизайнер интерфейсов создаст интерфейс, а разработчик напишет код, который реализует логику этого интерфейса, но технологии типа Swing или MFC просто-напросто не позволяют поступать таким образом.
Архитектура MVVM решает эту проблему ясным разделением ответственности:
- Разработка пользовательского интерфейса совершается дизайнером интерфейсов с помощью технологии, более или менее естественной для такой работы (XML)
- Логика пользовательского интерфейса реализуется разработчиком как компонент ViewModel
- Функциональные связи между пользовательским интерфейсом и ViewModel реализуются через биндинги (bindings), которые, по сути, являются правилами типа «если кнопка A была нажата, должен быть вызван метод onButtonAClick() из ViewModel». Биндинги могут быть написаны в коде или определены декларативным путём (Android использует оба типа).
Архитектура MVVM используется в том или ином виде всеми современными технологиями, например Microsoft WPF и Silverlight, Oracle JavaFX, Adobe Flex, AJAX.
Мы упоминали, что различные части Android-приложения могут вызывать друг друга и взаимодействовать между собой только формально. Как же это достигается? Фреймворк Android использует несколько шаблонов взаимодействия:
- Обмен сообщениями с помощью класса Intent
- Наблюдатель с использованием классов Intent и BroadcastReceiver
- Позднее связывание с последующим вызовом метода используется для доступа к контент-провайдерам (ContentProviders) и локальным (внурипроцессным) сервисам (Services)
- Позднее связывание и межпроцессное взаимодейтсвие (Inter-process Procedure Communication, IPC) для вызова сервисов (AIDL)
Не волнуйтесь, если что-то из этого звучит непонятно. Подробные объяснения будут в следующих статьях.
На сегодня это всё.
Предыдущая статья: Архитектура Android-приложений. Часть I — истоки
Автор: ilichme
