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

После завершений метода 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 - Прототип экрана отображения детальной информации о заказе

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

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

Android предоставляет коллекцию подклассов 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, и устанавливать их свойства программно.

Android дает возможность использовать один или оба этих метода для объявления и управления пользовательским интерфейсом мобильного приложения. Например, вы можете объявить макеты по умолчанию вашего приложения в 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 - Список файлов, содержащих описание пользовательского интерфейса

Xamarin.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 для отображения фотографии транспортного средства.

2.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.

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

2.8.1 AlarmManager

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

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

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

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

2.8.2 JobScheduler

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

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

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

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

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

2.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].

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

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

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

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

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

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

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

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

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

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

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

- по требованию. Запуск адаптера синхронизации в ответ на действие пользователя.

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

2.8.5 Режим Doze

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

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

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

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

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

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

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

- AlarmManager, позволяет строго держать частоту срабатывания сигнала и пробуждения устройства, но негативно влияет на автономную работу устройства;

- JobScheduler обеспечивает эффективное планирование фоновых задач, но работает с версией Android выше 5;

- GCM Network Manager обеспечивает эффективное планирование фоновых задач, если пользователь установил сервисы Google Play и проще в управлении, чем JobService.

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

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

AlarmManager и GCM Network Manager являются единственными вариантами для прерывания режима Doze.

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

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

- UpdateOrdersService, осуществляет синхронизацию списка заказов;

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

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

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

2.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, так и на реальных устройствах, используемых в организации.

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

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

2. Документация по Apache Cordova [Электронный ресурс]: Apache Cordova Documentation - Режим доступа: https://cordova.apache.org/docs/en/latest/

3. Руководство по Xamarin.Android [Электронный ресурс]: Xamarin.Android guides - Режим доступа: https://developer.xamarin.com/guides/android/

4. Разработка мобильных приложений с использованием Xamarin [Электронный ресурс]: Learn about mobile development with Xamarin - Режим доступа: https://msdn.microsoft.com/library/mt488768.aspx

5. Википедия [Электронный ресурс]: 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.

8. Helder Vasconcelos. Asynchronous Android Programming / Helder Vasconcelos - Packt Publishing, 2016. - 394 p.

9. Dawn Griffiths. Head First Android Development: A Brain-Friendly Guide / Dawn Griffiths, David Griffiths - O'Reilly Media, 2015 - 734 p.

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

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

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

Размещено на Allbest.ru