Мобильное приложение для оценки эффективности мерчендайзинга торговой компании

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Содержание

Введение

1. Обзор литературы

2. Системное проектирование

3. Функциональное проектирование

3.1 Описание взаимодействия с сервером

3.2 Описание классов системных компонентов

3.3 Описание классов взаимодействия с данными

3.4 Описание классов пакета dialogs

3.5 Обзор функциональных классов из пакета helpers

3.6 Описание классов пакета networking

4. Разработка программных модулей

5. Программа и методика испытаний

6. Руководство пользователя

7. Технико-экономическое обоснование проекта

7.1 Описание проекта

7.2 Расчет сметы затрат и цены ПО

8. Обеспечение пожарной безопасности на ЗАО «Итранзишэн»

Заключение

Список литературы

Приложения

Введение

Данный дипломный проект является частью системы, которая используется маркетинговым отделом компании для мониторинга и анализа работы сотрудников (мерчендайзеров), а также для слежения за динамикой продаж в соответствии с проделанной работой.

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

Разработка системы преследует две цели: с одной стороны, облегчить рядовым сотрудникам удобство и простоту ведения отчётности о проделанной работе, а с другой - предоставить руководителям возможность контроля за работой подчинённых.

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

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

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

1. Обзор литературы

В основе программирования для операционной системы (ОС) Android лежит программирования на Java. Несмотря на свою закостенелость и ощутимое неудобство в работе, Java является одним из самым популярных языков программирования. Язык имеет большую историю - первый релиз Java состоялся ещё в 1995 году - поэтому не удивительно, что существует огромное количество учебников и специализированных сайтов, посвящённых Java-разработке. В качестве ярких примеров можно привести наиболее распространённые [1] и [2].

Java - объектно-ориентированный язык программирования, разработанный компанией Sun Microsystems (в последующем приобретённой компанией Oracle). Приложения Java обычно транслируется в специальный байт-код, поэтому они могут работать на любой виртуальной Java-машине вне зависимости от компьютерной архитектуры. Bиртуальная машина Java (Java Virtual Machine, далее JVM)) - основная часть исполняющей системы Java, так называемой Java Runtime Environment (JRE). Виртуальная машина Java интерпретирует байт-код, предварительно созданный из исходного текста программы компилятором.

В своё время Java удалось сдать стандартом де-факто для бизнес решений. В многом на это повлияли удобство программирования (на тот момент это ещё было актуально) и простота освоения языка: синтаксис языка Java представляет собой более простой вариант синтаксиса языка С++. Зная С++, несложно перейти к языку Java. В настоящий момент Java ощутимо проигрывает в удобстве использования большинству современных языков программирования, однако не спешит сдавать позиции в рейтинге популярности. В основном это обусловлено политикой компании Oracle, из-за которой темпы развития Java существенно отстают от других распространённых языков программирования. Java-сообщество по-прежнему обширно, а экосистема языка содержит гигантскую кодовую базу с тысячами сторонних библиотек, существенно расширяющих функциональность. Несмотря на первый взгляд, оптимистичную картину, без многих популярных библиотек функциональность и удобство использования Java «из коробки» оставляет желать лучшего.

Одним из главных свойств Java, обеспечившим ему огромную популярность, является переносимость. Философия Java провозглашает принцип «Write once - run everywhere», указывающий на то, что, в теории, Java-код может быть исполнен на любой JVM, работающей на любом устройстве. В реальной жизни, конечно, данный принцип работает с большими оговорками, однако это не мешает успешной работоспособности JVM более чем на трёх миллиардах устройств. Скорее всего, благодаря заманчивой перспективе переносимости, именно Java был выбран в качестве языка программирования для операционной системы (ОС) Android. Философия платформы включает в себя варианты использования ОС на любом устройстве с любой микропроцессорной архитектурой, будь то ARM, x86 или любая другая.

ОС Android является хорошим примером лукавости принципа «Write once - run everywhere»: ввиду ограниченности ресурсов использование стандартной JVM было затруднено, и единственным возможным выбором было использование Java ME JVM, разработанной для мобильных устройств. Однако, компания Google решила разработать собственную виртуальную машину Dalvik VM, которая отличается от других JVM следующим [3]:

