Android программы и их описание

Android приложения написаны на языке программирования Java. Инструменты Android SDK компилируют ваш код — включая все данные и ресуры — в файл APK (Android Package): пакет Android, который является архивом файлов с расширением .apk . Один APK файл включает все содержимое отдельного Android приложения и этот файл Android устройства используют для установки приложения.

После установки на устройство, каждое приложение работает в его собственной защищенной песочнице:

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

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

Эта Программа ЕСТЬ Только на Android

Однако, существуют способы обмена данными между приложениями и доступа к системным сервисам:

• Возможно установить для двух приложений общий идентификатор, в этом случае они смогут получить доступ к файлам друг друга. Для экономии ресурсов системы, приложения с одинаковым идентификатором могут также могут запускаться в одном и том же процессе и использовать одну и ту же виртуальную машину (приложения при этом должны быть подписаны одним и тем же сертификатом).
• Приложение может запросить разрешение на доступ к данным, например контактам, SMS сообщениям, присоединенным хранилищам (SD карты), камере, Bluetooth и другим. Все разрешения должны быть подтверждены пользователем во время установки приложения.

Это основы того, как Android приложение существует в системе. Остальная часть текущего документа познакомит вас:

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

Компоненты приложения

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

ЭЛИТНЫЕ android программы #40

Существует четыре разных типа компонентов. Каждый из них служит для различных целей, имеет свой собственный жизненный цикл, который определяет, как компонент создается и уничтожается.

Вот эти четыре типа:

Явления (Activities)

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

Явления реализуются как подклассы базового класса Activity, о них вы можете подробнее узнать в разделе Явления.

Сервисы (Services)

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

Службы реализуются как подклассы базового класса Service, о них вы можете подробнее узнать в разделе Сервисы.

Поставщики содержимого

Поставщики содержимого управляют общими данными в приложении. Вы можете хранить данные в файловой системе, в базе данных SQLite, в сети, в любом другом постоянном хранилище, к которому приложение имеет доступ. Через поставщики содержимого, другие приложения могут получить или модифицировать данные вашего приложения (если это разрешено). Например, Android предоставляет поставщик содержимого для управления контактными данными. Таким образом, любое приложение, которое имеет соответствующее разрешение, может запросить поставщики содержимого (например ContactsContract.Data) для чтения или изменения информации о каком-либо человеке.

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

Поставщики содержимого реализуются как подклассы базового класса ContentProvider и должны содержать стандартный набор методов, которые позволят другим приложениям выполнять транзакции. Подробную информацию смотрите в разделе Поставщики содержимого.

Широковещательные приемники

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

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

Широковещательные приемники реализуются как подклассы базового класса BroadcastReceiver и каждая рассылка передается как объект типа Intent. За подробной информацией обращайтесь к документации по классу BroadcastReceiver.

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

Вместо этого вы просто запускаете явление приложения Камера и делаете фотографию. После спуска затвора, фотография будет передана в ваше приложение и вы сможете ее использовать. Для пользователя будет казаться, что работа с камерой — это часть вашего приложения.

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

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

Запуск компонентов

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

Намерения создаются с помощью объектов типа Intent, которые определяют сообщение для запуска конкретного компонента или компонента заданного типа. Такие намерения называются соответственно явные и неявные.

Для явлений и сервисов, намерения определяют действие для выполнения (например, «что-то показать» или «что-то передать») и могут содержать URI данных. Например, намерение может передать запрос явлению, чтобы последнее показало изображение или веб-страницу. В некоторых случаях, вы можете запустить явление, чтобы получить от него результат. В таких случаях, явление возвращает результат так же в объекте Intent (например, вы можете оформить намерение для выбора контакта, и вам вернется другое намерение, содержащее URI, который указывает на выбранный контакт).

Для широковещательных приемников, намерения просто описывают сообщение, которое будет разослано (например, рассылка о низком заряде батареи может содержать только строку «батарея разряжена»).

Последний тип компонентов, поставщики содержимого, не могут быть запущены с помощью намерения. Они активируются, когда получают запрос от объекта типа ContentResolver. Этот объект обрабатывает все транзакции напрямую, используя поставщики содержимого и методы класса ContentResolver. Это оставляет слой абстракции между поставщиками содержимого и компонентом, запросившим информацию (для безопасности).

Вот различные методы для запуска каждого типа компонентов:

• Вы можете запустить явление (или заставить его сделать что-то новое), передав объект намерения Intent в метод startActivity() или startActivityForResult() (если вы хотите, чтобы явление вернуло результат работы).
• Вы можете запустить сервис (или передать новые инструкции на уже работающий), передав объект намерения Intent в метод startService(). Или можете связать сервис передав Intent в метод bindService().
• Вы можете инициировать рассылку передав намерение в методы sendBroadcast(), sendOrderedBroadcast() или sendStickyBroadcast().
• Вы можете выполнять запросы к поставщикам содержимого с помощью метода query() класса ContentResolver.

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

Файл манифеста

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

Кроме описания компонентов приложения, манифест служит также для следующих вещей:

• Указание разрешений, которые требуются приложению, например доступ в интернет или чтение контактов.
• Объявление минимального уровня API, который требуется для работы приложения.
• Объявление программных и аппаратных зависимостей, например камеры, bluetooth или экран с поддержкой нескольких прикосновений.
• Указание библиотек, который должны быть подключены к приложению, например Google Maps Library.
• И другое

Описание компонентов

Первичной задачей файла манифеста является информирование системы о компонентах приложения. Например, манифест может описывать явление следующим образом:

Источник: easyandroid.ru

Виды приложений и их структура

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

Презентацию к данной лекции можно скачать здесь.

3.1 Введение

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

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

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

3.2 Основные виды Android-приложений

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

• Приложения переднего плана выполняют свои функции только, когда видимы на экране, в противном же случае их выполнение приостанавливается. Такими приложениями являются, например, игры, текстовые редакторы, видеопроигрыватели. При разработке таких приложений необходимо очень внимательно изучить жизненный цикл активности, чтобы переключения в фоновый режим и обратно проходили гладко (бесшовно), т. е. при возвращении приложения на передний план было незаметно, что оно вообще куда-то пропадало. Для достижения этой гладкости необходимо следить за тем, чтобы при входе в фоновый режим приложение сохраняло свое состояние, а при выходе на передний план восстанавливало его. Еще один важный момент, на который обязательно надо обратить внимание при разработке приложений переднего плана, удобный и интуитивно понятный интерфейс 1 Вопросам создания предсказуемых и привлекательных интерфейсов пользователя посвящена тема 3 данного курса, а также тема 2 из второй части. .
• Фоновые приложения после настройки не предполагают взаимодействия с пользователем, большую часть времени находятся и работают в скрытом состоянии. Примерами таких приложений могут служить, службы экранирования звонков, SMS-автоответчики. В большинстве своем фоновые приложения нацелены на отслеживание событий, порождаемых аппаратным обеспечением, системой или другими приложениями, работают незаметно. Можно создавать совершенно невидимые сервисы, но тогда они будут неуправляемыми. Минимум действий, которые необходимо позволить пользователю: санкционирование запуска сервиса, настройка, приостановка и прерывание его работы при необходимости.
• Смешанные приложения большую часть времени работают в фоновом режиме, однако допускают взаимодействие с пользователем и после настройки. Обычно взаимодействие с пользователем сводится к уведомлению о каких-либо событиях. Примерами таких приложений могут служить мультимедиа-проигрыватели, программы для обмена текстовыми сообщениями (чаты), почтовые клиенты. Возможность реагировать на пользовательский ввод и при этом не терять работоспособности в фоновом режиме является характерной особенностью смешанных приложений. Такие приложения обычно содержат как видимые активности, так и скрытые (фоновые) сервисы, и при взаимодействии с пользователем должны учитывать свое текущее состояние. Возможно потребуется обновлять графический интерфейс, если приложение находится на переднем плане, или же посылать пользователю уведомления из фонового режима, чтобы держать его в курсе происходящего. И эти особенности необходимо учитывать при разработке подобных приложений.
• Виджеты — небольшие приложения, отображаемые в виде графического объекта на рабочем столе. Примерами могут служить, приложения для отображения динамической информации, такой как заряд батареи, прогноз погоды, дата и время. Разумеется, сложные приложения могут содержать элементы каждого из рассмотренных видов. Планируя разработку приложения, необходимо определить способ его использования, только после этого приступать к проектированию и непосредственно разработке.

3.3 Безопасность

Обратим внимание на организацию исполнения приложений в ОС Android . Как уже было отмечено приложения под Android разрабатываются на языке программирования Java , компилируется в файл с расширением .apk, после этот файл используется для установки приложения на устройства, работающие под управлением Android . После установки каждое Android приложение «живет» в своей собственной безопасной «песочнице», рассмотрим, как это выглядит:

• операционная система Android является многопользовательской ОС, в которой каждое приложение рассматривается как отдельный пользователь;
• по умолчанию, система назначает каждому приложению уникальный пользовательский ID, который используется только системой и неизвестен приложению;
• система устанавливает права доступа ко всем файлам приложения следующим образом: доступ к элементам приложения имеет только пользователь с соответствующим ID;
• каждому приложению соответствует отдельный Linux процесс, который запускается, как только это необходимо хотя бы одному компоненту приложения, процесс прекращает работу, когда ни один компонент приложения не использует его или же системе требуется освободить память для других (возможно, более важных) приложений;
• каждому процессу соответствует отдельный экземпляр виртуальной машины Dalvik, в связи с этим код приложения исполняется изолировано от других приложений.

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

Однако, в случае необходимости приложения могут получить доступ к данным других приложений и системным сервисам (услугам). В случае, когда двум приложениям необходимо иметь доступ к файлам друг друга, им присваивается один и тот же пользовательский ID . Для экономии системных ресурсов такие приложения запускаются в одном Linux процессе и делят между собой один и тот же экземпляр виртуальной машины, в этом случае приложения также должны быть подписаны одним сертификатом. В случае же, когда приложению требуется доступ к системным данным, например, контактам, SMS сообщениям, картам памяти, камере, Bluetooth и т. д., пользователю необходимо дать приложению такие полномочия во время установки его на устройство.

Источник: intuit.ru

Архитектура Android-приложений. Часть III — основные части приложения

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

В этой статье будут представлены основные «персонажи» архитектуры Android-приложения.

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

• Java-классов, являющихся подклассами основных классов из Android SDK (View, Activity, ContentProvider, Service, BroadcastReciever, Intent) и Java-классов, у которых нет родителей в Android SDK.
• Манифеста приложения
• Ресурсов наподобие строк, изображений и т.п.
• Файлов

Java классы

На следующей диаграмме представлена иерархия основных классов из Android SDK, с которыми предстоит иметь дело разработчику:

На самом деле классов намного больше, но это основные. Выделенные жёлтым — те, с которыми разработчик работает непосредственно (в частности, наследуются от них). Остальные так же важны, но они реже используются напрямую.

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

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

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

• Активно и выполняется — этот пользовательский интерфейс находится на переднем плане (говоря технически — на вершине стека активити)
• Приостановлено — если данный интерфейс пользователя потерял фокус, но всё ещё видим. В таком состоянии никакой код не выполняется.
• Завершено — если интерфейс пользователя невидим. В таком состоянии код не выполняется.

Класс ContentProvider и его подклассы представляют model в архитектуре MVVM. В большинстве практических случаев это обёртка над базой данных SQLite с немного причудливым способом доступа на основе URI. Теоретически, никто не мешает разработчику создать ContentProvider на основе чего-то ещё, кроме базы данных. Тем не менее, существующий метод query() контент-провайдера возвращает объект Cursor, который крайне похож на JDBC ResultSet интерфейсом и тем, как он работает. Поэтому вряд ли кто-то усомнится, что настоящее назначение контент-провайдеров — инкапсулировать базу данных.

Я не знаю, как комманда Android пришла к такому дизайну, но, по-моему, здесь соединены две хороших, но не слишком совместимых идеи.

И вот почему я так считаю. Основная идея контент-провайдеров, похоже, базируется на архитектуре AJAX приложений. AJAX приложения обычно используют архитектуру MVVM, где модель представлена как URI на стороне сервера (тем не менее, это изменилось с поялвинем HTML5, который позволяет хранить данные локально). В самом деле, тот факт, что контент-провайдеры запрашиваются с помощью URI и создают расширение с помощью типов MIME указывает на то, что в основе лежит AJAX. Напомню, ребята из Google создали большое количество AJAX приложений, таких как Gmail, Google Docs и т.п., поэтому вполне естественно, что идеи заимствовались из архитектуры AJAX.

Возможно, кто-то ещё пришёл с ещё одной отличной идеей: как было бы здорово иметь полноценную реляционную базу на мобильном устройстве! (замечу, это было примерно в 2005 году, когда мобильные телефоны были намного слабее, чем сейчас). И, как результат, они соединили две хороших идеи в один класс ContentProvider. Как это обычно и случается в разработке ПО, соединение двух хороших идей не всегда даёт в результате хорошую идею; в случае Android мы имеем несколько обескураживающий дизайн контент-провайдеров.

Класс Service и его подклассы я затрудняюсь как-то классифицировать. Я думаю, ребята из Google испытывают те же трудности (прочтите, пожалуйста, их документацию). Их классификация, в основном, говорит, чем этот класс не является. Я лично думаю, что сервис — это разновидность Model, обслуживающая несколько иные варианты использования, нежели ContentProvider.

По-моему, архитектурный дизайн Android Service навеян сервисами OSGI.

Думаю, сервисы были созданы ребятами из Google как решение логической проблемы, возникшей из-за модели потоков Android.

Подумайте над этим: Activity активно и выполняется только когда его пользовательский интерфейс находится на переднем плане. Как только интерфейс другого Activity закрывает собой текущее, последнее останавливается, даже если оно что-то делало. А что, если вам нужно выполнять некую операцию, даже если процесс, которые её выполняет, не на переднем плане? С помощью Activity вы не сможете этого сделать. Вы не сможете это сделать и с помощью ContentProvider, поскольку у них нет собственного жизненного цикла, и они могут выполняться только пока Activity, использующее его, активно.

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

Service так же имеет жизненный цикл. Это означает, что он может быть инстанцирован и запущен Android-приложением по некому условию (мы обсудим это позже).

Как я уже упоминал, Service, как model, приследует более общие цели, нежели ContentProvier. Он может использовать базу данных, но его API не связано с БД, как в случае ContentProvider. В большинстве случаев сервисы используются для связи с внешними серверами.

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