Создание мобильного приложения для организации

метки: Приложение, Разработка, Работа, Дипломный, Активность, Метод, Система, Устройство

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

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

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

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

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

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

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

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

Автоматизация кадрового учета сотрудников в организации

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

Целью данной дипломной работы является создание мобильного приложения для организации информационного обмена между мобильными сотрудниками компании ООО «Техника 24» и существующими информационными системами компании.

Для достижения поставленной цели следует решить основные задачи:

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

1. Постановка задачи

Основной деятельностью организации ООО «Техника 24» является оказание услуг помощи на дорогах Москвы и Московской области.

Для оказания услуг техпомощи и эвакуации организация имеет собственный колл-центр, а также парк спецтехники (эвакуаторы и машины техпомощи) обслуживаемый мобильными сотрудниками компании.

Сотрудники колл-центра организации обрабатывают входящие звонки клиентов и регистрирует всю необходимую для оказания услуг информацию в CRM (Customer Relationship Management) системе и передают ее мобильным сотрудникам посредством телефонной связи.

При изменении деталей заказа, сотрудник колл-центра передает информацию мобильному сотруднику повторно.

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

1.1 Описание приложения

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

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

Пользователи приложения могут авторизоваться, используя соответствующие логин и пароль, установленные для них в CRM системе.

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

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

• быстрого набора номера клиента из данных заказа;
• поиска адреса оказания техпомощи из данных заказа во внешних программных средствах таких как Яндекс. Карты, Google Maps и другие;

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

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

Разработка стратегического развития транспортной компании на ...

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

1.2 Требования к приложению

Синхронизация данных о заказах должна происходить не реже 1 раза в минуту при наличии связи смартфона с интернетом.

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

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

Приложение должно работать на смартфонах под управлением операционной системы Android версии 5 и выше.

Приложение должно поддерживать возможность работы как в портретной, так и в альбомной ориентации экрана.

Приложение должно сохранять состояние пользовательского интерфейса во время переключения на другие приложения или сворачивании всех приложений.

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

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

Пользовательский интерфейс приложения должен быть нативным для платформы Android и соответствовать основным рекомендациям по разработке приложений для данной платформы (Android User Interface Guidelines).

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

Обмен информацией с CRM должен происходить по протоколу http путем передачи сообщений в формате JSON с использованием существующего API CRM.

1.3 Технология разработки мобильных приложений

Есть множество платформ и инструментов, доступных для выбора при разработке мобильных приложений. Все инструменты можно условно разбить на три основные категории: web-приложение, гибридное приложение, нативное приложение. Рассмотри каждую из них.

3.1 Web-приложение

Web-приложения — это сайт, оптимизированный для просмотра на мобильном устройстве.

Web-приложения используют для работы браузер телефона. Web-приложения не нужно загружать из магазина приложений, чаще всего пользователи переходят по заданному URL а затем получают возможность закрепить закладку на эту страницу на домашнем экране смартфона. Также такие приложения могут распространяться через специальные магазины web-приложений, которые есть в некоторых браузерах. Главной особенностью web-приложений является их кроссплатформенность — возможность работать на всех устройствах, без дополнительной адаптации.

Подавляющее большинство web-приложений создается при помощи JavaScript, CSS и HTML5. При создании web-приложений разработчик не имеет такого программного обеспечения для разработки как SDK (software development kit) для доступа к функциям мобильной платформы. Независимо от установленной операционной системы такие приложения не могут напрямую использовать программное обеспечение смартфона. С помощью браузера такие приложения могут получить доступ к таким функциям как геолокация, звонок по ссылке, вызов камеры телефона для получения фотографии. Однако множество встроенных функций операционной системы смартфона на данный момент не доступны для web-приложений: уведомления в фоновом режиме, автономное хранилище данных, данные акселерометра, функции безопасности и другие [1].

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

... игр 1. Разработка концепции: возраст пользователя. вид игры: развлекающая, развивающая, обучающая, комплексная. 1.3 Архитектура Android C точки зрения программиста, Android - платформа, абстрагирующая разработчика ... разрешений. Пользователю перед установкой демонстрируются разрешения, которые необходимо предоставить приложению для его работы. Эти разрешения включают в себя доступ к телефонным ...

Для разработки таких приложений существуют шаблоны и фреймворки, такие как Angular, React и Vue.js. Разработка web-приложений может быть простой и быстрой, однако их простота также является их недостатком. Web-приложения являются хорошим способ проверить идею, прежде чем выделять ресурсы для разработки нативного мобильного приложения.

Плюсы:

• кроссплатформенность;
• не требует установки;
• короткий цикл разработки. Обновления вступают в силу немедленно, после внесения изменений.

Минусы:

• требует постоянного подключения к интернету;
• не имеет доступ к системным возможностям смартфона и другому программному обеспечению смартфона;
• трудно добиться полностью одинаковой работы приложения на разных моделях телефонов;
• трудно имитировать нативные элементы пользовательского интерфейса для различных моделей смартфонов.

3.2 Нативное мобильное приложение

Нативные приложения — приложения, разработанные специально для одной конкретной операционной системы смартфона.

Такое приложение поставляется через специальные магазины для приложений. Нативные приложения обеспечивают лучшее удобство использования, доступность наибольшего количества функций и лучшее соответствие рекомендациям по разработке пользовательского интерфейса (Android User Interface Guidelines).

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

Главными преимуществами нативных приложений является скорость работы, одинаковый внешний вид и поведение на различных

Плюсы:

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

Минусы:

• необходима отдельная реализация для каждой платформы;
• долгий цикл разработки;
• высокая стоимость производства.

3.3 Гибридное приложение

Гибридное приложение — это web-приложение, построенное с использованием HTML5 и JavaScript, которое затем обернуто внутри тонкого собственного контейнера, который обеспечивает доступ к встроенным функциям платформы.

Гибридное приложение является компромиссом между web-приложением и нативным решением. Как и нативные приложения, они распространяются с помощью магазина приложений и могут пользоваться большинством доступных функций устройства. Как и web-приложения, они используют HTML, отображаемый в браузере, только браузер встроен в само приложение.