1. Используется специальный формат DEX для хранения двоичных кодов с целью уменьшения их размера.

2. Dalvik VM оптимизирована для выполнения нескольких процессов одновременно.

3. Используется архитектуру, основанную на регистрах против стековой архитектуры в других JVM.

4. Используется собственный набор инструкций, а не стандартный байткод JVM.

5. Возможен запуск нескольких независимых Android-приложений в одном процессе.

6. Реализован специальный механизм сериализации объектов, основанный на классах Parcel и Parcelable.

7. Имеется особый способ для выполнения вызовов между процессами, основанный на Android Interface Definition Language (AIDL).

Кроме новой JVM, также были пересмотрены стандартные пакеты Java JDK API. Некоторые из ни были удалены, например, всё, что касалось Swing (библиотеки для создания графического интерфейса пользователя), но в том числе добавилось некоторое количество собственных android. пакетов. Таким образом, далеко не всякая программа или библиотека, написанная на Java, сможет без проблем быть скомпилированной и запуститься на Android-устройстве.

В связи с большой популярностью мобильных разработок, существует большое количество источников информации по Android-разработке. Основным источником, в первую очередь, является официальная документация [4]. Помимо технической документации комплекта средств разработки (Software Development Kit, SDK), официальный сайт содержит множество примеров, руководства по реализации стандартных компонентов, пошаговые рекомендации по разработке приложений с нуля, а также требования к дизайну.

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

Как бы то ни было, из любого из выше приведенных источников можно почерпнуть сведения об архитектуре и процессе разработки приложений. Любое Android-приложение, содержит в себе хотя бы один из так называемых App Components - компонентов приложения. Существуют четыре вида основных компонентов приложения: Activity, Service, Content Provider и Broadcast Receiver. К сожалению, не существует какого-либо официального перевода этих терминов на русский язык. В переведённой литературе обычно используется калька с английского, например, Activity - «Активность». Поскольку термин «Активность» не совсем соответствует тому, для чего служит класс Activity (о его назначении будет написано ниже), в большинстве интернет-источников используется русская транскрипция терминов, например, Activity - «Активити».

Активити представляет собой одну «страницу» с пользовательским интерфейсом (если проводить аналоги с веб-интерфейсами). Все пользовательские активити являются классами, унаследованными от стандартного класса Activity. Здесь можно провести некоторую параллель с технологией Windows Forms, однако, поскольку Java не поддерживает частичные (partial) классы, в Android-приложениях используется иной способ связывания элементов интерфейса и пользовательского класса-активити. Каждая активити обладает определённым жизненным циклом (рисунок 1.1), который является хорошей демонстрацией специфики мобильных приложений. Поскольку ресурсы мобильных устройств весьма ограничены, достоверно можно сказать лишь то, что в памяти существуют лишь те объекты, которые так или иначе относятся к отображаемому на экране содержимому. Как только активити скрывается с экрана, например, если пользователь сворачивает приложение кнопкой «Домой», активити переходит в состояние «остановлено» (stopped). Начиная с этого момента, ОС может уничтожить все объекты в оперативной памяти, относящиеся к данной активити, включая саму активити. Исходя из этого очень важно вовремя сохранять состояние приложения. Второй особенностью активити является то, что каждый раз при смене ориентации устройства с ландшафтной на портретную или наоборот, активити уничтожается и создаётся заново. Сложно сказать, чем продиктовано подобное решение, скорее всего это сделано для того, чтобы обеспечить поддержку различных вариантов пользовательского интерфейса для различной ориентации устройства. Данная особенность порождает вторую важную проблему - проблему сохранения состояния при изменении конфигурации (например, при повороте экрана). Подробнее о работе с активити можно прочитать в специализированном разделе документации [4].

