Уровень приложений

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

Возможность организовывать взаимодействие между приложениями, предоставляя для этого определенные механизмы, сыграла важную роль в развитии разработки под ОС Android. Появление встраивания и переноса информации между приложениями стали возможны благодаря этому.

Архитектура Android:

Архитектура Android является фреймворк-ориентированной (framework-based), в противовес вольной (free-style) архитектуре. Free-style приложения, написанные на Java, начинаются с класса, имеющего метод public static void main(String args[]), и разрабатываются на основании предпочтений разработчиков и требований задачи. Фреймворк-ориентированные приложения основываются на существующем фреймворке. Их разработка сводится к расширению неких классов или реализации интерфейсов, предоставленных фрейморком. Такое приложение не может быть запущено вне фреймворка или без него. Фреймворк-ориентированная архитектура ограничивает свободу разработчиков, предписывая им что и как следует делать. Но, в итоге, исчезают повторяющиеся участки кода (boilerplate code), разработчики реализуют лишь часть компонентов и встраивают их в платформу.

Для Java существует множество фреймворков. Тем не менее, команда Android решила создать свой собственный. Возможно, одной из причин, по которой они так поступили, была необходимость поддерживать уникальную систему управления памятью.

В «обычной» Java объекты находятся в памяти до тех пор, пока сборщик мусора не доберётся до них. Происходит это только тогда, когда на объект нет ни одной ссылки от «живых» объектов. В Android это не так. Если некий интерфейс пользователя скрывается (то есть он более не видим на экране), то нет никакой гарантии, что он находится в памяти, даже если приложение в дальнейшем собирается использовать его. Если у ОС Android есть достаточно свободной памяти, эти объекты могут храниться в ней, но сборщик мусора может уничтожить их в любой момент, когда ОС решит, что памяти осталось слишком мало. То же верно и для процессов. Процесс, который в данный момент времени не показывает пользователю никакого графического интерфейса, может быть уничтожен ОС Android.

Фреймворк Android решает возникающую при этом проблему хранения состояний у «спрятанных» компонентов: для каждого состояния жизненного цикла существуют методы, каждый из которых может быть переопределён разработчиком. Эти методы вызываются фреймворком в заранее определённые ключевые моменты, например, когда пользовательский интерфейс показывается на экране, прячется и т.п. В этих методах разработчик может реализовать логику для хранения и восстановления состояния объектов. Подобная обработка скрытия пользовательских интерфейсов и существование кнопки «назад» на Android-устройствах приводит к необходимости наличия стека пользовательских интерфейсов, в котором текущий видимый интерфейс помещается на вершину, а все остальные сдвигаются вниз (стековая операция «push»). Нажатие «назад» удаляет интерфейс с вершины стека и показывает элемент, который был за ним (стековая операция «pop»). Подобный стек существует в Android. В документации он называется «activity stack». В плане обработки взаимодействия между пользовательским интерфейсом и его логикой Android следует архитектурному MVVM, являющемуся лучшим решением для клиентских приложению.

Архитектура MVVM была создана с целью разделения труда дизайнера и программиста:

· Разработка пользовательского интерфейса совершается дизайнером интерфейсов с помощью технологии, более или менее естественной для такой работы (XML)

· Логика пользовательского интерфейса реализуется разработчиком как компонент ViewModel

· Функциональные связи между пользовательским интерфейсом и ViewModel реализуются через биндинги (bindings), которые, по сути, являются правилами типа «если кнопка A была нажата, должен быть вызван метод onButtonAClick() из ViewModel». Биндинги могут быть написаны в коде или определены декларативным путём (Android использует оба типа).

Структура приложения:

В общем случае, Android-приложение состоит из:

· Java-классов, являющихся подклассами основных классов из Android SDK и Java-классов, у которых нет родителей в Android SDK.

· Манифеста

· Ресурсов наподобие строк, изображений и т.п.

· Файлов

Java-классы

View— базовый класс для всех виджетов пользовательского интерфейса. Интерфейс Android-приложения представляет собой дерево экземпляров наследников этого класса. Можно создать это дерево программно, но это неправильно. Пользовательский интерфейс определяется с помощью XML (файлы слоёв, layout files), а во время исполнения автоматически превращается (inflate, термин Android) в дерево соответствующих объектов.