Гибридное приложение идеально подходит для тех, кто хочет пользоваться средствами web-разработки, но кому также нужен доступ к функциям мобильной операционной системы. Приложение разрабатывается один раз, а потом транслируется на нативные языки каждой конкретной платформы [2].

Плюсы:

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

Минусы:

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

3.4 Выбор технологии для разработки приложения

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

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

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

Традиционными средствами разработки приложений под Android является язык программирования Java, принадлежащий компании Oracle. Основным средством разработки до декабря 2015 года являлась свободная интегрированная среда разработки модульных кроссплатформенных приложений — Eclipse. В декабре 2015 года компания Google, официальный владелец Android, установила официальным средством разработки — Android Studio (интегрированная среда разработки (IDE) для работы с платформой Android).

Другим, набирающим в последнее время популярность, инструментом для разработки мобильных приложений является платформа Xamarin.предлагает единый язык — C #, библиотеку классов и среду выполнения, которая работает на всех трех мобильных платформах iOS, Android и Windows Phone, но при этом собирает нативные приложения, которые достаточно производительны даже для написания сложных приложений и игр [3].

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

• полное связывание с нативными SDK — Xamarin содержит привязки почти для всех функций нативных SDK как для мобильной операционной системы iOS, так и для Android. Кроме того, эти привязки строго типизированы, что означает, что по ним легче ориентироваться и использовать, а также обеспечить надежную проверку типа во время компиляции, то есть на этапе разработки. Это приводит к уменьшению количества ошибок во время выполнения и приводит к повышению качества приложений;

• интероперабельность c Objective-C, Java, C и C++ — Xamarin предоставляет средства для непосредственного вызова Objective-C, Java, C и C++ библиотек. Это позволяет использовать существующие библиотеки мобильных операционных систем iOS и Android, написанных на Objective-C, Java или C/C++. Кроме того, Xamarin позволяет связывать проекты, что позволяет легко связывать собственные библиотеки Objective-C и Java с использованием декларативного синтаксиса;

• современные языковые конструкции — приложения Xamarin написаны на современном языке C;
• обширная библиотека базового класса — приложения Xamarin используют.NET BCL (Base Class Library), коллекцию классов, которые имеют функции для работы с XML, базами данных, сериализацией объектов, вводом-выводом, строками и сетью, и другие;

• современная интегрированная среда разработки (IDE) — Xamarin использует Xamarin Studio при работе в операционной системе Mac OS X и Visual Studio при работе в Windows. Это современные IDE, которые включают такие функции, как автодополнение кода сложную систему управления, большую библиотеку шаблонов проектов, встроенную поддержку систем контроля версий и многие другие;

— кроссплатформенность — Xamarin предлагает поддержку кроссплатформенности для трех основных мобильных платформ iOS, Android и Windows Phone. Приложения могут быть содержать до 90% общего кода, а библиотека Xamarin.Mobile предоставляет унифицированный API для доступа к общим ресурсам на всех трех платформах. Это может значительно снизить затраты на разработку мобильных приложений, ориентированных на три самые популярных мобильных платформы.

Благодаря широкому набору функций Xamarin остается на сегодняшний день единственным выбором для разработчиков мобильных приложений, которые хотят использовать современный высокоуровневый язык программирования C# и платформу для разработки кроссплатформенных мобильных приложений [4].

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

Многие ключевые характеристики Java можно найти в C#:

• основанное на классах объектно-ориентированное программирование;
• сильная типизация;
• поддержка интерфейсов;
• дженерики;
• сборка мусора;
• компиляция во время выполнения.

И Java, и C# компилируются на промежуточный язык, который запускается в управляемой среде исполнения. Оба C# и Java статически типизированы, и оба языка рассматривают строки как неизменяемые типы. Оба языка используют иерархию классов с одним корнем. Подобно Java, C# поддерживает только одно наследование и не позволяет использовать глобальные методы. На обоих языках объекты создаются в куче с использованием нового ключевого слова, а объекты собираются с мусором, когда они больше не используются. Оба языка предоставляют официальную поддержку обработки исключений с семантикой try/catch. Оба обеспечивают поддержку потоков и поддержку синхронизации.

Однако между Java и C# существует множество различий:

• Java не поддерживает неявно типизированные локальные переменные (C# поддерживает ключевое слово var);
• в Java вы можете передавать параметры только по значению, в то время как в C# вы можете передавать как по ссылке, так и по значению.

(C# содержит ключевые слова ref и out для передачи параметров по ссылке, в Java нет эквивалента);

• Java не поддерживает директивы препроцессора, такие как #define;
• Java не поддерживает целые типы без знака, в то время как C ulong типы, такие как ulong, uint, ushort и byte;

• Java не поддерживает перегрузку оператора;
• В C# вы можете перегружать операторы и конверсии;

• в выражении оператора Java код может попасть в следующий раздел коммутатора, но в C# конец каждого раздела коммутатора должен завершать коммутатор (конец каждого раздела должен завершаться оператором break);
• в Java вы указываете исключения, создаваемые методом с ключевым словом throw, но C# не имеет понятия проверенных исключений — ключевое слово throw не поддерживается в C#;
• C# поддерживает Language-Integrated Query (LINQ), который позволяет использовать зарезервированные слова from, select и where писать запросы к коллекциям способом, похожим на запросы к базе данных [5].

Язык C# является самым богатым на сегодняшний день языком программирования. Он предоставляет множество самых передовых техник — атрибуты, делегаты и события, лямбда-выражения, замыкания, язык запросов LINQ, универсальные классы и функции, анонимные типы, асинхронные методы. Язык динамично развивается, с каждой версией разработчики получают новые возможности. Такие встроенные возможности языка как события позволяют значительно упростить разработку пользовательского интерфейса и сократить количество кода необходимого для реакции на взаимодействие пользователя с графическим интерфейсом.

2. Разработка приложения, .1 Описание существующего API

Для взаимодействия с существующими информационными системами предприятия — CRM системой, был предоставлен набор методов для удаленного вызова процедур по протоколу HTTP (HyperText Transfer Protocol) описание которых приведено в таблице 2.1.

Таблица 2.1 — Методы API

Название метода	Метод HTTP	Заголовки	Параметры запроса	Формат ответа	Назначение
getdriver	GET	Authorization		JSON объект	получение данных о пользователе
getdrivers	GET			JSON объект	получение списка пользователей
getorders	GET	Authorization		JSON объект	получение списка заказов
uploadphoto	POST	Authorization, Content-Type: «multipart/form-data»	photo_order, photo	Код состояния HTTP	загрузка файла фотографии

Метод getdriver возвращает JSON объект содержащий данные о пользователе логин и пароль которого были переданы с помощью заголовка Authorization.

Метод getdrivers возвращает JSON объект, содержащий массив доступных пользователей.

Метод getorders возвращает JSON объект, содержащий массив заказов, привязанных к пользователю, логин и пароль которого были переданы с помощью заголовка Authorization.

Метод uploadphoto принимает данные в виде multipart/form-data запроса в котором должны содержаться параметр photo_order, указывающий на номер заказа к которому принадлежит фотография, и photo содержащий снимок в формате base64 и возвращает код HTTP 202 Accepted в случае удачной загрузки фотографии.

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

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

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

Существует четыре различных типа компонентов приложения:

• активности (Activity);
• сервисы (Service);
• получатели широковещательных сообщений (Broadcast receiver);
• поставщики контента (Content provider).

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

2.2.1 Активность

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

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

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

Активности приложения являются наследниками базового класса Activity.

В разработанном мобильном приложении реализовано три класса активности:

• StartActivity является точкой входа в приложение. При запуске данной активности проверяется, произведён ли вход пользователя в приложение, на основании чего управление предается в одну из двух следующих активностей;
• LoginActivity содержит пользовательский интерфейс и методы для осуществления входа (аутентификации) в приложение;
• MainActivity является главной рабочей активностью приложения и контейнером для основных фрагментов.

2.2.2 Сервис

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

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

• сервис переднего плана — это сервис, о котором пользователь активно осведомлен, и поэтому он не является кандидатом для удаления системой в случае нехватки памяти. Сервис переднего плана должен выводить уведомление в строку состояния. Это уведомление не может быть удалено, пока сервис не будет остановлен или удален с переднего плана;

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

Сервис является привязанным, когда компонент приложения привязывается к нему вызовом bindService().

Привязанный сервис предоставляет клиент-серверный интерфейс, который позволяет компонентам взаимодействовать с сервисом, отправлять запросы, получать результаты и даже делать это между разными процессами посредством межпроцессного взаимодействия (IPC).

Привязанный сервис работает только пока к нему привязан другой компонент приложения. К сервису могут быть привязаны несколько компонентов одновременно, но, когда все они отменяют привязку, сервис уничтожается [6].

Сервис реализуется как подкласс базового класса Service.

В приложении используются сервисы, унаследованные от класса IntentService, потомка класса Service упрощающего работу с многопоточностью.выполняет вызов метода getorders API CRM системы для получения списка заказов и сохраняет изменения в базе данных.

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

2.3 Получатель широковещательных сообщений

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

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

В приложении использовано три подкласса класса BroadcastReceiver.

StartServicesReceiver подписан на событие «android.intent.action.BOOT_COMPLETED» которое вызывается при завершении загрузки операционной системы. Этот класс восстанавливает уничтоженные после перезагрузки устройства задания для запуска сервисов синхронизации.обрабатывает событие запланированного запуска сервиса UpdateOrdersService

UploadPhotosAlarmReceiver обрабатывает событие запланированного запуска сервиса UploadPhotosService

2.4 Поставщик контента

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

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

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

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

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

Когда система запускает компонент, он запускает процесс для содержащего его приложения, если оно еще не запущено. Например, если приложение запускает активность в приложении камеры, эта активность выполняется в процессе, который принадлежит приложению камеры, а не в процессе первого приложения.

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

2.5 Вызов компонентов

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

Намерения связывают отдельные компоненты друг с другом во время выполнения.

Намерение создается с помощью объекта Intent, который содержит сообщение для активации либо конкретного компонента (явного намерения), либо определенного типа компонента (неявный намерение).

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

Для получателей широковещательных сообщений намерение просто передает широковещательное сообщение.

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

Существуют также другие методы вызова каждого типа компонента:

• активность можно вызвать с помощью методов startActivity() или startActivityForResult() (когда активность должна возвращать результат);
• начиная с Android версии 5 можно использовать класс JobScheduler для отложенного запуска действий;
• можно послать широковещательное сообщения используя методы sendBroadcast(), sendOrderedBroadcast() или sendStickyBroadcast();
• можно послать запрос поставщику контента с помощью метода query() класса ContentResolver.

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

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

Прежде чем система Android сможет запустить компонент приложения, система должна знать, что этот компонент существует. Приложение должно регистрировать свои компоненты в собственном файле AndroidManifest.xml. Платформа Xamarin может генерировать записи в этом файле основываясь на атрибутах классов, так, например, активности разработанного приложения зарегистрированы с помощью атрибута Activity а получатели широковещательных сообщений с помощью атрибута BroadcastReceiver и IntentFilter.

Кроме компонентов приложения файл манифеста содержит список разрешений необходимых приложению, например, для доступа в интернет или чтения контактов пользователя. Также в этом файле объявляется минимальная версия операционной системы для с которой будет работать данное приложение, сторонние библиотеки с которыми связано приложение и требования к функциональным возможностям мобильного устройства [3].

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

2.2.7 Объявление требований приложения

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

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

2.8 Ресурсы приложений

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

Для каждого ресурса, включаемого в проект Android, инструменты SDK задают уникальный целочисленный идентификатор, который может использоваться, чтобы сослаться на ресурс из кода приложения или из других ресурсов, определенных в XML. Например, если в приложении имеется файл изображения с именем logo.png (сохраненный в папке res/drawable/), инструменты SDK сформируют идентификатор ресурса под именем R.drawable.logo, с помощью которого на изображение можно будет ссылаться и вставлять его в пользовательский интерфейс [6].

Один из наиболее важных аспектов предоставления ресурсов отдельно от исходного кода заключается в возможности использовать альтернативные ресурсы для различных конфигураций устройств. Например, определив строки пользовательского интерфейса в XML, можно перевести их на другие языки и сохранить эти переводы в отдельных файлах. Затем по квалификатору языка, добавленному к имени каталога ресурса (например, res/values-ru/ для строк на русском языке), и выбранному пользователем языку система Android применит к пользовательскому интерфейсу строки на соответствующем языке.поддерживает разные квалификаторы для соответствующих ресурсов. Квалификатор представляет собой короткую строку, которая включается в имена каталогов ресурсов с целью определения конфигурации устройства, для которой эти ресурсы следует использовать. В качестве другого примера можно сказать, что для активностей следует создавать разные макеты, которые будут соответствовать размеру и ориентации экрана устройства. Например, когда экран устройства имеет книжную ориентацию (расположен вертикально), кнопки в макете можно также размещать по вертикали, а когда экран развернут горизонтально (альбомная ориентация), кнопки следует размещать по горизонтали. Чтобы при изменении ориентации экрана изменялся макет, можно определить два разных макета и применить соответствующий квалификатор к имени каталога каждого макета. После этого система будет автоматически применять соответствующий макет в зависимости от ориентации

Макет экрана входа в приложение выполнен в дух вариантах: для портретной ориентации экрана и для альбомной. Для этого соответствующие файлы помещены в папки ресурсов с названиями layout-land и layout-port.

3 Жизненный цикл приложения

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

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

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

Жизненный цикл активности Android включает набор методов, определенных в базовом классе Activity, которые предоставляют структурированный подход к управлению ресурсами.

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

Рисунок 2.1 — Состояния активности

Эти состояния можно разбить на четыре основные группы следующим образом:

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

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

• в фоне/остановлена. Активности, полностью перекрытые другими активностям, считаются остановленными или находящимися в фоновом режиме. Остановленные активности по-прежнему пытаются сохранить информацию о своем состоянии и состоянии дочерних элементов как можно дольше, но при этом они обладают наименьшим приоритетом и могут быть убиты операционной системой в любое время для поддержания работоспособности активностей с более высоким приоритетом;

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

Еще больше усложняет управление жизненным циклом приложения изменения конфигурации (Configuration Changes).

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

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

2.3.1 Методы жизненного цикла

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

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

Следует рассмотреть работу каждого из методов жизненного цикла активности отдельно.

Метод OnCreate — это первый метод, который вызывается при создании активности. OnCreate всегда переопределяется для выполнения инициализации активности. Во время выполнения этого метода обычно происходит:

• создание представлений;
• инициализация переменных;
• связывание статических данных со списками.

Рисунок 2.2 — Методы жизненного цикла активности

принимает параметр Bundle, который является словарем для хранения и передачи информации состояния и объектов между активностями. Если bundle не является равен null, это указывает на то, что активность перезагружается и должна восстановить свое состояние из предыдущего экземпляра.

Как только OnCreate возвращает управление, операционная система, вызывает метод OnStart.

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

Сразу после завершения метода, операционная система вызывает метод OnResume активности.

Система вызывает метод OnResume, когда активность готова начать взаимодействие с пользователем. Этот метод необходимо переопределить для выполнения таких задач, как:

• запуск анимации;
• запуск прослушивания обновлений GPS;
• отображение любых необходимых предупреждений или диалогов.

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

Метод OnPause вызывается, когда система собирается поместить активность в фоновый режим или, когда активность становится частично скрытой. В этом методе, если необходимо должны выполняться

запись несохраненных изменений в постоянные данные;

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

После завершений метода OnPause может быть вызван один из двух методов:

• OnResume. Будет вызван, если активность должна быть возвращена на передний план;
• OnStop. Будет вызван, если активность помещается в фоновом режиме.

Метод OnStop вызывается, когда действие больше не отображается пользователю. Это происходит, когда активность полностью перекрывается новой или ранее запущенной активностью.

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

Следующие методы жизненного цикла, которые могут быть вызваны — это OnDestroy, если приложение завершается, или OnRestart если приложение возвращается на передний план.

Метод OnDestroy — это последний метод, который вызывается активности перед ее уничтожением и полным удалением из памяти. В экстремальных ситуациях операционная система может убить процесс приложения, которому принадлежит активность, что приведет к тому, что метод OnDestroy не будет вызван. Обычно этот метод не переопределяется, так как большинство необходимых операций выполняется в методах OnPause и OnStop. Метод OnDestroy обычно переопределяется только для остановки долгоживущих фоновых потоков, которые могут вызвать утечку ресурсов.

Метод OnRestart вызывается после того, как активность была остановлена и перед ее повторным запуском.

Нет общих правил относительно того, какая логика должна быть реализована в методе OnRestart. Это связано с тем, что OnStart всегда вызывается независимо от того, создается активность или перезапускается, поэтому любые ресурсы, необходимые для активности, должны быть инициализированы в OnStart, а не в OnRestart.

На многих устройствах Android есть две различные кнопки: кнопка «Назад» и кнопка «Домой». Существует тонкая разница между этими двумя кнопками, хоть обе они и оказывают похожий эффект на приложение отправляя его в фоновый режим. Когда пользователь нажимает кнопку «Назад», она сообщает операционной системе, что пользователь закончил работу с текущей активностью и Android ее уничтожает. Когда же пользователь нажимает кнопку «Домой», активность просто помещается в фоновый режим [9].

2.3.2 Сохранение состояния

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

Основным методом сохранения состояния активности является использование словаря ключ/значения, известного как bundle. Этот объект передается методу OnCreate в качестве параметра, и его можно использовать для восстановления состояния активности. Bundle рекомендуется использовать для сохранения простых значений, таких как строки.

Активность предоставляет методы, помогающие сохранить и восстановить состояние в Bundle.

Метод OnSaveInstanceState, вызывается операционной системой, когда активность уничтожается. Активности могут реализовывать этот метод, если необходимо сохранить любые элементы состояния в словаре bundle.

Метод OnRestoreInstanceState, вызывается после завершения метода OnCreate и предоставляет еще одну возможность для активности восстановить состояние после завершения инициализации.

Метод OnSaveInstanceState получает в качестве параметра объект Bundle, в котором активность может сохранить в свое состояние.

Переопределение OnSaveInstanceState является подходящим механизмом для сохранения временных данных активности, однако реализация OnSaveInstanceState по умолчанию позаботится о временных данных содержащихся в элементах пользовательского интерфейс, а активности, если такие элементы имеют определенный идентификатор, который может быть назначен с помощью атрибута android:id в файле разметки XML. Например, если активность содержит элемент EditText определенный в XML, и он имеет идентификатор, то данные введенные пользователем будут сохранены при изменении конфигурации (повороте экрана).

Метод OnRestoreInstanceState получает в качестве параметра тот же объект Bundle что и метод OnCreate. Этот метод существует для обеспечения некоторой гибкости при восстановлении состояния. Иногда более целесообразно подождать полной инициализации активности прежде чем восстанавливать состояние.

Хотя OnSaveInstanceState упрощает сохранение временных данных, он имеет некоторые ограничения:

• вызывается не во всех случаях. Например, нажатие кнопки «Домой» или «Назад» для выхода из действия не приведет к вызову метода OnSaveInstanceState;
• объект Bundle передаваемый в качестве параметра в OnSaveInstanceState предназначен для хранения больших объектов;
• данные, сохраненные с помощью пакета, сериализуются, что может привести к задержкам во время выполнения приложения.

В активности LoginActivity разработанного приложения для сохранения состояния используется метод OnSaveInstanceState. Восстановление состояния происходит при вызове метода OnCreate, для того чтобы не нужно было обрабатывать вручную сохранение состояния текстового поля.

2.4 Прототипирование пользовательского интерфейса

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

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

Для прототипирования пользовательского интерфейса разрабатываемого мобильного приложения была использована бесплатная версия онлайн сервиса NinjaMock.com.

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

Экран входа в приложение представлен на рисунке 2.3.

Рисунок 2.3 — Прототип экрана входа в приложение

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

Заголовок экрана входа содержит название приложения.

В верхней части экрана входа находится логотип организации.

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

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

Рисунок 2.4 — Прототип экрана, содержащего список заказов

Заголовок экрана со списком заказов содержит название «Список заказов», кнопку для применения фильтра к заказам и кнопку выхода из приложения.

В подзаголовке отображается имя текущего пользователя.

В списке заказов содержатся карточки заказов отображающие основную информацию по ним.

При нажатии кнопки «Фильтр» появляется диалоговое окно с опциями фильтрации заказов представленное на рисунке 2.5.

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

В заголовке экрана содержится название «Просмотр заказа».

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

Рисунок 2.5 — Прототип диалогового окна с опциями фильтрации заказов

В нижней части экрана содержится список прикрепленных к заказу фотографий транспортного средства и кнопка для добавления новых фотографий.

Прототип экрана с подробной информацией по заказу представлен на рисунке 2.6.

Рисунок 2.6 — Прототип экрана отображения детальной информации о заказе

5 Разработка пользовательского интерфейса

Все элементы пользовательского интерфейса в приложении для Android построены с использованием объектов View и ViewGroup. View — это объект, который рисует что-то на экране, с которым пользователь может взаимодействовать. ViewGroup — это объект, который содержит другие объекты View (и ViewGroup), чтобы определить макет интерфейса.предоставляет коллекцию подклассов View и ViewGroup которые содержат часто используемые элементы, такие как кнопки и поля для ввода текста, и различные макеты (Layouts) для группировки элементов: линейный (Linear Layout), относительный (Relative Layout), табличный (Table Layout) и другие.

Каждый подкласс класса ViewGroup предоставляет уникальный способ расположения View, которые вы в нем размещаете. В разработанном мобильном приложении используются два наиболее часто используемых макета: Linear Layout и Relative Layout.

Макет Linear Layout представляет из себя подкласс ViewGroup который выравнивает все дочерние элементы в одном из направлений: вертикально или горизонтально. Направление выравнивания указывается с помощью атрибута android: orientation. Все дочерние элементы Linear Layout располагаются один за другим, поэтому в вертикальном списке будет только один дочерний элемент на строку, независимо от того, насколько они широки, а в горизонтальном списке будет только один дочерний элемент на колонку.

Relative Layout — это подкласс ViewGroup, который отображает дочерние элементы в относительных положениях. Позиция каждого элемента может быть указана относительно соседних в иерархии элементов (например, слева или ниже другого элемента) или в относительно родительской области Relative Layout (например, элемент прижат к низу родительской области, к левому краю, выравнен по центру).

Relative Layout — очень мощная макет, так как он помогает избежать множественных вложений макетов и сохранить иерархию элементов пользовательского интерфейса максимально плоской, что повышает производительность мобильного приложения [6].

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

• объявить элементы пользовательского интерфейса в XML файле. Android предлагает простой синтаксис XML, который содержит элементы, соответствующие классам и подклассам View и ViewGroup определенным в Android SDK;

— создавать элементы макета во время выполнения. Приложение может создавать объекты View и ViewGroup, и устанавливать их свойства программно.дает возможность использовать один или оба этих метода для объявления и управления пользовательским интерфейсом мобильного приложения. Например, вы можете объявить макеты по умолчанию вашего приложения в XML, включая элементы экрана, которые будут отображаться в них и их свойства. Затем вы можете добавить код в приложение, которое изменит состояние объектов экрана, в том числе объявленных в XML, во время выполнения.

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

Для управления внешним видом экранов, используются стили и темы приложения.

Для создания темы приложения соответствующей цветам организации необходимо создать файл styles.xml в папке Resources/values-v21 приложения. Данное расположение файла специфично для версий Android 5 и выше. В файле стилей приложения возможно задать следующие свойства встроенной темы Material Theme:

• colorPrimary — основной цвет приложения. Цвет заголовка приложения;
• colorPrimaryDark — цвет строки состояния и контекстных заголовков приложения;
• colorAccent — цвет таких элементов как флажки, радио кнопки и границы полей для ввода текста;
• windowBackground — цвет фона экрана;
• textColorPrimary — цвет текста основного текста приложения;
• statusBarColor — цвет панели состояния;
• navigationBarColor — цвет панели навигации.

Файлы с описанием пользовательского интерфейса находятся в папке Resources/layout разрабатываемого приложения. Список файлов показан на рисунке 2.7.

Рисунок 2.7 — Список файлов, содержащих описание пользовательского интерфейса

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

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

Файл Login.axml содержит описание пользовательского интерфейса для экрана входа в приложение. Макет экрана входа в приложение строится на основе макета Relative Layout. Макет содержит такие элементы как:

• ImageView — для отображения логотипа организации;
• EditText — для отображения поля для ввода пароля. Элемент EditText содержит атрибут android:inputType установленный в значение «textPassword», что делает введенные в это поле символы замаскированными;

— Spinner — для отображения списка пользователей. Для того чтобы отобразить список пользователей, объекту Spinner необходимо передать объект SpinnerAdapter, который обеспечивает доступ к данным. В разработанном мобильном приложении реализован собственный SpinnerAdapter для отображения выбранным по умолчанию пустого значения.

Файлы UserSpinner.axml, UserSpinnerDropdownItem.axml и UserSpinnerWithEmptySelection.axml являются вспомогательными и описывают отображение выбранного элемента списка пользователей, элемента списка пользователей при открытом выпадающем списке и отсутствие выбранного значения соответственно.

Файл Main.axml cодержит единственный элемент Linear Layout который является контейнером для основных фрагментов приложения.

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

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

Фрагменты находятся внутри иерархии представлений активности и имеет свой собственный макет. Фрагмент может быть добавлен в активность с помощью явного объявления в файле макета активности используя элемент <fragment> или динамически из кода приложения, с помощью добавления его в существующую ViewGroup активности. Однако фрагмент не обязан быть частью макета активности. Фрагмент может быть использован без пользовательского интерфейса в качестве рабочего потока активности.

Файл OrderListFragmet.axml содержит TextView для отображения текущего пользователя и ListView для отображения списка заказов. Для отображения каждого объекта заказа в виде сложного элемента CardView с множеством TextView реализован адаптер данных OrderListAdapter который возвращает View для каждого элемента списка на основе данных из объекта и макета, содержащегося в файле OrderListRow.axml.

Файл OrderDeatilsFragment.axml содержит ListView в котором в качестве заголовка используется детальная информация по заказу отображаемая с помощью макета OrderDeatilsHeader.axml, а элементы списка сформированы при помощи объектов данных о фотографиях прикрепленных к этому заказу и макета PhotoListRow.axml.

Файл ViewPhotoFragment.axml содержит элемент ImageView для отображения фотографии транспортного средства.

6 Хранение данных

В мобильной платформе Android для хранения данных приложений используется база данных SQLite. Для работы с этой базой данных для приложений на платформе Xamarin есть возможность использовать библиотеку SQLite.NET, которая поддерживает технологию ORM (Object-Relational Mapping).

Благодаря технологии ORM используемой в библиотеке SQLite.NET, нет необходимости разрабатывать схему базы данных для несложных объектов, что значительно ускоряет разработку приложения.

Для хранения объектов в базе данных, достаточно описать их параметры с помощью атрибутов определенных в библиотеке SQLite.NET.

Для открытия соединения с базой данных необходимо создать объект SQLiteConnection и передать ему в качестве параметра путь к файлу базы данных. Ели файл отсутствует, то он будет создан с заданным именем.

При обращении к таблицам, необходимо проверять их существование с помощью вызова обобщенного метода CreateTable класса SQLiteConnection. Таблица будет создана, только в случае ее отсутствия в базе данных.

Для работы с данными используются следующие методы класса SQLiteConnection:

• Insert — добавляет новый объект в соответствующую таблицу базы данных. Таблица автоматически определяется из типа передаваемого значения;
• Get<T>

• возвращает объект с заданным первичным ключом (таблица определяется по типу обобщенного параметра);
• Table<T>

• возвращает все записи из таблицы;
• Delete — удаляет объект с заданным первичным ключом;
• Query<T>

• выполняет SQL запрос и возвращает список записей в качестве результата;
• Execute — используется для выполнения SQL запросов, не предполагающих возврата значения (INSERT, UPDATE, DELETE).

2.7 Хранение настроек приложения

Для сохранения небольшой коллекции данных представленных в виде ключ/значение, можно использовать API общих настроек (SharedPreferences).

Объект класса SharedPreferences предоставляет простые методы чтения/записи файла настроек приложения, содержащего коллекцию пар ключ/значение.

Для создания нового или доступа к существующему фалу настроек может быть использован один из двух методов:

• getSharedPreferences() — используется, если необходимо обеспечить работу с несколькими файлами настроек. Имя файла настроек передается в качестве параметра метода;
• getPreferences() — используется если необходимо создать или прочитать один файл общих настроек для заданной активности.

При именовании файлов общих настроек необходимо использовать уникальное имя приложения, например, «com.example.myapp.PREFERENCE_FILE_KEY».

Для записи в файл настрое нужно создать объект класса SharedPreferences.Editor, вызвав метод edit() объекта SharedPreferences.

Значения могут быть записаны с помощью последовательного вызова методов putInt() или putString() (для записи целочисленных и строчных значений соответственно) и метода commit() (для сохранения изменений) объекта SharedPreferences.

Чтобы получить значения из файла общих настроек используются методы, такие как getInt() и getString(), для получения целочисленного или строкового значений переданного ключа.

В приложении используется шаблон проектирования Синглетон для доступа к общим настройкам. Синглетон — это порождающий шаблон проектирования, гарантирующий, что в однопроцессном приложении будет единственный экземпляр некоторого класса, и предоставляющий глобальную точку доступа к этому экземпляру [11].

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

2.8 Синхронизация данных

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

К ним относятся:

• AlarmManager;
• JobScheduler;
• GCM Network Manager;
• SyncAdapter.

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

8.1 AlarmManager

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

Одной из проблем, связанных с работой AlarmManager является то, что все запланированные сигналы удаляются при перезагрузке операционной системы, поэтому приложение должно иметь права RECEIVE_BOOT_COMPLETE для того чтобы планировать запуск сервисов заново при каждом запуске операционной системы [7].

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

8.2 JobScheduler

Класс JobScheduler помогает эффективно работать в фоновом режиме. Сервисы JobService запускаются согласно критериям, установленным в JobInfo с помощью метода JobInfo.Builder().

Эти критерии задают необходимые условия для выполнения JobService, например, выполняться только в режиме ожидания, только при подключении к сети интернет или только при безлимитном подключении. JobInfo также может задавать минимальные задержки между выполнениями JobService и максимальный срок ожидания выполнения JobService. Задания сохраняются в очереди операционной системой если критерии не выполнены, для того чтобы быть исполненными позднее. Операционная система также попытается объединить эти задания вместе таким образом, чтобы сократить время работы при подключении к сети [9].

Для того чтобы создать подкласс базового класса JobService требуется переопределить методы onStartJob и onStopJob.

Метод onStartJob() — вызывается при срабатывании планировщика. Этот метод выполняется в основном потоке и может заблокировать выполнение приложения. Если необходимо выполнить длительную работы, то следует создать новый поток для ее выполнения и вернуть значение true в качестве результата работы метода или false если создание дополнительного потока не понадобилось и вся работа выполнена. Также если потребовалось создание дополнительного потока следует вызвать метод jobFinished() когда задание завершено.

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

8.3 GCM Network Manager

GCM (Google Cloud Messaging) Network Manager фактически использует JobService при работе с Android версии 5 и выше, а поддержка предыдущих версий Android осуществляется я с помощью сервисов Google Play. GCMNetworkManager обладает теми же преимуществами в плане экономии заряда, что и JobScheduler, при этом обладая лучшей обратной совместимостью и более простым API.

Задания создаются с помощью методов OneoffTask.Builder() или PeriodicTask.Builder().

Шаблон Builder (строитель) упрощает добавление критериев планирования к задаче. Критерии почти идентичны критериям JobInfo, и система стремится оптимизировать время автономной работы с помощью объединения вызова заданий, запланированных с помощью GCMNetworkManager.

Для обработки запланированных заданий требуется подкласс базового класса GcmTaskService. GcmTaskService требует переопределения метода onRunTask(), и именно в нем должна выполняться вся работа. Метод onRunTask() запускается в фоновом потоке, что делает его использование немного удобней, чем использование метода onStartJob() класса JobService.

В отличие от JobScheduler задания, установленные с помощью GCMNetworkManager, могут быть потеряны при обновлении приложения или сервисов Google Play. Метод onInitializeTask() класса GcmTaskService может быть переопределен для того чтобы получать уведомление об этом событии и соответствующим образом реагировать на него для повторного планирования заданий [7].

и JobScheduler не созданы для выполнения задач сразу или в определенное время. Они предназначены для выполнения повторяющихся или одноразовых, низкоприоритетных работ и сохранения срока службы батареи. Приложение требующие какой-либо точности во времени вызова сервизов, не должно использовать ни один из этих методов планирования. Это особенно актуально после введения режима Doze в Android версии 5.

2.8.4 Адаптеры синхронизации

Адаптеры синхронизации (Sync Adapters) были созданы с целью решения задач синхронизации Android устройств и серверов. Запуск синхронизации моет быть инициирован изменениями данных на сервере или устройстве, или по истечении определенного времени. Операционная система будет пытаться выполнять синхронизацию пакетно, чтобы сохранить время автономной работы мобильного устройства, и транзакции будут накапливаться в очереди для передачи позже. Система будет пытаться запустить синхронизацию только тогда, когда устройство подключено к сети [6].

Дополнительным плюсом адаптеров синхронизации является возможность для пользователя видеть информацию о состоянии синхронизации и возможность отключать ее.

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

Адаптер синхронизации объявляется в XML файле. В нем указывается поставщик контента и аутентификатор, а также, другие опции, такие как: видимость адаптера синхронизации в настройках и другие.

Существуют следующие варианты запуска адаптера синхронизации:

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

Запуск адаптера синхронизации, когда операционная система Android посылает по сети сообщение, которое держит TCP/IP соединение открытым; это сообщение является частью сетевого взаимодействия. Эта опция является одним из способов для автоматического запуска адаптера синхронизации;

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

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

8.5 Режим Doze

В Android версии 5 был введен режим Doze, как способ свести к минимуму расход энергии батареи, когда пользователь некоторое время не пользуется устройством. Режим Doze автоматически включается на устройствах под управлением Android API уровня 23 и выше. Этот режим сильно влияет на работу сервисов синхронизации.

Режим Doze активируется через некоторое время в таких условиях: экран пользователя отключен, устройство стационарно и устройство не заряжается. В режиме Doze доступ к сети приостанавливается, а стандартные сигналы откладываются, включая запуск адаптеров синхронизации и JobSchedulers. В режиме Doze есть окна обслуживания, которые позволяют всем планировщикам в системе работать сразу, сохраняя заряд батареи организуя нечастые и сгруппированные сетевые вызовы [6].

Работа режима Doze показана на рисунке 2.8.

Рисунок 2.8 — Схема работы режима Doze

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

8.6 Выбор метода синхронизации

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

• AlarmManager, позволяет строго держать частоту срабатывания сигнала и пробуждения устройства, но негативно влияет на автономную работу устройства;
• JobScheduler обеспечивает эффективное планирование фоновых задач, но работает с версией Android выше 5;
• GCM Network Manager обеспечивает эффективное планирование фоновых задач, если пользователь установил сервисы Google Play и проще в управлении, чем JobService.

Адаптеры синхронизации — хорошее решение для синхронизации локальных данных с данными сервера, если в приложении уже реализован аутентификатор и провайдеры контента.

Так как для разрабатываемого приложения наибольшим приоритетом обладает регулярность обновления информации, а время жизни устройства на батарее не играет никакой роли (мобильные устройство большую часть времени находятся на зарядке), то влияние режима Doze на сервисы синхронизации приложения недопустимо.и GCM Network Manager являются единственными вариантами для прерывания режима Doze.

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

Для осуществления процесса синхронизации в приложении реализованы два сервиса:

• UpdateOrdersService, осуществляет синхронизацию списка заказов;
• UploadPhotosService; осуществляет синхронизацию фотографий транспортных средств.

Оба этих сервиса являются наследниками базового класса IntentService.

Класс IntentService автоматически создает очередь намерений, через которые был вызван сервис, что упрощает работу с многопоточностью.

9 Тестирование приложения

В процессе разработки приложения производилось поэтапное тестирование с целью выявления программных ошибок и несоответствий заданным требованиям к приложению. Для этого были созданы эмуляторы смартфона с разными диагоналями экрана для разных версий Android. Тестируемый программный продукт последовательно запускался на этих эмуляторах, его поведение анализировалось, и при необходимости по результатам анализа вносились изменения в код [12].

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

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

2.10 Публикация приложения

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

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

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

• через web-сайт. Файл приложения может быть доступен для загрузки на web-сайте. Загрузив файл, пользователи могут самостоятельно установить приложение. Для установки приложения самостоятельно, пользователь должен обладать некоторой квалификацией. При этом невозможно контролировать обновление приложения;

• непосредственная установка на телефон. Среди работников одной организации возможно распространение мобильного приложения через IT отдел организации. Для установки и обновления приложения пользователям необходимо посещать офис организации;
• через магазин приложений Google Play. Мобильное приложение может быть установлено удаленно и обновлено автоматически.

Для публикации мобильного приложения был выбран сервис Google Play.

Сервис Google Play позволяет ограничить распространение приложения заданной группой пользователей (работников организации), наиболее быстро производить обновление приложения на мобильных устройствах пользователей, а также следить за статистикой критических ошибок приложения.

3. Описание функциональности приложения

При первом запуске приложения отображается экран для входа в приложение показанный на рисунке 3.1.

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

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

Рисунок 3.1 — Экран входа в приложение

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

По умолчанию в списке заказов отображаются только заказы со статусами «выполняется» и «в очереди».

Рисунок 3.2 — Экран со списком заказов текущего пользователя

Короткое описание каждого заказа содержится в отдельных «карточках» списка. Статус заказа отображается в нижней части «карточки».

Для отображения заказов с другими статусами необходимо воспользоваться кнопкой «фильтр», расположенной в правом верхнем углу экрана приложения. Рядом с кнопкой фильтр располагается кнопка для выхода из приложения.

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

При нажатии кнопки «фильтр» будет вызвано диалоговое окно с возможностью выбора вариантов фильтрации заказов, представленное на рисунке 3.3.

Рисунок 3.3 — Диалоговое окно с опциями фильтрации заказов пользователя

При нажатии на любую из «карточек» в списке заказов будет открыт экран, содержащий детали заказа, представленный на рисунке 3.4.

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

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

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

Рисунок 3.4 — Экран, содержащий подробную информацию о заказе

Заключение

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

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

Приложение было протестировано на стандартных эмуляторах включенных в поставку программных средств для разработки мобильных приложений Android (Visual Studio Emulator for Android и Android SDK Emulator), взятых из SDK Android, так и на реальных устройствах, используемых в организации.

Список использованных источников

[Электронный ресурс]//URL: https://inzhpro.ru/diplomnaya/temyi-diplomnyih-rabot-po-razrabotke-prilojeniy/

1. Прогрессивные Web-приложения [Электронный ресурс]: Progressive Web Apps — Режим доступа: https://developers.google.com/web/progressive-web-apps/

• Документация по Apache Cordova [Электронный ресурс]: Apache Cordova Documentation — Режим доступа: https://cordova.apache.org/docs/en/latest/
• Руководство по Xamarin.Android [Электронный ресурс]: Xamarin.Android guides — Режим доступа: https://developer.xamarin.com/guides/android/
• Разработка мобильных приложений с использованием Xamarin [Электронный ресурс]: Learn about mobile development with Xamarin — Режим доступа: https://msdn.microsoft.com/library/mt488768.aspx
• Википедия [Электронный ресурс]: Comparison of C Sharp and Java — https://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java

6. Руководство по Android API [Электронный ресурс]: Android API Guides — Режим доступа: https://developer.android.com/guide/index.html

7. Reto Meier. Professional Android 4 Application Development. / Reto Meier — Wrox, 2012. — 864 p.

• Helder Vasconcelos. Asynchronous Android Programming / Helder Vasconcelos — Packt Publishing, 2016. — 394 p.
• Dawn Griffiths. Head First Android Development: A Brain-Friendly Guide / Dawn Griffiths, David Griffiths — O’Reilly Media, 2015 — 734 p.

10. Роберт Дж. Торрес. Практическое руководство по проектированию и разработке пользовательского интерфейса / Роберт Дж. Торрес — М.: Вильямс, 2002 — 400 с.: ил.

• Рихтер, Дж. CLR via C#. Программирование на платформе Microsoft .NET Framework4.0 на языке C#. 3-е изд. — СПб.: Питер, 2012. — 982 с.: ил.
• Котляров В.П.

Основы тестирования программного обеспечения. / В.П. Котляров, Т.В. Коликова — М.: Интернет-Университет Информационных Технологий, 2014. — 285 с.: ил.