Сервис - это компонент, который работает в фоне и используется для длительных и ресурсоёмких операций. Отличительной особенностью сервиса является возможность запуска в привилегированном режиме (foreground mode), благодаря которому ОС не завершает приложение в фоне максимально долгое время. Несмотря на такую возможность, разработчикам крайне не рекомендуется злоупотреблять ею и наоборот, завершать сервисы как можно раньше. Привилегированный режим обычно используется для записи или воспроизведения потокового содержимого, а также для скачивания или загрузки файлов. Помимо упоминавшихся ранее источников, хорошим руководством по работе с сервисами является [6].

Ещё одним часто используемым компонентом является Broadcast Receiver (в русскоязычной литературе встречается перевод «широковещательный приемник»). Broadcast receiver - это компонент, служащий для обработки широковещательных сообщений. ОС Android использует специальные объекты для сообщения между компонентами - интенты (intent). Иногда в литературе встречается прямой перевод - «намерения». Интент - это объект класса Intent представляющий собой некоторое сообщение. С каждым интентом может ассоциироваться некий код ошибки, действие, URI (Uniform Resource Identifier), а также произвольный набор пересылаемых объектов. Объекты, так называемые extras, хранятся в ассоциативном контейнере с уникальными строковыми ключами. Поддерживаются все примитивные типы, строки, а также объекты, реализующие интерфейсы Serializable или Parcelable. Интенты могут быть узконаправленными, например, для запуска сервиса или активити, или же широковещательными, обычно используемые в качестве нотификации о каком-либо событии. Интенты широко используются в ОС Android: благодаря широковещательным интентам, с помощью широковещательных приемников можно подписываться на различные системные события, от срабатывания будильника и до перехода по ссылке в браузере.

Рисунок 1.1 - Жизненный цикл Activity

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

Широковещательные приёмники и поставщики контента хорошо описаны во многих источниках, например, на популярном русскоязычном ресурсе, посвящённом изучению программирования для ОС Android - [7].

Связующим элементом, объединяющим разрозненные компоненты в единое Android-приложение, является манифест. Манифест - это специальный обязательный XML-файл, содержащий перечень всех компонентов приложения, минимальную и используемую для сборки версии ОС, а также требуемые для работы разрешение и необходимые возможности устройства (например, наличие фронтальной камеры или определённой версии OpenGL ES).

Помимо изучения работы с основными компонентами, каждый разработчик должен ознакомится с основными шаблонами проектирования ОС Android. Наиболее часто используемыми стандартными шаблонами проектирования являются наблюдатель (observer) и слушатель (listener). Также широко используются такие принципы как обмен сообщений и позднее связывание. Помимо этого, Android диктует свои правила при реализации некоторых стандартных процессов, тем самым заставляя разработчикам следовать определённым специфическим шаблонам проектирования. Ярким примеров этого могут служить загрузчики (loaders). Загрузчики являются потомками класса Loader и служат для асинхронной загрузки данных. Главным преимуществом загрузчиков является то, что их жизненный цикл не зависит от других компонентов. Для доступа к загрузчикам используется специальный компонент Loader Manager, который позволяется работать с загрузчиками любым классам, реализующим интерфейс Loader Manager Loader Callbacks. Несмотря на некоторые встроенные во фреймворк реализации, разработчикам довольно часто приходится реализовывать свои специфические загрузчики, например, для работы с локальной базой данных или получения массивов информации по сети. Хорошую статью о практической реализации загрузчиков можно найти по адресу [8]. Там же можно отыскать и другие полезные статьи по специфическим шаблонам проектирования.

Несмотря на довольно динамичное развитие SDK и внедрение новых шаблонов проектирования, в последнее время издавалось не много литературы с упором на актуальные версии средств разработки. В качестве одного из примером, можно привести [9]. Книга во много схожа с [2], однако базируется на современной версии платформы и отдельно затрагивает тему обеспечения совместимости с использованием стандартных компонентов.

Поскольку Android-разработка является фрэймворк-ориентированной, то есть, достаточно сильно завязанной на стандартные классы и генерацию кода, перед всеми разработчиками встаёт вопрос: какую же среду разработки следует использовать для максимально удобного программирования под Android? Однозначного ответа на него нет, скорее это вопрос личных предпочтений. Существует четыре основных интегрированных среды разработки (Integrated development environment, далее IDE) с поддержкой Android-проектов:

- Eclipse + ADT Plugin;

- InelliJ IDEA;

- NetBeans;

- Android Studio.

Долгое время чаще всего использовались первые две IDE. Eclipse является скорее платформой для создания универсальных сред разработки, основанных на интегрировании специальных модулей расширения - плагинов. Соответствующий плагин для Android-разработки носит имя ADT Plugin и обладает весьма обширным функционалом. Первоначально именно его широкая функциональность принесла популярность связке Eclipse + ADT Plugin, поскольку она позволяла, например, редактировать пользовательский интерфейс в WYSIWYG стиле. Несмотря на это, в последнее время Eclipse сильно уступила InelliJ IDEA в связи с бурным и динамичным развитием последней. InelliJ IDEA также поддерживает расширения в виде плагинов и позволяет создавать Android-проекты, однако объективно обладает намного более впечатляющими возможностями для написания, редактирования и рефакторинга исходного кода по сравнению с Eclipse.

Наименее распространённой 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 для любых внешних приложений. Конечно, существует возможность ограничения доступа к поставщику. Можно дать права на подключения лишь некоторым приложениям или требовать запроса разрешений от внешних приложений, которые планируют контактировать с поставщиком, или же ограничить видимость поставщика собственных приложением. В последнем случае, фактически, необходимость в поставщике содержимого отпадает, и программист волен сам решать, как реализовывать интерфейс для взаимодействия с БД. В данном проекте БД используется для кеширования данных сервера и нет необходимости делать доступными эти данные для внешних компонент. Модуль работы с БД предоставляет набор открытых методов для асинхронного обновления содержимого БД, а также предоставляет возможность для подписки класса-обозревателя на события от БД. В данном случае, такими событиями являются факты получения новых данных. В качестве обозревателей используются прокси-объекты, являющиеся частью модулей загрузки данных. Процесс подключения к БД для чтения данных выглядит следующим образом:

1. Модуль-инициатор чтения (в данном случае, модуль редактирования метаданных) запрашивает у менеджера загрузчиков создание нового объекта-загрузчика, указывая события, к которым будет подключен класс обозреватель, а также класс-слушатель, вызываемый по готовности данных.

2. Создаётся новый автономный загрузчик, который, через прокси-объект, подписывается на события обновления определённых данных в БД. Если менеджер загрузчиков видит, что необходимый загрузчик уже был создан, он отдаёт существующий вместо создания нового.

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

Стоит отметить, что менеджер загрузчиков - это системный объект класса Loader Manager, который служит для взаимодействия с конкретными загрузчиками (наследниками класса Loader), а также обеспечивает поддержку их автономного жизненного цикла. В то же время, конкретные загрузчики являются пользовательскими классами, реализующими необходимые методы для обработки данных, а также предоставляющие возможность подписки на произвольные события извне.

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

Модуль фоновой обработки операций построен на базе Android-сервиса и предназначен, как следует из названия, для осуществления затратных по времени операций вне основного потока выполнения. Помимо основного своего назначения, модуль определяет слабосвязанный интерфейс для обмена с остальными крупными модулями приложения через интенты. Типичный ход работы приложения не определяет параллельных операций, поэтому сервис используется как очередь для обработки ресурсоёмких операций в отдельном потоке. Для этого используется входящий в состав Android SDK класс Handler. С помощью наследования от этого класса, можно получить готовую очередь событий с пользовательским обработчиком сообщений - объектов класса Message, способных передавать в обработчик все необходимые данные. Экземпляр подкласса Handler может быть ассоциирован с любым потоком, что позволяет организовывать межпотоковую коммуникацию для обеспечения обратной связи с основным потоком исполнения. Несмотря на это, в данном проекте используется иной способ коммуникации, основанный на интентах. Подобный подход позволяет более просто организовать доступ к сервису из нескольких модулей приложения. К счастью, ОС Android предоставляет частичную реализацию подобного шаблона обработки сообщений - класс Intent Service. Объект данного класса представляет собой Android-сервис, который при старте запускает отдельный фоновый поток исполнения и ассоциирует с ним объект Handler, оставляя пользователя право самому определить, как будут обрабатываться полученные интенты. Если один или несколько интентов приходят во время обработки предыдущих, то они автоматически добавляются в конец текущей очереди обработки операций. IntentService самостоятельно помещает интенты в объекты-сообщения для постановки в очередь обслуживания и извлекает их напрямую передавая в метод-обработчик. Особенностью данной реализации является то, что Inten Service поддерживает лишь одну очередь обработки сообщений, а также автоматически завершается после выполнения всех операций из очереди для экономии ресурсов телефона. Данные особенности вынуждают отказываться от использования Intent Service в случаях, когда требуется параллельная обработка операций или же обеспечение долгоживущего сервиса, однако для целей текущего проекта Intent Service подходит идеально.

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

Первая цепочка представлена следующим набором последовательных операций:

1. Пользовательский ввод.

2. Реакция на ввод в активити.

3. Отправка команды сервису фоновой обработки.

4. Вызов удалённого веб API.

5. Получение данных в формате JSON.

6. Преобразование данных к виду, используемому на клиенте.

7. Передача данных для обновления в БД.

С другой стороны, вторая цепочка описывается следующим образом:

1. Старт активити.

2. Создание загрузчика и подписка его на обновления БД.

3. Ожидание обновления и передача данных в активити по готовности.

4. Переход к пункту 3 для отслеживания актуальности данных.

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

3. Функциональное проектирование

В данном разделе подробно рассматривается функционирование программных модулей. Перечислены все присутствующие классы и большинство их компонентов. Состав и отношения классов также показаны на диаграмме классов (чертёж ГУИР.400201.128 РР.2).

3.1 Описание взаимодействия с сервером

Одной из главных функций мобильного клиента является обмен данными с сервером. Для этих целей был разработан интерфейс, описывающий набор веб-методов для коммуникации между компонентами. Иными словами, интерфейс программирования приложений (application programming interface, далее API). API базируется на трёх основных принципах:

1. Формат передаваемых данных - JSON.

2. Информация о пользователе передается с каждым запросом при помощи базовой аутентификации HTTP (Basic Authentication).

3. Для отправки данных используются HTTP POST запросы.

На данный момент сервер предоставляет пять веб-методов доступных клиенту, описание которых представлено ниже. Методы перечислены в порядке их вызова приложением. Как только пользователь нажимает кнопку «Войти» на экране авторизации, вызывается метод login для проверки прав доступа. Если доступ получен, приложение по очереди вызывает методы stores и categories для обновления локального кэша, в то время как пользователь может делать снимок. После того как пользователь сделает фото, он попадает на страницу метаданных, заполнив которые, отправляет фото на сервер, другими словами производится вызов методов upload_photo и save_photo.

1. Авторизация пользователя (../api/login)

Входные данные:

{

}

Ответ сервера:

{

"role": "user"

}

Описание:

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

2. Получение списка магазинов (../api/stores)

Входные данные:

{

"version": 10

}

Ответ сервера:

[

{

"id": 102,

"version": 11,

"active": true,

"name": "Coolman",

"street": "Кульман",

"city": "Минск"

},

...

]

Описание:

Метод возвращает список магазинов, обновившихся после запрошенной версии (поле «version» из входных данных). При каждом изменении данных о магазине на сервере должен увеличиваться номер версии. Номер версии является глобальным для клиента и сервера счетчиком. Клиент при запросе отправляет максимальную версию из имеющихся у него. Важной особенностью системы является то, что данные о магазинах никогда не удаляются, однако им можно присваивать неактивный статус (поле «active» из ответа сервера). Неактивные магазины не отображаются при выборе точки продажи на клиенте.

3. Получение списка категорий (..api/categories)

Входные данные:

{

"version": 10

}

Ответ сервера:

[

{

"id": 3,

"version": 6,

"active": true,

"name": "Computers"

},

...

]

Описание:

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

4. Загрузка фотографии (../api/upload_photo)

Входные данные:

Фото в бинарном виде.

Ответ сервера:

{

"file": "3F2504E0-4F89-11D3-9A0C-0305E82C3301"

}

Описание:

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

5. Сохранение фотографии (../api/save_photo)

Входные данные:

{

"store": 102,

"category": 12,

"comment": "User defined comment",

"problem": false,

"was_taken": "unknown"

"file": "3F2504E0-4F89-11D3-9A0C-0305E82C3301",

"coordinates": {

"latitude": 54.3,

"longitude": 23.4,

"accuracy": 10

}

}

Ответ сервера:

{

"success": true

}

Описание:

Метод используется для сохранения загруженной ранее фотографии с идентификатором, переданным в качестве параметра «file» запроса. В данном случае в теле POST-запроса передаются метаданные снимка, которые включают в себя следующие элементы:

- идентификатор магазина («store»);

- идентификатор категории («category»);

- произвольный комментарий («comment»);

- специальное поле «was_taken», позволяющее определить снимок как сделанный до, либо после работы; возможные значения: «unknown» (по умолчанию), «before» или «after»;

- идентификатор файла («file»);

- координаты точки, в которой была сделана фотография (структура «coordinates»), включающие в себя широту («latitude»), долготу («longitude») и точность определения («accuracy»).

В случае неправильного логина или пароля, любой из выше перечисленных методов возвращает ошибку в виде HTTP ответа с кодом 401 - «Unauthorized». Ответ сервера сделан непустым на случай, если понадобится добавление расширенных сообщений об ошибках.

3.2 Описание классов системных компонентов

Классы системных компонентов, применительно к данному проекту, представляют собой класс Worker Service, наследованный от класса Intent Service, а также четыре класса, унаследованные от класса Acivity: Login Activity, Settings Acivity, Camera Activity и Data Activity. Особенностью данных классов является то, что они описывают тот или иной крупный компонент приложения, важный, в первую очередь, для ОС.

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

- void onCreate(Bundle savedInstanceState) - метод, вызываемый при создании активити. В нём осуществляется создание и размещение (inflatting) визуальных компонентов (обычно из специального файла с разметкой), а также начальная инициализация компонентов. Данный метод можно рассматривать как аналог конструктора, с той лишь разницей, что на момент вызова активити будет уже не только создана, но и отображаться на экране телефона. Объект типа Bundle является контейнером, содержащим пары ключ-значение и служит для восстановления параметров при пересоздании активити после поворота экрана или иной смены конфигурации.

- boolean on Create Options Menu (Menu menu) - метод, вызываемый при создании контекстного меню активити, пункты которого добавлялись к объекту menu. На данный момент шаблон проектирования с использованием контекстного меню устарел и в этом методе производится инициализация так называемой «строки действий» (Action Bar), являющей актуальным на данный момент дизайнерским шаблоном для предоставления контекстно зависимых опций. В отличие от контекстного меню, строка действий, обычно, инициализируется не в коде, а в файле разметки. Возвращаемое методом значение служит индикатором для создания меню: если метод вернёт false, то контекстное меню создано не будет, даже если оно будет инициализировано значениями. Такое поведение справедливо также и для строки действий.

- boolean on Options Item Selected (MenuItem item) - метод вызываемый при выборе пункта меню или действия со строки действий (в действительности, это одно и то же: разница лишь в терминологии и способе отображения). Объект типа Menu Item ассоциирован с визуальным элементом, обрабатывающим нажатие, а возвращаемое значение является индикатором окончания обработки нажатия: если метод возвращает false, для определённого пункта меню, значит нажатие на него будет обработано в другом месте.

- void on Resume() - метод, вызываемый непосредственно перед отображением активити на экране. В данном методе обычно производится возобновление всех временно прерванных процессов.

- void on Pause() - метод, вызываемый при переходе активити в неактивный режим. Иными словами, каждый раз, когда активити пропадает с экрана. В данном методе обычно приостанавливаются все связанные с пользовательским интерфейсом процессы, а также производится сохранение состояния важных переменных.

- void on Activity Result (int request Code, int result Code, Intent data) - данный метод представляет собой обработчик результатов, полученных от действий инициируемых с помощью интентов, например, таких, как вызов активити, содержащей детальное представление или получение информации от датчиков телефона. В данном случае request Code - уникальный идентификатор интента, result Code - код результата, обычно показывающий успех или ошибку, data - непосредственно сам интент с результатами выполнения запроса.

- void on Click (View view) - данный метод не является частью класса Activity, однако очень часто используется в его наследниках. Данный метод является единственным компонентом интерфейса View. On Click Listener, который должны реализовать объекты-слушатели событий-кликов по визуальным элементам управления. Существует два основных подхода к обработке кликов, каждый из которых имеет свои преимущества и недостатки: либо для каждого элемента управления создаётся свой класс-слушатель (обычно анонимный), либо активити реализует интерфейс View. On Click Listener и становится слушателем для всех свои элементов управления. В данном проекте используется второй способ.

Помимо этих методов, можно отметить наличие в классах-активити целочисленных констант вида «ACTION_CODE_XXX» и строковых констант вида «YYY_DIALOG_TAG».

Константы первого типа представляют собой уникальные ключи, используемые при создании интентов. Они необходимы для идентификации результатов, полученных в качестве ответа на определённые интенты. Идентификатор, заданный при создании интента будет в последствии передан в метод on Activity Result в качестве параметра requestCode. Значения целочисленных констант формируются из трёх цифр наподобие кодов HTTP ответов. Первая цифра показывает компонент (класс), которому принадлежит константа, вторая - область применения константы (идентификатор интента, идентификатор загрузчика и т.д.), третья - порядковый номер константы в рамках заданного компонента и области применения.

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

Класс Login Activity

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

Константы:

- ACTION_CODE_LOGIN - идентификатор интента, ассоциированного с действием авторизации.

- PROGRESS_DIALOG_TAG - тег диалогового фрагмента, используемого для отображения прогресса выполнения задачи.

- REPORT_DIALOG_TAG - тег диалогового фрагмента, используемого для отображения информации об ошибках.

- REDIRECT_DIALOG_TAG - тег диалогового фрагмента, используемого для переадресации на страницу на строек при первом запуске приложения.

- SAVE_CREDENTIALS_PROPERTY - константа-ключ для доступа к опции запоминания логина и пароля.

Поля:

- Save Credetials - поле типа boolean, содержащее актуальное значение опции запоминания логина и пароля.

- Login Edit Text - поле типа Edit Text, содержащее ссылку на текстовое поле для ввода имени пользователя (логина).

- Password Edit Text - поле типа Edit Text, содержащее ссылку на текстовое поле для ввода пароля.

- Save Credentials Check Box - поле типа Check Box, содержащее ссылку на флажок опции запоминания логина и пароля.

- Signin Button - поле типа Button, содержащее ссылку на кнопку «Войти».

- Progress Dialog - поле типа Progress Dialog Fragment, содержащее ссылку на диалоговый фрагмент, используемый для отображения прогресса выполнения задачи.

- Preferences - поле типа Shared Preferences, содержащее ссылку на модуль настроек.

Методы:

- void try Begin Authorize User() - метод, осуществляющий валидацию пользовательского ввода перед операцией авторизации, а также отображающий результаты валидации.

- void begin Authorize User (String login, String password) - метод, запускающий процесс асинхронной авторизации. В качестве входных параметров выступают введённые пользователем логин и пароль.

- void end Authorize User(String role) - метод, вызываемый при окончании авторизации. Входным параметром является роль пользователя.

- void navigate To Camera Activity () - метод, осуществляющий переход к активити управления камерой.

- void before Text Changed (Char Sequence char Sequence, int i, int i2, int i3) - метод интерфейса Text Watcher. Не используется.

- void on Text Chan ged (Char Sequence char Sequence, int i, int i2, int i3) - метод интерфейса Text Watcher. Не используется.

- void after Text Changed (Editable editable) - метод интерфейса Text Watcher. Вызывается послед ввода каждого символа. Разблокирует кнопку signin Button при наличии логина и пароля.