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

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

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

Рассмотрим внешний вид экранов коллекции, взятый из макетов дизайна (см. рисунок 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, примененный во всём приложении, так как при таком большом количестве интерактивных элементов в ячейках, перерисовка будет занимать очень много времени каждый раз.

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

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

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

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

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