Разработка функциональных модулей мобильного приложения на платформе iOS для музея "Оружейная палата Кремля"

Первая часть описывает классы, обслуживающие все разделы, кроме игр. Вторая часть целиком освещает классы, обслуживающие экраны игр. Как можно видеть из рисунков А1 и А2, обе части диаграммы имеют один и тот же родительский класс - AncestorObject.

Структура классов довольно проста, для переиспользования основные поля похожих объектов наследуются от родителя (например, классы Hall, Case и Exhibit наследуют поля класса KremlinObject). Классы, объекты которых являются полями более больших классов, связаны с ними композицией или агрегацией, в зависимости от того, необходимо это поле для полноценности крупного класса или нет.

Следует отметить, что в процессе обсуждения руководителем проекта было озвучено желание использовать компонентный подход к проектированию объектной модели. В таком случае, сократилась бы глубина наследования, а дополнительные функции и поля классы получали бы с помощью интерфейсов. Например, класс KremlinObjectsWithContours бы исчез, а вместо этого, классы Hall и Case реализовывали интерфейс IHasContours. В результате обсуждения, подход был отклонён по двум причинам. Во-первых, существовала предложенная музеем модель данных, и реализация компонентной модели привела бы к дополнительным усилиям по экспорту данных из одной модели в другую. Во-вторых, требуемые сроки разработки не позволяли выделить время на переработку модели.

2.4 Разработка интерактивного прототипа

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

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

В данной главе было проведено моделирование сценариев использования мобильного приложения для Оружейной палаты. Сценарии использования были построены в виде диаграмм последовательности UML. Также, была описана объектная модель приложения в виде диаграммы классов UML. В заключение, был разработан интерактивный прототип приложения с помощью сервиса Marvel App.

3. Разработка функциональных модулей приложения

3.1 Разработка архитектуры приложения

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

1. MVC (Model - View - Controller) - наиболее распространенный паттерн разработки мобильных приложений, как для платформы iOS, так и для платформы Android. Диаграмма классов стандартного варианта MVC представлена на рисунке 3.1:

Рисунок 3.1. Диаграмма классов стандартного паттерна MVC

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

2. MVP (Model - View - Presenter) - шаблон проектирования пользовательского интерфейса, который был разработан для облегчения автоматического модульного тестирования и улучшения разделения ответственности в презентационной логике (отделения логики от отображения). В отличие от MVC, в данном паттерне элемент View не связан с моделью и является пассивным. Фактически, модификация MVC, рекомендуемая Apple, на самом деле представляет собой паттерн MVP (см. рисунок 3.2):

Рисунок 3.2. Паттерн Apple MVC (MVP)

Главным недостатком паттернов MVC и MVP является так называемый Massive View Controller: увеличение объема кода в элементе Controller, связанное с необходимостью реализации сложной логики, или увеличением размеров моделей. В связи с этим, поддерживать такие контроллеры становится неудобно и трудозатратно.

3. VIPER (View-Interactor-Presenter-Entity-Router) - архитектура, предложенная в статье Clean Architecture от Uncle Bob. Данная архитектура призвана решить проблему Massive View Controller путем увеличения модульности кода, что также облегчает модульное тестирование. Рассмотрим диаграмму классов паттерна VIPER (см. рисунок 3.3):

Рисунок 3.3. Паттерн VIPER

VIPER можно назвать улучшенной версией MVP. Как и в MVP, элемент View в данном паттерне является пассивным, и отвечает только за работу с UI. Следующий по логике слой, Presenter, отвечает за коммуникацию VIPER-объекта с другими, и обеспечивает прослойку между View и слоем Interactor, который отвечает за работу с источниками данных. Entity - определяет вид модели данных.

4. MVVM (Model - View - View Model) - вариант архитектуры MVC, адаптированный для реактивного программирования. Диаграмма классов представлена на рисунке 3.4:

Рисунок 3.4. Паттерн MVVM

View Model ничего не знает о View Controller. Он никогда не ссылается на него и не имеет свойства напрямую. Вместо этого View Controller постоянно следит за любыми изменениями View Model, и как только изменения произойдут, они сразу будут отображены на экране. Это, в некотором смысле, односторонняя связь между ViewController и ViewModel. ViewController может видеть и обращаться к ViewModel, но у ViewModel нет ни малейшего представления о том, кто такой ViewController. Это значит, что можно полностью удалить ViewController из своего приложения, и вся логика останется нетронутой. Этот паттерн лег в основу реактивного программирования под мобильные платформы.

