Итак, мы уже говорили об истоках архитектуры ОС Android И о паттернах, реализованных в этой архитектуре .
Теперь пришло время поговорить о том, из чего состоит Android-приложение.
В этой статье будут представлены основные «персонажи» архитектуры приложений Android. В целом приложение для Android состоит из:
- Классы Java, являющиеся подклассами основных классов из Android SDK ( Вид , Активность , Поставщик услуг , Услуга , Широковещательный приемник , Намерение ) и классы Java, у которых нет родительских элементов в Android SDK.
- Манифест приложения
- Ресурсы, такие как строки, изображения и т. д.
- Файлы
Java-классы
На следующей диаграмме показана иерархия основных классов из Android SDK, с которыми придется иметь дело разработчику:
На самом деле классов гораздо больше, но это основные.
Желтым выделены те, с которыми разработчик работает напрямую (в частности, они унаследованы от них).
Остальные не менее важны, но используются реже.
Вид — базовый класс для всех виджетов пользовательского интерфейса (виджетов GUI).
Интерфейс Android-приложения представляет собой дерево экземпляров потомков этого класса.
Вы можете создать это дерево программно, но это неправильно.
Пользовательский интерфейс определяется с использованием XML (файлы слоев, файлы макета) и во время выполнения автоматически преобразуется (инфляция, термин Android) в дерево соответствующих объектов.
Сорт Активность и его подклассы содержат логику пользовательского интерфейса.
При ближайшем рассмотрении этот класс соответствует ViewModel в архитектурном шаблоне.
Модель-Представление-ViewModel (МВВМ).
Отношения между подклассом Activity и пользовательским интерфейсом являются отношениями один к одному; Обычно с каждым подклассом Activity связан только один уровень пользовательского интерфейса, и наоборот. Действие имеет жизненный цикл.
В течение своего жизненного цикла Activity может находиться в одном из трех состояний:
- Активен и работает — этот пользовательский интерфейс находится на переднем плане (технически говоря — вверху стека активности).
- Приостановлено — если данный пользовательский интерфейс потерял фокус, но все еще виден.
В этом состоянии никакой код не выполняется.
- Завершено — если пользовательский интерфейс невидим.
В этом состоянии код не выполняется.
Нет никакой гарантии, что Activity и связанные с ним объекты находятся в памяти, когда Activity приостанавливается или завершается (очень важно помнить об этом; ранее Мы уже обсуждали этот аспект управления памятью в Android).
Сорт Поставщик услуг и его подклассы представляют модель в архитектуре MVVM. В большинстве практических случаев это оболочка базы данных SQLite с немного причудливым методом доступа на основе URI. Теоретически никто не мешает разработчику создать ContentProvider на основе чего-то другого, кроме базы данных.
Однако существующий метод query() поставщика контента возвращает объект Курсор , который очень похож на JDBC Набор результатов интерфейс и как он работает. Поэтому нет никаких сомнений в том, что настоящая цель поставщиков контента — инкапсулировать базу данных.
Я не знаю, как команда Android придумала такой дизайн, но, на мой взгляд, он сочетает в себе две хорошие, но не очень совместимые идеи.
И вот почему я так думаю.
Основная идея контент-провайдеров, похоже, основана на архитектуре приложений AJAX. Приложения AJAX обычно используют архитектуру MVVM, где модель представлена в виде URI на стороне сервера (однако это изменилось с появлением HTML5, который позволяет хранить данные локально).
Действительно, тот факт, что поставщики контента запрашиваются с использованием URI и создают расширение с использованием типов MIME, указывает на то, что в основе лежит AJAX. Напомню, что ребята из Google создали большое количество AJAX-приложений, таких как Gmail, Google Docs и т. д., поэтому вполне естественно, что идеи были позаимствованы из архитектуры AJAX. Возможно, кому-то еще пришла в голову еще одна замечательная идея: как было бы здорово иметь полноценную реляционную базу данных на мобильном устройстве! (Обратите внимание, что это было примерно в 2005 году, когда сотовые телефоны были намного слабее, чем сейчас).
И в результате они объединили две хорошие идеи в один класс ContentProvider. Как это часто бывает при разработке программного обеспечения, объединение двух хороших идей не всегда приводит к хорошей идее; в случае с Android мы имеем несколько обескураживающий дизайн поставщиков контента.
Сорт Услуга и мне сложно как-то классифицировать его подклассы.
Думаю, у ребят из Google те же трудности (пожалуйста, прочитайте их документацию).
Их классификация в основном говорит вам, чем этот класс не является.
Лично я считаю, что Сервис — это вариант Модели, обслуживающий несколько другие варианты использования, чем ContentProvider. На мой взгляд, архитектурный дизайн Android Service вдохновлен услуги ОСГИ .
Я думаю, что сервисы были созданы ребятами из Google как решение логической проблемы, созданной потоковой моделью Android. Подумайте об этом: действие активно и выполняется только тогда, когда его пользовательский интерфейс находится на переднем плане.
Как только интерфейс другого Activity перекрывает текущий, последний останавливается, даже если он что-то делал.
Что делать, если вам нужно выполнить какую-то операцию, даже если процесс, который ее выполняет, не находится на переднем плане? Вы не можете сделать это с помощью Activity. Вы также не можете сделать это с ContentProvider, поскольку у них нет собственного жизненного цикла и они могут выполняться только тогда, когда активное действие, использующее его.
И тут на помощь приходят сервисы.
Они могут работать, даже если процесс, в котором они выполняются, не находится на переднем плане.
Итак, если вы разрабатываете действие, выполняющее трудоемкую операцию, которая должна завершиться даже во время работы в фоновом режиме, вам следует создать Службу, реализующую эту операцию, и запустить ее из действия.
У сервиса также есть жизненный цикл.
Это означает, что его экземпляр может быть создан и запущен приложением Android при выполнении некоторого условия (мы обсудим это позже).
Как я уже упоминал, Сервис как модель преследует более общие цели, чем ContentProvier. Он может использовать базу данных, но его API не подключен к базе данных, как в случае с ContentProvider. В большинстве случаев сервисы используются для связи с внешними серверами.
Сорт Широковещательный приемник и его подклассы представляют «подписчика» в механизме взаимодействия издатель/подписчик , реализованный в архитектуре Android. О механизмах взаимодействия мы уже говорили в предыдущей статье.
Конечно, разработчик Android не ограничивается лишь расширением классов из Android SDK. Он может писать свои собственные классы так, как хочет. Но все они будут лишь вспомогательными классами для классов из Andoird SDK.
Android-манифест
Android-манифест — еще одна важная часть Android-приложения.Идея была вдохновлена Манифесты плагина Eclipse .
Манифест Android представляет собой XML-файл и выполняет несколько функций.
Вот как их описывает Google:
- Указывает имя пакета Java приложения.
Имя пакета является уникальным идентификатором приложения.
- Описывает компоненты приложения – действия, сервисы, приемники вещания и поставщики контента.
Определяет имена классов, реализующих каждый из компонентов, и объявляет их возможности (например, какие сообщения Intent они могут обрабатывать).
Эти объявления позволяют системе Android узнать, какие компоненты можно запустить и при каких условиях.
- Определяет процессы, которые будут содержать компоненты приложения.
- Объявляет разрешения, которые приложение должно иметь для доступа к защищенным частям API и взаимодействия с другими приложениями.
- Также объявляет разрешения, необходимые для доступа к компонентам приложения.
- Перечисляет классы инструментирования, которые предоставляют профилирование и другую информацию во время работы приложения.
Эти объявления присутствуют в манифесте только во время разработки и тестирования приложения; они удаляются до публикации приложения.
- Объявляет минимальный уровень Android API, необходимый приложению.
- Перечисляет библиотеки, с которыми должно связываться приложение.
Ресурсы
Каждое современное приложение с графическим интерфейсом в той или иной форме использует ресурсы.Приложения для Android не являются исключением.
Они используют следующие виды ресурсов:
- Изображений
- Слои графического интерфейса (файлы XML)
- Рекламные меню (файлы XML)
- Текстовые строки
Обычно в Java ресурсы идентифицируются строками.
Такие строки могут содержать, например, путь и имя файла, содержащего изображение, или идентификатор этой строки и т. д. Проблема в том, что ошибки в таких ссылках невозможно обнаружить в процессе трансляции кода.
Давайте посмотрим на следующий пример.
Файл с именем mybutton.png содержит изображение кнопки.
Разработчик допускает ошибку и вводит mybuton.png, ссылаясь на ресурс из кода.
В результате код пытается использовать несуществующий ресурс, но компиляция пройдет успешно.
Ошибка может быть обнаружена только в ходе тестирования (а может и не быть обнаружена вообще).
Ребята из Google нашли элегантное решение этой проблемы.
При создании приложения Android используется специальный класс Java, называемый р (всего одна буква).
Этот класс содержит несколько статических окончательных наборов данных.
Каждый такой набор данных представляет собой ссылку на отдельный ресурс.
Эти ссылки используются в коде приложения для ссылки на ресурсы.
Теперь каждая ошибка в ссылке на ресурс проявляется в процессе компиляции.
Файлы
Приложение Android использует несколько различных типов файлов:- Файлы «общего назначения»
- файлы БД
- Непрозрачные двоичные файлы Blob ( ОББ ) (они представляют собой зашифрованную файловую систему, которую можно смонтировать для приложения)
- Кэшированные файлы
Они также отделены от файлов, хранящихся во внутреннем или внешнем хранилище (последнее может отсутствовать или исчезнуть/появиться в любой момент).
API для работы с файлами реализован классом Контекст , из которого получены классы Activity и Service. Этот класс уже обсуждался нами Здесь .
Это все на сегодня.
В следующей статье мы поговорим о том, как различные части Android-приложения взаимодействуют друг с другом.
Предыдущие статьи:
- Архитектура Android-приложений.
Часть I. Происхождение
- Архитектура Android-приложений.
Часть II. Архитектурные стили и узоры
Часть IV – уровень интеграции
Теги: #Android #Влад Невзоров #Влад Невзоров #архитектура приложений #архитектура приложений для Android #Разработка под Android-
Аргеландер, Фридрих Вильгельм Август
19 Oct, 24 -
Войди В It: Риск Стать Стажером Оправдался
19 Oct, 24 -
Ищу Людей
19 Oct, 24 -
Сколько Инструкций В X86?
19 Oct, 24 -
Сетка Дизайн Или Макет С Сеткой.
19 Oct, 24 -
Как Работает Vmware Drs
19 Oct, 24 -
Google, Скорее Всего, Приобретет Spot Runner
19 Oct, 24
