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

Главная

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

Системное и функциональное проектирование. Описание взаимодействия с сервером, классов системных компонентов. Обзор функциональных классов из пакетов helpers, dialogs и networking. Разработка программных модулей. Технико-экономическое обоснование проекта.


посмотреть текст работы


скачать работу можно здесь


полная информация о работе


весь список подобных работ


Нужна помощь с учёбой? Наши эксперты готовы помочь!
Нажимая на кнопку, вы соглашаетесь с
политикой обработки персональных данных

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
3.1 Описание взаимодействия с сервером
3.2 Описание классов системных компонентов
3.3 Описание классов взаимодействия с данными
3.4 Описание классов пакета dialogs
3.5 Обзор функциональных классов из пакета helpers
3.6 Описание классов пакета networking
7. Технико-экономическое обоснование проекта
8. Обеспечение пожарной безопасности на ЗАО «Итранзишэн»
Данный дипломный проект является частью системы, которая используется маркетинговым отделом компании для мониторинга и анализа работы сотрудников (мерчендайзеров), а также для слежения за динамикой продаж в соответствии с проделанной работой.
Система является вспомогательным инструментом для анализа и предполагает исключительно внутреннее использование. В первую очередь система ориентирована на визуальный сбор и анализ информации, то есть работу с фотографиями.
Разработка системы преследует две цели: с одной стороны, облегчить рядовым сотрудникам удобство и простоту ведения отчётности о проделанной работе, а с другой - предоставить руководителям возможность контроля за работой подчинённых.
По своей структуре система представляет собой клиент-серверную архитектуру, где в качестве клиентов выступает мобильное приложение, используемое мерчендайзерами в точках продаж, а также веб-интерфейс, предоставляющий основные возможности для просмотра данных. Специально для управляющего звена существует возможность использования веб-интерфейса администрирования для управления пользователями и редактирования данных.
Согласно логике работы системы, мерчендайзеры должны периодически отправлять на сервер снимки закреплённых за ними точек продаж в качестве краткого визуального отчёта о своей деятельности. В то же время, аналитики компании, имея доступ к общей базе снимков, сделанных мерчендайзерами, могут через веб-интерфейс осуществлять выборку снимков по определённой торговой точке за определённый промежуток времени для сопоставления динамики продаж с расположением товара на прилавках. Это может использоваться для экспериментального нахождения наиболее выгодного расположения товара, либо же для наблюдения за схожими действиями конкурирующих фирм. Помимо этого, менеджеры компании могут осуществлять выборку снимков по конкретному сотруднику для наблюдения за эффективностью его работы.
Проект предусматривает использование в закрытой инфраструктуре, поэтому сложно сказать, существуют ли схожие решения. Хоть это и не афишируется, вероятно, подобные системы используются другими компаниями, однако, скорее всего, имеют свои особенности, связанные с производственной отраслью и предметом наблюдений.
В основе программирования для операционной системы (ОС) 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-проектов:
Долгое время чаще всего использовались первые две 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 или же специфических для устройств определённых производителей особенностей платформы.
Типичное Android-приложение имеет модульную структуру, зачастую с весьма слабосвязанными компонентами, общающимися посредствам пересылки сообщений. В данном дипломном проекте можно выделить четыре основных компонента, три из которых ассоциированы с основными активити приложения, а четвёртый отвечает за фоновую обработку данных. Наряду с основными модулями, которые логически выделяются исходя из входных требований к приложению, несложно определить набор дополнительных модулей. К ним можно отнести модуль настроек, присутствующий в большинстве Android-приложений, а также пользовательский интерфейс для взаимодействия с ним. На первый взгляд, выделение двух модулей может показаться излишним, однако исходя из специфики взаимодействия с настройками, оно довольно логично. Приложение также использует БД для кеширования части данных с сервера, поэтому логично будет отдельный модуль для работы с БД. Приложение обладает небольшим количеством фоновых операций, поэтому, по крайней мере на данном этапе, нет необходимости в выделении отдельных сервисов для работы с БД и веб-сервером. Как было сказано выше, Android позволяет использовать отдельные компоненты-загрузчики для асинхронного получения массивов данных. Данные загрузчики имеют автономный жизненный цикл и являются внешними компонентами по отношению к модулю взаимодействия с БД, поэтому их разумно выделить в отдельный модуль. Приложение обладает небольшим количеством фоновых операций, поэтому, по крайней мере, на данном этапе, нет необходимости в выделении отдельных сервисов для работы с БД и веб-сервером. Поэтому, чтобы подчеркнуть функции фонового сервиса, как контекста выполнения операций, веб-клиент также следует вынести в отдельный модуль. Таким образом, окончательная структура дипломного проекта представлена на чертеже ГУИР.400201.086 C1.
Рассмотрим по подробнее каждый из модулей. Модуль авторизации, как и прочие два модуля, ассоциированные с активити, состоит из двух частей, одной из которых является представление, а другой класс-контроллер, унаследованный от класса Activity. Несмотря на это, не следует выделять эти части в два разных модуля, как это можно было бы сделать в случае веб-приложения. Представление, по своей сути, является набором декларативных XML-файлов, описывающих разметку. Несмотря на то, что эти файлы подгружаются динамически классом-контроллером, между ними всё ещё существует неявная, односторонняя, но достаточно существенная связь. В то время как представление ничего не знает о классе-контроллере, да и вообще о структуре классов в целом (исключениями в некотором роде являются пользовательские элементы управления), класс-контроллер должен оперировать строго определёнными элементами представления. Попытка получить элемент, отсутствующий в разметке, неизбежно приведёт к исключению во время исполнения. Кроме этого, следует учитывать, что для получения объектов, ассоциированных с элементами управления используется метод find View ById, принимающий на вход уникальный числовой идентификатор, определённый в разметке, и возвращающий базовый тип View. Таким образом, каждый объект, полученный с помощью данного метода, необходимо приводить к конкретному типу, например, Button или List View, многие из которых обладают уникальными свойствами. Это создаёт ещё одно опасное место, способствующее возникновению ошибок, связанных с приведением типов, и выдаче исключений Class Cast Exception во время исполнения. Помимо этого, существует возможность программно создавать элементы управления и изменять разметку, что способствует более тесной связи представления и класса-контроллера.
Активити авторизации является первым, что видит пользователь приложения. Помимо своих основных функций (предоставления возможности для ввода логина и пароля, а также их валидации) данный модуль также выполняют функцию определения первого запуска приложения. Архитектурой Android-приложения не предусмотрен метод, который вызывается при самом первом старте приложения, или же хотя бы просто при старте приложения. Вследствие этого, зачастую обработка подобных ситуаций производится в начальной активити приложения, то есть, в данном случае, в модуле авторизации. Кроме того, активити авторизации является единственной в приложении, где используются разные разметки для альбомной и портретной ориентации экрана.
Модуль работы с камерой сделан на базе основной, второй по счёту, активити, которую видит пользователь. В данном случае, модуль работы с камерой - это нечто большее, чем простое представление. Android предоставляет определённые возможности для написания пользовательских приложений, работающих напрямую с камерой. Типовое решение предполагает использование определённого элемента управления и реализации нескольких интерфейсов обратного вызова для получения событий от камеры и элементов представления. Помимо этого, важным нюансов является то, что поворот экрана приводит к пересозданию компонента представления, отвечающего за вывод видео потока с камеры. С визуальной точки зрения, такое поведение выглядит не лучшим образом, поэтому определённую сложность представляет собой собственная обработка определения положения экрана и обработка его поворота. Таким образом, получается достаточно тесно связанный, узкоспециализированный модуль, представляющий собой синтез визуальных компонент и класса-слушателя для реакции на события от камеры и датчиков позиционирования телефона.
Ключевым модулем приложения является модуль редактирования метаданных. Его особая роль состоит в том, что он контактирует с многими компонентами системы и является агрегатором данных. В работе модуля можно выделить три основные стадии, в ходе которых он взаимодействует с различными частями приложения. На этапе инициализации модуль получает исходные данные в виде снимка от модуля работы с камерой, а также устанавливает связь с модулями загрузки данных для асинхронного получения кэшированной информации. В следующей фазе своей работы, модуль обеспечивает взаимодействие с пользователем: предоставляет возможности для заполнения формы метаданных, а также обеспечивает сохранение введённых данных до момента отправки. В завершительной фазе модуль становится слушателем событий от фонового сервиса для того, чтобы показывать пользователю прогресс выполнения задачи и предоставить возможность обратной связи в случае возникновения ошибок.
Модуль настроек представляет собой по большей части системную компоненту, которая предоставляет доступ к защищённому фалу настроек приложения, доступному в контексте всего приложения. Типичной практикой является использование модуля настроек для сохранения состоянии приложения между запусками. Помимо этого, модуль настроек связывается с пользовательским интерфейсом, который функционирует как фасад и открывает пользователю часть настроек для редактирования. В зависимости от сложности приложения, модуль, отвечающий за взаимодействия с пользователем может иметь вид не только тонкого клиента, но и достаточно сложно системы, включающей в себя набор собственных элементов представления для редактирования настроек, а также набора компонент, ответственных за быстрое реагирования на смену настроек. В данном проекте модуль пользовательского интерфейса не является сложным и, более того, предоставляет возможности для редактирования довольно общих свойств, важных в контексте всего приложения, а не конкретной сессии. По этой причине приложение предоставляет лишь одну точку входа в интерфейс настроек. Несмотря на это, нижележащий модуль настроек достаточно широко используется всеми основными компонентами системы. Данный факт является основным доводом в пользу выделения двух модулей, имеющих отношение к настройкам.
Достаточно обособленным выглядит модуль работы с БД. Во многом это следствие шаблонов проектирования ОС Android. Платформа предоставляет возможности для автономной инициализации БД при первом запуске приложения, а также позволяет вести версионность БД. При этом, в общем случае, имеется возможность реализации поставщика содержимого (Content Provider), предоставляющий внешний интерфейс для взаимодействия с БД. Поставщик содержимого можно трактовать как аналог сервиса, представляющего публичный API для любых внешних приложений. Конечно, существует возможность ограничения доступа к поставщику. Можно дать права на подключения лишь некоторым приложениям или требовать запроса разрешений от внешних приложений, которые планируют контактировать с поставщиком, или же ограничить видимость поставщика собственных приложением. В последнем случае, фактически, необходимость в поставщике содержимого отпадает, и программист волен сам решать, как реализовывать интерфейс для взаимодействия с БД. В данном проекте БД используется для кеширования данных сервера и нет необхо
Мобильное приложение для оценки эффективности мерчендайзинга торговой компании дипломная работа. Программирование, компьютеры и кибернетика.
История 5 Класс Контрольная Работа 1 Четверть
Әлеуметтік Желінің Пайдасы Мен Зияны Эссе
Реферат по теме Происхождение и сущность глобальных проблем
Реферат: Свежий взгляд на старые теории
Контрольная Работа На Тему Формирование Уставного Фонда Совместного Предприятия
Сочинение Трагедия
Оформление Использованных Источников В Курсовой Работе
Квадратные Уравнения Виды Свойства Примеры Реферат
Отчет по практике по теме Аналіз діяльності приватного підприємства "Вовняночка"
Отчет По Практика Проектов Индивидуальных Домов
Реферат Основные Направления И Задачи Инновационной Политики
Доклад: Фивы
Реферат: Методические рекомендации для студентов для подготовки к семинарскому занятию №18 по дисциплине «Мобилизационная подготовка здравоохранения»
Доклад по теме Селекция
Дипломная работа по теме Разработка бизнес-плана финансового оздоровления металлургического предприятия (на материалах ОАО 'Мценский литейный завод')
Реферат: Грошові розрахунки підприємств 2
Парвовирусный Энтерит Собак Дипломная Работа
Выполнение Контрольных Работ По Математике
Характеристика Технической Подготовки Баскетболистов Реферат
Курсовая работа по теме Внутренний государственный долг: причины возникновения и проблемы погашения
Особенности пищеварения - Биология и естествознание презентация
Характеристика основополагающих принципов теории разделения властей - Государство и право курсовая работа
Религия, государство и право - Государство и право дипломная работа