Для приложения Оружейной палаты Кремля был выбран паттерн VIPER. Основанием для выбора данной архитектуры была её модульность, которая облегчила бы работу в большой команде, а также простота покрытия тестами маленьких модулей. От реактивного MVVM было решено отказаться, так как он не обеспечивал бы должной атомарности кода. Как будет описано далее, даже выбор VIPER не спас от Massive View Controller в нескольких случаях, но он существенно облегчил тестирование и поддержку.

3.2 Выбор и настройка инструментов разработки

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

Выбор IDE.

Для iOS разработки существуют только 2 варианта IDE:

1. Apple Xcode - IDE, разработанная и рекомендуемая к использованию компанией Apple. Является мощным и довольно удобным инструментом, содержит в себе встроенный графический редактор интерфейсов, инструменты для анализа утечек памяти, производительности, симуляторы различных устройств и многое другое. К её недостаткам относятся наличие огромного количества багов, частые вылеты, ресурсоемкость.

2. JetBrains AppCode - легковесная IDE, разработанная компанией JetBrains на основе других своих продуктов. Отличается потрясающей скоростью работы и наличия огромного количества удобных и функциональных горячих клавиш. К её недостаткам можно отнести отсутствие встроенного редактора интерфейсов и слабую интеграцию с сервисами Apple а также высокую цену лицензии.

Для данного проекта была выбрана IDE от Apple, во-первых, ввиду бесплатного распространения, а во-вторых, ввиду того, что большая часть команды проекта, включая автора работы была новичками в iOS разработке. А IDE Xcode является фундаментом, с которого начинается обучение стажеров.

Выбор генератора исходного кода.

Одним из недостатков модульности архитектуры VIPER является большое количество файлов в проекте. К примеру, на Objective C, для одного VIPER - модуля требуется создать больше 15 файлов и минимум 5 папок. Большое количество создаваемых файлов повышает вероятность ошибки из-за человеческого фактора. Поэтому, для автоматизации создания файлов было решено использовать генератор Generamba, созданный сотрудниками компании Rambler. После инициализации в проекте он позволяет генерировать модули с использованием различных шаблонов кода. Исходный код шаблона может выглядеть, например, так (см. рисунок 3.5):

Рисунок 3.5 Пример шаблона Generamba

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

Выбор системы контроля версии и системы авто-сборки.

В качестве системы контроля версий был выбран GitLab, ввиду его универсальности и бесплатности. Доступной альтернативой был стек продуктов Atlassian (Bitbucket+Jira), однако от него было решено отказаться ввиду дороговизны. GitLab также является системой управления проектами, позволяет следить за рабочим процессом с помощью Kanban-Board. Также, GitLab имеет встроенный CI, позволяющий автоматизировать проведение Unit и UI тестирования. Однако, ввиду большой скорости разработки, CI не пригодился в данном проекте. Вместо этого был использован легковесный и скоростной инструмент Fastlane, автоматизирующий выкладку версий в бета- и альфа-тест, а также релиз. Fastlane позволяет свернуть всё в одну команду и не тратить время на рутинное заполнение одинаковых полей на ресурсах Apple. Этот инструмент также имеет возможность дальнейшей интеграции с GitLab CI и другими популярными системами непрерывной интеграции.

3.3 Разработка функциональных модулей приложения

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

Разработка экранов коллекции.

Рассмотрим внешний вид экранов коллекции, взятый из макетов дизайна (см. рисунок 3.6):

Рисунок 3.6. Дизайн экранов коллекции

Как можно видеть из скриншотов выше, экраны коллекции представляют собой довольно простые экраны. Каждый из экранов «Залы», «Викторины» и «Экспонаты» представляет собой таблицу, в ячейках которой отображаются данные, полученные из БД с серверной части приложения. Для реализации таблицы был использован компонент UITableView из фреймворка UIKit.

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

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

Следующим сложным кейсом оказалась работа с плеером, см. рисунок 3.7:

Рисунок 3.7. Работа плеера (внешний вид)

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

Для решения этой задачи был использован паттерн Observer. Диаграмма классов представлена на рисунке 3.8:

Рисунок 3.8. Паттерн Observer

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

Разработка экрана карты и режима экскурсий.

Одним из самых сложных экранов в приложении Оружейной палаты является экран карты музея. Даже с учетом использования модульной архитектуры VIPER, View Controller данного экрана занимает более 2500 строк кода. Это объяснимо постоянным переиспользованием данного экрана для разных режимов и задач. На финальном этапе разработки, стало понятно, что была допущена ошибка, и нужно было дублировать данный экран для разных режимов работы с картой, каждый раз создавая логику только для конкретного режима.

Рассмотрим внешний вид экрана карты (см. рисунок 3.9):

Рисунок 3.9. Экран карты

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

Экран состоит из элемента MKMapView и элементов управления. Местоположение пользователя на карте определяется либо вручную, путем прокрутки экрана (ручной режим), либо с помощью автопозиционирования по iBeacon'ам. Ближайшие к пользователю объекты на карте (витрины, залы) обозначаются указателями (пинами). Также на экране присутствует возможность работы с плеером.

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

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

Процесс создания данного функционала выглядел следующим образом. Первоначально, в админ-консоли Navigine была создана карта музея и накрыта координатной сеткой. Затем, менеджеры проекта провели кропотливую установку большой сети Bluetooth-маяков в музее. При установке маяка, его местоположения отмечалось на карте, с помощью мобильного приложения от Navigine. В результате, карта в админ-консоли выглядит следующим образом (см. рисунок 3.10):

Рисунок 3.10. Админ-консоль Navigine с картой музея

Затем, такое же изображение карты используется в мобильном приложении как фон для MKMapView, а классы из SDK Navigine отвечают за позиционирование пользователя на карте. Определение положения происходит раз в полсекунды и событие передается контроллеру, чтобы тот отобразил измененное местоположение указателя пользователя.

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

Следующим разработанным в рамках карты функционалом был режим экскурсии (см. рисунок 3.11):

Рисунок 3.11. Режим экскурсии

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

Разработка игры Квесты.

Интерактивная экскурсия в виде квеста-чата была задумана как средство развлечь детей при походе в музей целыми семьями. Внешний вид экрана квеста представлен на рисунке 3.12:

Рисунок 3.12. Внешний вид экрана Квест-чат

Центральным элементом экрана является UITableView, содержащая в себе сообщения-ячейки. Однако, в данной ситуации, каждая ячейка вполне заслуживает отдельного VIPER-модуля, ввиду наполненности различными элементами (галерея картинок, текст, просто картинка и т.д.).

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

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

3.4 Внутреннее и внешнее тестирование приложения

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

Для данных целей был использован описанный выше инструмент Fastlane. Путем создания сценария в файле Fastfile, весь процесс выкладывания очередной версии в бета-тест был полностью автоматизирован и свернут до одной команды в терминале.

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

Заключение

навигация алгоритм серверный

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

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

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

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

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

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

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

7. Приложение предоставлено для внешнего тестирования сотрудникам музея.

В ходе выполнения данной работы получены следующие знания и навыки:

1. Изучено предметное поле Интернета вещей, изучены подходы к реализации indoor-навигации.

2. Изучена математическая модель задачи локального позиционирования и алгоритмы её решения.

3. Получены навыки моделирования предметного поля в крупном проекте.

4. Получены навыки работы с инструментами прототипирования.

5. Изучены преимущества и недостатки существующих архитектур мобильных приложений, получен практический опыт работы на архитектуре VIPER.

6. Изучены современные инструменты для обеспечения инфраструктуры совместной разработки программного обеспечения.

7. Получены навыки командной Agile-разработки в крупном долгоиграющем проекте.

8. Изучен язык программирования Objective-C и специфика разработки под платформу iOS.

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

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

Литература

1. Аверин И.М. «Позиционирование пользователей с использованием инфраструктуры локальных беспроводных сетей» / И.М. Аверин, В.Ю. Семенов // IV Всероссийская конференция «Радиолокация и радиосвязь» (ИРЭ РАН, 29 ноября - 3 декабря 2010 г.). -- М., 2010. -- C. 475-479.

2. Алгулиев Р.Ш. «Интернет вещей» / Р.Ш. Алгулиев, Р.Ш. Махмудов // Информационное общество. - 2013. - № 3. - C. 42-48.

3. Васкевич Д. Стратегии клиент/сервер. - Диалектика, Киев. -1997. -С.24-25.

4. Гмарь Д.В., «Навигация внутри зданий с использованием беспроводной сети (на примере кампуса ВГУЭС)» / Д.В. Гмарь, К.И. Кротенок // Материалы ХХ Всероссийской научно-методической конференции «Телематика'2013». СПб, 2013.

5. Миниахметов Р.М. «Обзор алгоритмов локального позиционирования для мобильных устройств» / Р.М. Миниахметов, А.А. Рогов, М.Л. Цимблер // Вестник Южно-Уральского государственного университета. Серия: Вычислительная математика и информатика. - 2013. - том 2. - №2. - С. 83-96.

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