КлассActivity и его подклассы содержат логику, лежащую за пользовательским интерфейсом. При ближайшем рассмотрении этот класс соответствует ViewModel в архитектурном шаблоне Model-View-ViewModel(MVVM). Отношение между подклассом Activity и пользовательским интерфейсом — это отношение один к одному; обычно каждый подкласс Activity имеет только один связанный с ним слой пользовательского интерфейса, и наоборот. Activity имеет жизненный цикл.

В течении жизненного цикла Activity может находиться в одном из трёх состояний:

· Активно и выполняется — этот пользовательский интерфейс находится на переднем плане (говоря технически — на вершине стека активити)

· Приостановлено — если данный интерфейс пользователя потерял фокус, но всё ещё видим. В таком состоянии никакой код не выполняется.

• Завершено — если интерфейс пользователя невидим. В таком состоянии код не выполняется.

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

Класс Service и его подклассы реализуют механизм долгого непрерывного выполнения какого-либо действия. Особенностью является то, что сервисы не привязаны к активити, следовательно их работа не будет приостановлена, когда активити сменится или будет скрыто. Service может быть инстанцирован и запущен Android-приложением по некому условию.

Класс BroadcastReceiver и его подклассы представляют собой «подписчика» в механизме взаимодейтсвия издатель/подписчик, реализованном в архитектуре Android.

Разработчик под Android не ограничен одним только расширением классов из Android SDK. Он может писать собственные классы так, как захочет. Но все они будут только хелперами («helper classes») для классов из Andoird SDK.

Android Manifest

Манифест Android—важная часть Android-приложения. Вот как их описывает Google:

· Определяет имя Java-пакета приложения. Имя пакета представляет собой уникальный идентификатор для приложения.

· Описывает компоненты приложения — активити, сервисы, броадкаст-ресиверы и контент-провайдеры. Определяет имена классов, реализующие каждый из компонентов и оглашает их возможности (например, какие Intent-сообщения они могут обрабатывать). Эти объявления позволяют системе Android знать, какие компоненты и при каких условиях могут быть запущены.

· Предопределяет процессы, которые будут содержать компоненты приложения.

· Объявляет разрешения, которые приложение должно иметь для доступа к защищённым частям API и взаимодействия с другими приложениями.

· Также объявляет разрешения, которые требуются для доступа к компонентам приложения.

· Перечисляет классы Instrumentation, которые предоставляют профайлинг и другую информацию во время работы приложения. Эти объявления присутствуют в манифесте только пока приложение разрабатывается и тестируется; они удаляются перед публикацией приложения.

· Объявляет минимальный уровень Android API, который требует приложение.

· Перечисляет библиотеки, с которыми приложение должно быть связано.

Ресурсы

Android-приложения используют следующие типы ресурсов:

· Изображения

· Слои GUI (XML файлы)

· Объявления меню (XML файлы)

• Текстовые строки

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

При сборке Android-приложения генерируется специальный Java-класс с именем R. Этот класс содержит несколько static final наборов данных. Каждый такой набор данных — ссылка на отдельный ресурс. Эти ссылки используются в коде приложения для связи с ресурсами. Теперь каждая ошибка в ссылке на ресурсы проявляет себя в процессе компиляции.

Файлы

Android-приложение использует несколько разных типов файлов:

· Файлы «общего назначения»

· Файлы БД

· Файлы Opaque Binary Blob (OBB) (они представляют собой зашифрованную файловую систему, которая может быть монтирована для приложения)

· Закешированные файлы

Хотя, в конечно итоге, все они только файлы Linux, имеет смылсл рассматривать их как отдельные типы файлов только в разрезе обработки их различным API и отдельного хранения. Также они отделены от файлов, хранящихся во внутреннем или внешнем хранилище (последнее может отсутствовать или исчезнуть/появиться в любой момент).

API для работы с файлами реализован классом Context, от которого порождены классы Activity и Service.

Поиск по сайту: