Наименее распространённой IDE является NetBeans, поскольку она используется в основном пользователями Linuх, которые ранее применяли NetBeans для своих проектов.
На данный момент весьма перспективно выглядит IDE от Google - Android Studio. Она позиционируется как специализированное средство для Android-разработки от компании разработчика самой ОС. Android Studio основывается на InelliJ IDEA и обладает всеми её достоинствами. В добавок к этому Android Studio содержит специализированные средства разработки и анализа кода, специфичные для Android-разработки. Пожалуй, единственным недостатком Android Studio является то, что она официально всё ещё находится в стадии бета-тестирования. При разработке данного проекта использовалась именно эта IDE. Подробнее ознакомится с данным продуктом можно с помощью [10]. Там же можно найти подробные описания процесса миграции проектов на новою IDE с других популярных решений.
Отличительной особенностью Android Studio является использование постепенно набирающей популярность системы сборки Gradle. Её описание можно найти на официальном сайте [11] или же на ресурсе [12], применительно конкретно к Android Studio. К особенностям Gradle, выгодно отличающей её от других систем сборки, стоит отнести сплав концепции «build by convention», используемой во всех популярных аналогах, например, Maven, с использование скриптов на языке Groovy. Подобный подход позволяет легко создавать многомодульные сборки, что весьма актуально для Android-проектов, использующих пользовательские библиотеки. Ещё одной возможностью Gradle, активно используемой в Android Studio является возможность создавать основанные на Gradle проекты, при этом фактически всё, что необходимо - это пара стандартных скриптов для построения и скачиваемый из общедоступного репозитория модуль для их обработки. Подобная лаконичная структура весьма эффектно смотрится при использовании системы контроля версий: фактически все файлы проекта являются функционально необходимыми и не захламляют репозиторий.
Стоит отметить, что все выше перечисленные среды разработки либо являются полностью бесплатными, либо имеют бесплатные версии.
В заключении следует упомянуть некоторые источники, специфичные для данного дипломного проекта. В проекте активно используется взаимодействие с базой данных (БД). На ОС Android в качестве БД использует SQLite. SQLite является простой, легковесной реляционной базой данных, используемой на всех популярных мобильных платформах (iOS, Windows Phone). Помимо официальной документации [4], описывающей шаблон проектирования для работы с БД, полезным является официальная документация БД [13]. SQLite обладает определёнными особенностями, ознакомление с которыми необходимо даже при наличии опыта работы с другими реляционными БД. SQLite содержит всего лишь четыре типа данных и не поддерживает хранимые процедуры. Вдобавок к этим ограничениям, добавляется и то, что входящие в Android SDK средства для работы БД не способствуют созданию даже самой простой структуры БД с зависимостями между таблицами, всячески подталкивая к хранению данных в нескольких больших, несвязанных таблицах.
Одной из ключевых особенностей дипломного проекта, является работа с визуальной информацией, то есть использование камеры. Несмотря на исчерпывающее описание процесса работы с камерой как в официальной документации, так и в литературе, камера остаётся весьма специфическим устройством. В основном это связано с большим разнообразием используемых фотомодулей, так или иначе влияющим на стандартный процесс взаимодействия. К сожалению, не существует единого источника, описывающего все, или хотя основные, подводные камни в работе с камерой, однако в качестве полезнейшего ресурса, во многом помогающего разработке, в том числе и в вопросах взаимодействия с камерой, стоит привести [14].
Следует отметить, что отличительной чертой
Android-разработки, с точки зрения обзора литературы, является большое число
интернет-ресурсов. Это обусловлено, во-первых, популярностью платформы, а,
во-вторых, особенностями мобильной разработки. Несмотря на наличие официальной
документации и нескольких основных книг по разработке, на практике существует
большое число нюансов, которые обычно не рассматриваются в официальных
источниках. В качестве примера таких нюансов можно привести решения для обхода
ошибок в Android
SDK или же
специфических для устройств определённых производителей особенностей платформы.
2. Системное проектирование
Типичное Android-приложение имеет модульную структуру, зачастую с весьма слабосвязанными компонентами, общающимися посредствам пересылки сообщений. В данном дипломном проекте можно выделить четыре основных компонента, три из которых ассоциированы с основными активити приложения, а четвёртый отвечает за фоновую обработку данных. Наряду с основными модулями, которые логически выделяются исходя из входных требований к приложению, несложно определить набор дополнительных модулей. К ним можно отнести модуль настроек, присутствующий в большинстве Android-приложений, а также пользовательский интерфейс для взаимодействия с ним. На первый взгляд, выделение двух модулей может показаться излишним, однако исходя из специфики взаимодействия с настройками, оно довольно логично. Приложение также использует БД для кеширования части данных с сервера, поэтому логично будет отдельный модуль для работы с БД. Приложение обладает небольшим количеством фоновых операций, поэтому, по крайней мере на данном этапе, нет необходимости в выделении отдельных сервисов для работы с БД и веб-сервером. Как было сказано выше, Android позволяет использовать отдельные компоненты-загрузчики для асинхронного получения массивов данных. Данные загрузчики имеют автономный жизненный цикл и являются внешними компонентами по отношению к модулю взаимодействия с БД, поэтому их разумно выделить в отдельный модуль. Приложение обладает небольшим количеством фоновых операций, поэтому, по крайней мере, на данном этапе, нет необходимости в выделении отдельных сервисов для работы с БД и веб-сервером. Поэтому, чтобы подчеркнуть функции фонового сервиса, как контекста выполнения операций, веб-клиент также следует вынести в отдельный модуль. Таким образом, окончательная структура дипломного проекта представлена на чертеже ГУИР.400201.086 C1.
Рассмотрим по подробнее каждый из модулей. Модуль авторизации, как и прочие два модуля, ассоциированные с активити, состоит из двух частей, одной из которых является представление, а другой класс-контроллер, унаследованный от класса Activity. Несмотря на это, не следует выделять эти части в два разных модуля, как это можно было бы сделать в случае веб-приложения. Представление, по своей сути, является набором декларативных XML-файлов, описывающих разметку. Несмотря на то, что эти файлы подгружаются динамически классом-контроллером, между ними всё ещё существует неявная, односторонняя, но достаточно существенная связь. В то время как представление ничего не знает о классе-контроллере, да и вообще о структуре классов в целом (исключениями в некотором роде являются пользовательские элементы управления), класс-контроллер должен оперировать строго определёнными элементами представления. Попытка получить элемент, отсутствующий в разметке, неизбежно приведёт к исключению во время исполнения. Кроме этого, следует учитывать, что для получения объектов, ассоциированных с элементами управления используется метод find View ById, принимающий на вход уникальный числовой идентификатор, определённый в разметке, и возвращающий базовый тип View. Таким образом, каждый объект, полученный с помощью данного метода, необходимо приводить к конкретному типу, например, Button или List View, многие из которых обладают уникальными свойствами. Это создаёт ещё одно опасное место, способствующее возникновению ошибок, связанных с приведением типов, и выдаче исключений Class Cast Exception во время исполнения. Помимо этого, существует возможность программно создавать элементы управления и изменять разметку, что способствует более тесной связи представления и класса-контроллера.
Активити авторизации является первым, что видит пользователь приложения. Помимо своих основных функций (предоставления возможности для ввода логина и пароля, а также их валидации) данный модуль также выполняют функцию определения первого запуска приложения. Архитектурой Android-приложения не предусмотрен метод, который вызывается при самом первом старте приложения, или же хотя бы просто при старте приложения. Вследствие этого, зачастую обработка подобных ситуаций производится в начальной активити приложения, то есть, в данном случае, в модуле авторизации. Кроме того, активити авторизации является единственной в приложении, где используются разные разметки для альбомной и портретной ориентации экрана.
Модуль работы с камерой сделан на базе основной, второй по счёту, активити, которую видит пользователь. В данном случае, модуль работы с камерой - это нечто большее, чем простое представление. Android предоставляет определённые возможности для написания пользовательских приложений, работающих напрямую с камерой. Типовое решение предполагает использование определённого элемента управления и реализации нескольких интерфейсов обратного вызова для получения событий от камеры и элементов представления. Помимо этого, важным нюансов является то, что поворот экрана приводит к пересозданию компонента представления, отвечающего за вывод видео потока с камеры. С визуальной точки зрения, такое поведение выглядит не лучшим образом, поэтому определённую сложность представляет собой собственная обработка определения положения экрана и обработка его поворота. Таким образом, получается достаточно тесно связанный, узкоспециализированный модуль, представляющий собой синтез визуальных компонент и класса-слушателя для реакции на события от камеры и датчиков позиционирования телефона.
Ключевым модулем приложения является модуль редактирования метаданных. Его особая роль состоит в том, что он контактирует с многими компонентами системы и является агрегатором данных. В работе модуля можно выделить три основные стадии, в ходе которых он взаимодействует с различными частями приложения. На этапе инициализации модуль получает исходные данные в виде снимка от модуля работы с камерой, а также устанавливает связь с модулями загрузки данных для асинхронного получения кэшированной информации. В следующей фазе своей работы, модуль обеспечивает взаимодействие с пользователем: предоставляет возможности для заполнения формы метаданных, а также обеспечивает сохранение введённых данных до момента отправки. В завершительной фазе модуль становится слушателем событий от фонового сервиса для того, чтобы показывать пользователю прогресс выполнения задачи и предоставить возможность обратной связи в случае возникновения ошибок.
Модуль настроек представляет собой по большей части системную компоненту, которая предоставляет доступ к защищённому фалу настроек приложения, доступному в контексте всего приложения. Типичной практикой является использование модуля настроек для сохранения состоянии приложения между запусками. Помимо этого, модуль настроек связывается с пользовательским интерфейсом, который функционирует как фасад и открывает пользователю часть настроек для редактирования. В зависимости от сложности приложения, модуль, отвечающий за взаимодействия с пользователем может иметь вид не только тонкого клиента, но и достаточно сложно системы, включающей в себя набор собственных элементов представления для редактирования настроек, а также набора компонент, ответственных за быстрое реагирования на смену настроек. В данном проекте модуль пользовательского интерфейса не является сложным и, более того, предоставляет возможности для редактирования довольно общих свойств, важных в контексте всего приложения, а не конкретной сессии. По этой причине приложение предоставляет лишь одну точку входа в интерфейс настроек. Несмотря на это, нижележащий модуль настроек достаточно широко используется всеми основными компонентами системы. Данный факт является основным доводом в пользу выделения двух модулей, имеющих отношение к настройкам.
Достаточно обособленным выглядит модуль работы с БД. Во многом это следствие шаблонов проектирования ОС Android. Платформа предоставляет возможности для автономной инициализации БД при первом запуске приложения, а также позволяет вести версионность БД. При этом, в общем случае, имеется возможность реализации поставщика содержимого (Content Provider), предоставляющий внешний интерфейс для взаимодействия с БД. Поставщик содержимого можно трактовать как аналог сервиса, представляющего публичный API для любых внешних приложений. Конечно, существует возможность ограничения доступа к поставщику. Можно дать права на подключения лишь некоторым приложениям или требовать запроса разрешений от внешних приложений, которые планируют контактировать с поставщиком, или же ограничить видимость поставщика собственных приложением. В последнем случае, фактически, необходимость в поставщике содержимого отпадает, и программист волен сам решать, как реализовывать интерфейс для взаимодействия с БД. В данном проекте БД используется для кеширования данных сервера и нет необходимости делать доступными эти данные для внешних компонент. Модуль работы с БД предоставляет набор открытых методов для асинхронного обновления содержимого БД, а также предоставляет возможность для подписки класса-обозревателя на события от БД. В данном случае, такими событиями являются факты получения новых данных. В качестве обозревателей используются прокси-объекты, являющиеся частью модулей загрузки данных. Процесс подключения к БД для чтения данных выглядит следующим образом:
. Модуль-инициатор чтения (в данном случае, модуль редактирования метаданных) запрашивает у менеджера загрузчиков создание нового объекта-загрузчика, указывая события, к которым будет подключен класс обозреватель, а также класс-слушатель, вызываемый по готовности данных.
. Создаётся новый автономный загрузчик, который, через прокси-объект, подписывается на события обновления определённых данных в БД. Если менеджер загрузчиков видит, что необходимый загрузчик уже был создан, он отдаёт существующий вместо создания нового.
. По готовности загрузчика, а также при последующих событиях от БД вызывается метод обратного вызова в классе-инициаторе чтения, в который передаются полученные данные.
Стоит отметить, что менеджер загрузчиков - это системный объект класса Loader Manager, который служит для взаимодействия с конкретными загрузчиками (наследниками класса Loader), а также обеспечивает поддержку их автономного жизненного цикла. В то же время, конкретные загрузчики являются пользовательскими классами, реализующими необходимые методы для обработки данных, а также предоставляющие возможность подписки на произвольные события извне.
Ещё одним не видным пользователю модулем является веб-клиент. В данном случае, это класс реализующий взаимодействие с веб API на клиентской стороне. Основными его функциями являются установка соединения с сервером, вызов удалённых веб-методов, а также преобразование структур данных от используемых приложением абстракций к установленному формату веб API. Основной причиной вынесения веб-клиента в отдельный модуль является универсальность модуля обработки фоновых операций. Принимая во внимание необходимую функциональность разрабатываемого приложения, не имеет смысла выделение нескольких сервисов для различных типов (работа с сетью, работа с БД) фоновых операций. Подобное разделение вызвало бы лишь излишнюю сложность при синхронизации работы компонент и пересылке данных. Таким образом, выделение отдельных компонент - веб-клиента и модуля работы с БД - подчёркивает их специализацию, а также указывает на роль модуля фоновой обработки данных, как контекста выполнения фоновых операций.
Модуль фоновой обработки операций построен на базе Android-сервиса и предназначен, как следует из названия, для осуществления затратных по времени операций вне основного потока выполнения. Помимо основного своего назначения, модуль определяет слабосвязанный интерфейс для обмена с остальными крупными модулями приложения через интенты. Типичный ход работы приложения не определяет параллельных операций, поэтому сервис используется как очередь для обработки ресурсоёмких операций в отдельном потоке. Для этого используется входящий в состав Android SDK класс Handler. С помощью наследования от этого класса, можно получить готовую очередь событий с пользовательским обработчиком сообщений - объектов класса Message, способных передавать в обработчик все необходимые данные. Экземпляр подкласса Handler может быть ассоциирован с любым потоком, что позволяет организовывать межпотоковую коммуникацию для обеспечения обратной связи с основным потоком исполнения. Несмотря на это, в данном проекте используется иной способ коммуникации, основанный на интентах. Подобный подход позволяет более просто организовать доступ к сервису из нескольких модулей приложения. К счастью, ОС Android предоставляет частичную реализацию подобного шаблона обработки сообщений - класс Intent Service. Объект данного класса представляет собой Android-сервис, который при старте запускает отдельный фоновый поток исполнения и ассоциирует с ним объект Handler, оставляя пользователя право самому определить, как будут обрабатываться полученные интенты. Если один или несколько интентов приходят во время обработки предыдущих, то они автоматически добавляются в конец текущей очереди обработки операций. IntentService самостоятельно помещает интенты в объекты-сообщения для постановки в очередь обслуживания и извлекает их напрямую передавая в метод-обработчик. Особенностью данной реализации является то, что Inten Service поддерживает лишь одну очередь обработки сообщений, а также автоматически завершается после выполнения всех операций из очереди для экономии ресурсов телефона. Данные особенности вынуждают отказываться от использования Intent Service в случаях, когда требуется параллельная обработка операций или же обеспечение долгоживущего сервиса, однако для целей текущего проекта Intent Service подходит идеально.