Разработка мобильного приложения

Разработка мобильного приложения

Введение

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

Дополненная реальность (Augmented Reality, AR) - одно из самых перспективных направлений исследований на сегодняшний день. Эта технология уже зарекомендовала себя во многих сферах человеческой деятельности - например, в образовании, медицине, строительстве и др. Главным достоинством дополненной реальности является наглядность, которая способствует лучшему усвоению информации, ассоциированной с объектом. Благодаря этому, эта технология получила широкое распространение в образовательной и, в частности, в музейной сфере.

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

Актуальность темы объясняется тем, что в современных музеях все больше внимания уделяется непосредственному взаимодействию посетителя с экспонатом. В нескольких исследованиях, посвященных внедрению технологии дополненной реальности в музейную среду, подчеркивается [2; 3], что использование таких приложений оказывает положительное воздействие на уровень восприятия экспонатов посетителями.

Приложение, разработка которого описывается в работе, предназначено для использования на фотографических выставках С.В. Челнокова (1861-1924), московского фотографа-любителя, достигшего заметного успеха в съемке стереофотографий [4]. Стереофотографии, или стереопары, - пары изображений для левого и правого глаз, которые дают эффект глубины (объема) при просмотре через стереоскоп (бинокулярный аппарат для просмотра «объемных» изображений).

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

·Провести обзор и анализ существующих решений.

·Выбрать методы разработки программного обеспечения (ПО) приложения.

·Выбрать инструментальные и программные средства.

·Разработать структуру ПО приложения.

·Разработать ПО приложения.

·Провести тестирование приложения.

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

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

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

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

Практическая значимость исследования состоит в применении разработанного приложения на фотографических выставках С.В. Челнокова.

Основная часть работы представлена четырьмя разделами:

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

·Во втором приводится сравнительный анализ инструментариев для распознавания изображений-маркеров и парсинга (синтаксического анализа) HTML-кода; обосновывается выбор методов для реализации приложения.

·В третьем формируется структура приложения; рассматриваются особенности разработки визуального интерфейса приложения в операционной системе iOS.

·Четвертый содержит описание реализации программного обеспечения приложения и его тестирования.

1. Обзор и анализ предметной области

.1 Обзор технологий дополненной реальности

Впервые термин «дополненная реальность» был использован в 1990 году инженером компании Boeing Томом Коделом (Tom Caudell) [5]. Однако у этого термина до сих пор нет точного и однозначного определения, чем отчасти объясняется тот факт, что приложения с элементами дополненной реальности могут иметь принципиальные различия в интерфейсе и реализации. Одно из наиболее часто используемых определений было предложено в 1997 году исследователем Р. Азума (R. Azuma) [6]. Согласно ему, дополненная реальность является системой, которая имеет три отличительные черты:

.Ассоциирует реальные и виртуальные объекты.

.Доступна для взаимодействия в реальном времени.

.Работает в 3D.

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

Возможность использования технологий дополненной реальности в мобильных приложениях обсуждалась на протяжение последнего десятилетия. Ф. Чжоу (F. Zhou) в исследовании 2008 года [7] подчеркивал, что статьи о мобильной дополненной реальности набирали популярность, составляя 6.1% от общего количества статей об AR. Исследователь отмечал, что эта тема цитируется наиболее часто после базовых вопросов реализации дополненной реальности. Высокому уровню популярности мобильной дополненной реальности также способствует широкое распространение мобильных устройств: согласно прогнозу [1], количество пользователей смартфонов в 2017 году достигнет 2.32 млрд человек.

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

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

А. Дамала (A. Damala) и др. в своем исследовании [8] указывают, что музеи начали внедрять инновационные разработки не лишь в последнее время, а с момента изобретения интернета, что привело к значительному развитию выставочных мультимедийных технологий. Сегодня многие культурные учреждения по всему миру используют различные сервисы для повышения уровня восприятия экспонатов и взаимодействия с посетителями. Один из наиболее ярких примеров применения мультимедийных технологий в музеях - мобильные приложения, которые предоставляют посетителям всю необходимую информацию об экспонатах. Значительная часть таких приложений поддерживает функционал дополненной реальности. Подобные приложения с элементами дополненной реальности используются во многих мировых музеях, однако на российском рынке они еще не так распространены.

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

)Положения посетителя в зале.

2)QR-кодов.

)Самих экспонатов.

Приложения первого типа получают сигналы от нескольких Bluetooth-маяков (например, iBeacon), расположенных в разных частях выставочного зала. Анализируя полученные сигналы, приложение способно определить позицию посетителя в зале и предложить ему контент, ассоциированный с ближайшим к нему экспонатом. Таким образом, главным преимуществом такого подхода является возможность автоматического получения информации без выполнения дополнительных операций. Помимо этого, некоторые исследователи, например, Ч. Хе (Z. He) и др. предлагают использовать маяки iBeacon для создания туров по музею и персональных рекомендаций. Главная проблема такого подхода заключается в небольшой для ряда выставочных залов средней дальности действия маяка (10 метров [9]). Это может привести к необходимости использования большого количества таких устройств, причем эта проблема становится существеннее с увеличением количества пользователей. Таким образом, этот метод идентификации ближайшего к посетителю экспоната является самым дорогим. Еще один существенный недостаток этого подхода - зависимость от инфраструктуры выставочного зала, заключающаяся в необходимости корректировки системы, например, при изменении расстановки экспонатов.

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

При использовании QR-кодов рядом с каждым экспонатом располагается табличка с уникальным кодом, распознав который, посетитель может получить информацию об интересующем его объекте. Этот подход сочетает низкую сложность разработки со сравнительно невысокими дополнительными затратами (на таблички с кодами). Исследователи также положительно отзываются о возможностях применения такого метода. Например, В. Евремович и С. Петровски в [10] предлагают использовать QR-коды и дополненную реальность для представления культурных объектов, недоступных для публики. Однако, согласно некоторым исследованиям, использование QR-кодов в качестве «посредников» между посетителем и экспонатом приводит к уменьшению внимания к самим экспонатам и посредственному взаимодействию с ними [11].

В то же время, К. Чанг и др. утверждают [11], что распознавание самих экспонатов способствует повышению внимания к ним. Этот подход является наиболее естественным для восприятия выставленных объектов, что ведет к более продвинутому взаимодействию между посетителями, экспонатами и музейным мобильным приложением. Помимо этого, идентификация экспонатов не требует дополнительных затрат на оборудование и объекты инфраструктуры, что делает этот вариант наименее дорогим. С другой стороны, многие исследователи соглашаются, что из всех возможных вариантов распознавание экспонатов является наиболее сложной задачей с точки зрения разработки [2; 10; 11]. Также в случае использования этого метода могут возникнуть сложности с распознаванием объемных и несимметричных экспонатов.

.3 Обзор существующих музейных приложений с элементами дополненной реальности

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

Далее представлено описание нескольких наиболее известных и популярных приложений (как зарубежных, так и российских).

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

Основные возможности приложения:

·Интерактивное взаимодействие с картинами.

·Просмотр карты музея, где обозначена расстановка всех экспонатов.

·Демонстрация утраченного оформления здания по наведении камеры.

В итоге, можно выделить следующие достоинства и недостатки приложения:

Достоинства:

·Полнота и доступная подача информации.

·Продвинутая интерактивность.

·Возможность навигации по музею.

·Возможность наглядного представления утраченного наследия.

Недостатки:

·Зависимость от инфраструктуры выставочного зала.

·Отсутствие возможности использовать приложение без интернета.

Приложение «Узнай Москву».

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

Таким образом, приложение обладает следующим функционалом:

·Распознавание кодов и представление информации о достопримечательностях.

·Навигация по всем достопримечательностям с помощью интерактивной карты.

·Навигация по туристическим маршрутам.

·Интеграция с социальными сервисами.

Достоинства:

·Полнота представляемой информации (текст, изображения, аудио).

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

·Структурированное представление достопримечательностей.

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

·Представление маршрутов только в текстовом виде.

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

Приложение «Artefact».

Приложение было разработано Министерством Культуры РФ в сотрудничестве с интернет-порталом «Культура.рф» для предоставления всем российским музеям возможности использовать дополненную реальность. В нем реализовано распознавание и QR-кодов, и самих экспонатов, причем также имеется возможность вручную ввести код представленного объекта. После распознавания объекта посетитель может увидеть на экране изображение экспоната, дополненное интерактивными метками, по нажатии на которые выводится информация о деталях объекта. Также есть возможность сравнить, как выглядел экспонат до и после реставрации.

Основные возможности приложения:

·Распознавание объектов искусства и представление детальной информации.

·Использование интерактивных меток для взаимодействия с пользователем.

·Показ ближайших к пользователю музеев и выставок.

Достоинства:

·Гибкие возможности по распознаванию экспоната: распознавание объекта, QR-коды, код экспоната.

·Визуальное представление объекта во время реставрации.

·Возможность использования приложения для распознавания выставленных объектов вне музея.

Недостатки:

·Ограниченное распознавание объекта без интернета (только для нескольких выставок).

·Ограниченная возможность получения информации об экспонате без интернета.

·Отсутствие подробной текстовой информации об объектах.

Проект «CHESS» [12] (аббр. от «Cultural Heritage Experiences through Socio-personal interactions and Storytelling», рус. «Преподавание культурного наследия посредством социо-персональных взаимодействий и повествования») - крупный проект, который призван объединить в себе информацию об экспонатах целого ряда европейских музеев. Он стартовал в 2011 году, и его разработка еще ведется. Приложение уже было успешно протестировано в нескольких музеях.

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

Основные возможности приложения:

·Интерактивная дополненная реальность.

·Формирование персональных рекомендаций на основе интересов пользователя.

·Получение знаний в ходе выполнения заданий интерактивных игр внутри приложения.

·Возможность пересмотреть маршрут своего визита в музей позднее в интернете.

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

Достоинства:

·Развитая интерактивность.

·Персонализация.

·Автоматическая генерация маршрутов по музею.

Недостатки:

·Отсутствие приложения на рынке.

·Высокая стоимость разработки.

·Краткость предоставляемой информации.

·Отсутствие возможности использовать приложение вне музея.

Таблица 1. Сравнительный анализ аналогов

Музей Рубенса«Узнай Москву»«Artefact»«CHESS»Разрабатываемое приложениеПолнота представляемой информации++--+Наглядность представления информации+±+++Независимость от инфраструктуры-++++Оффлайн-распознавание экспонатов-+±±+Представление информации оффлайн-±±±+Отсутствие дополнительных загрузок основных данных+---+Наличие анонсов и другой обновляемой информации от музея----+Интеграция с социальными сервисами++-++Доступность приложения для пользователей+++-+

.4 Формирование требований к разрабатываемому приложению

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

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

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

)Распознавание объекта должно выполняться без необходимости доступа к интернету.

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

)Данные об экспонате должны быть доступны на устройстве оффлайн.

)Должен быть реализован интерфейс библиотеки экспонатов.

)Должен присутствовать интерфейс покупки дополнительных элементов.

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

)В приложении должна быть реализована интеграция с социальными сервисами.

2. Выбор методов разработки приложения

Все функции приложения можно реализовать с нуля или использовать уже существующие средства (сторонние SDK - software development kit, комплект средств разработки). Для эффективной разработки приложения было решено использовать существующие инструментарии, дополняя их функциональность и сочетая их со стандартными возможностями целевой платформы.

Для разработки мобильного приложения была выбрана платформа iOS как одна из лидирующих на мировом рынке операционных систем для смартфонов и планшетов (33.39% рынка по результатам на март 2017 года [13]).

По данным официальной статистики компании Apple за 20 февраля 2017 года [14], 79% устройств в мире работают под управлением iOS 10, 16% - iOS 9, и лишь 5% отводится на более ранние версии. iOS 10 не поддерживается устройствами, выпущенными в 2012 году и ранее, и последняя версия системы, доступная для них, - 9.3.5. Таким образом, было принято решение разработать приложение для iOS 9 и новее.

Разработка приложений для системы iOS осуществляется в среде Xcode. Для написания кода могут использоваться два языка программирования - Objective-C и Swift. Swift является молодым языком программирования, но, будучи представленным лишь в 2014 году, он уже стремительно набирает популярность. В рамках одного проекта возможно использовать файлы кода, написанные на разных языках, что делает возможным использование в проекте сторонних Objective-C-библиотек.

Основными преимуществами Swift перед Objective-C являются [15]:

·Эффективное и безопасное управление памятью, благодаря которому программисту не нужно думать о памяти для каждого создаваемого объекта.

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

·Код, написанный на Swift, обладает высокой скоростью выполнения, находясь на одной позиции с C++.

·Наконец, Swift намного лаконичнее и удобнее в чтении, чем Objective-C.

Таким образом, было принято решение использовать язык программирования Swift 3.0 (наиболее актуальной версии).

.1 Обзор SDK для распознавания изображений

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

1)OpenCV;

)Vuforia SDK;

)Catchoom On-Device Image Recognition SDK;

)ARToolkit.

OpenCV [16] - библиотека с открытым исходным кодом, содержащая инструменты для нужд компьютерного зрения и обработки изображений. Библиотека является кроссплатформенной (существуют реализации для Windows, Mac OS, Linux, Android и iOS), реализована на четырех языках программирования: (C++, C, Python и Java) и распространяется под лицензией BSD.

В OpenCV реализовано много эффективных алгоритмов для работы с изображениями. Среди них стоит выделить алгоритм определения максимально стабильных областей экстремума (англ. maximally stable extremal regions, MSER). MSER определяет наборы смежных пикселей, у которых интенсивность пикселей внешней границы выше (по заданному порогу), чем интенсивность пикселей внутренней границы [17]. Алгоритм устойчив к размытию и масштабу изображения, а также имеет довольно низкую сложность относительно других алгоритмов обнаружения характерных пятен - , где n - число пикселей на изображении.

Необходимо заметить, что OpenCV не имеет специальной реализации для iOS, и единственная реализация библиотеки, доступная для использования - это версия для C++. В то же время, Swift-проекты не имеют базовой поддержки кода C++. Это означает, что для использования библиотеки в проекте необходимо создать «оборачивающий» класс Objective-C с интерфейсом, вызывающим методы из библиотеки, и добавить его в Swift-проект. Таким образом, из Swift-кода вызывается метод вспомогательного класса Objective-C, который, в свою очередь, запускает реализацию метода из библиотеки. Такая длинная цепочка вызова не является эффективным решением, так как замедляет быстродействие приложения.

Vuforia SDK [18] - набор инструментов для разработки приложений с элементами дополненной реальности. Vuforia также является кроссплатформенной, имея интерфейсы на языках C++, Objective-C, Java, а также. Net (через интеграцию с игровым движком Unity). Библиотека является полностью бесплатной для разработчиков и требует единоразового приобретения в случае использования проекта в коммерческих целях.

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

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

Catchoom On-Device Image Recognition SDK [19].

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

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

Как сообщают разработчики [19], система локального распознавания изображений отличается скоростью, 98% точностью и устойчивостью. Коллекция изображений для распознавания создается в профиле разработчика на сайте. Предполагается, что такая коллекция добавляется в приложение, SDK инициализируется с помощью нее, и затем распознавание происходит полностью на устройстве.

ARToolkit [20] - кроссплатформенный инструментарий, имеющий интерфейсы для Windows, Mac OS, Linux, Android и iOS. Одно из главных преимуществ этой библиотеки заключается в том, что она является программным обеспечением с открытым кодом, что означает отсутствие любой платы за ее использование.

В ARToolkit SDK есть инструмент Natural Feature Tracking (NFT, рус. отслеживание главных деталей), которым можно воспользоваться для распознавания маркеров-изображений. Однако в документации подчеркивается [21], что для распознавания изображения (текстурированной поверхности в терминах NFT) необходимо, чтобы поверхность была известна системе заранее. Это означает, что система должна быть заранее обучена распознаванию данного изображения, т.е. для него должен быть сформирован набор данных, который может быть использован для распознавания и трекинга во время выполнения. Обучение состоит из нескольких шагов:

)Выбор разрешений набора изображений.

)Генерация набора данных NFT из изображения.

)Тестирование набора данных.

Дополнительная сложность процесса заключается в том, что формирование набора данных должно быть выполнено для каждого изображения вручную из командной строки в системах Windows, Mac OS или Linux. Таким образом, для получения данных, готовых для использования в ARToolkit SDK, необходимо выполнить ряд дополнительных действий.

Таблица 2. Выбор инструментария для распознавания изображений

OpenCVVuforiaCatchoomARToolkitКроссплатформенность++++Простота импорта в проект-+++Простота подготовки изображений для распознавания++±-Простота использования-++±Наличие подробной документации+±±+Возможность использования одного инструмента без установки всего SDK--+-Плата за использование-Для разработчиков - бесплатно, Для коммерческого использования - единоразовая плата $499Для разработчиков - бесплатно, Для коммерческого использования - 99 €/мес (100 изобр.) или 249 €/мес (1000 изобр.)-

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

.2 Обзор SDK для парсинга HTML

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

Поскольку базовые инструменты языков разработки для iOS не позволяют осуществлять парсинг HTML-кода, возникает необходимость использования сторонних SDK. Для сравнительного анализа были выбраны следующие инструментарии:

1)Hpple;

2)Kanna;

3)Objective-C-HTML-Parser.

Hpple [22] является надстройкой над библиотекой XPathQuery, которая осуществляет синтаксический анализ кода HTML. Инструментарий работает с элементами, находя их по абсолютному пути XPath (от внешних тегов к вложенным). SDK отличается возможностью удобного получения доступа к тегам по XPath, а также лаконичным интерфейсом. Тем не менее, функционал SDK не содержит методов для поиска тегов по другим критериям (например, имя класса).

Kanna [23] также основана на поиске тегов по XPath, но, помимо этого, имеет функционал для поиска по тегам CSS. Инструментарий имеет поддержку современного стандарта CSS3. SDK реализован на языке программирования Swift и имеет интерфейсы для нескольких платформ: macOS, iOS, tvOS, watchOS и Linux. Помимо этого, SDK имеет функционал для парсинга XML. Главным недостатком этого инструментария является сложность импорта в проект, что обусловлено необходимостью включения большого количества файлов и связывания их со стандартными модулями и библиотеками.

Objective-C-HTML-Parser [24] - парсер HTML, обладающий широким функционалом и удобным интерфейсом для поиска тегов в коде и работы с ними. Наиболее заметным преимуществом этого SDK является возможность поиска тегов не по XPath, а по их атрибутам (например, можно с помощью вызова одного метода найти все теги определенного класса). Кроме того, этот инструментарий состоит лишь из нескольких файлов кода, для исполнения которых необходима лишь одна стандартная библиотека.

Таблица 3 Выбор инструментария для парсинга HTML

HppleKannaObjetive-C-HTML-ParserЯзык интерфейсаObjective-CSwiftObjective-CПростота импорта в проект+-+Широкий функционал-±+Полный размер библиотеки (с дополнительными зависимостями)227.9 кб343.2 кб160.9 кбЛицензияMITMITСтандартная лицензия GitHubДокументация и примерыМногоСреднеСредне

Таким образом, для синтаксического анализа HTML-кода страниц с новостями музея был выбран инструментарий Objective-C-HTML-Parser в силу наибольшей простоты использования, импорта в проект и малого размера.

3. Моделирование приложения с элементами дополненной реальности для музея

Факт причастности проекта к фотографической тематике добавляет некоторые особенности к его реализации:

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

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

.1 Общая структура приложения

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

)Распознавание;

)События;

)Библиотека;

)Дополнительно.

В разделе «Распознавание» представляются кадры с камеры устройства, которые получаются и обрабатываются в реальном времени. В случае, если на очередном кадре был обнаружен и идентифицирован экспонат, появляется всплывающее окно с информацией о нем. При этом данные представляются вместе с изображением экспоната, что способствует лучшему восприятию получаемой информации. Помимо этого, в этом окне пользователь может поделиться этими сведениями в социальных сервисах (Twitter, Facebook, ВКонтакте) или в простом сообщении, а также приобрести дополнительный контент.

Для распознавания экспонатов был выбран инструментарий Vuforia SDK. Для инициализации библиотеки необходим уникальный ключ приложения и база данных изображений-маркеров. Эти элементы можно получить в личном кабинете на веб-сайте developer.vuforia.com. При этом важной деталью является то, что впоследствии изображение можно идентифицировать только по имени файла, который был добавлен в библиотеку. Это означает необходимость введения однозначного соответствия между именами изображений-маркеров и информацией о них.

Было принято решение содержать информацию об экспонатах в файле.plist (XML Property List, Список Свойств) [25]. Такой файл представляет собой XML-разметку, в корне которой содержится сериализованный объект (массив или словарь). Благодаря этому, Property List обладает возможностью прямого доступа к элементам, в отличие от простых текстовых файлов (например.txt). Эти файлы широко используются в iOS для хранения данных и пользовательских настроек. Для разрабатываемого приложения был сформирован файл DBdata.plist, в корне которого содержится словарь, ключами которого являются имена изображений-маркеров, а значениями - строки с информацией о них.

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

Раздел «События» представляет собой новостную ленту музея. Здесь реализована прокручиваемая таблица с одним столбцом, в каждой клетке которой содержится краткая информация об определенном событии: заголовок, начало основного текста и изображение (если есть). По нажатии на ячейку показывается новое окно с полным содержанием новости, в котором пользователь может поделиться ей с помощью социальных сервисов или сообщения.

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

·«title» - название события;

·«abstract» - аннотация или начало текста о событии;

·«imLink» - ссылка на изображение, связанное с событием (если его нет, значение для этого ключа будет пустой строкой «»);

·«moreLink» - ссылка на страницу с полным текстом о событии.

Значения для всех ключей словаря являются строками.

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

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

В разделе «Дополнительно» пользователь может удалить все сохраненные данные (например, о событиях) и получить общую информацию о музее и приложении.

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

·«photographerInfo» - HTML-код страницы с информацией о С.В. Челнокове;

·«fundNumber» - номер телефона представителя Фонда;

·«fundEmail» - email-адрес представителя Фонда;

·«devEmail» - email-адрес разработчика.

Таким образом, можно выделить ключевые элементы приложения:

·Раздел «Распознавание».

·База данных маркеров для Vuforia SDK.

·Набор изображений экспонатов.

·Файл с информацией об экспонатах.

·Раздел «Библиотека».

·Раздел «События».

·Веб-сайт музея.

·Файл с информацией о событиях.

·Изображения событий.

·Раздел «Дополнительно».

·Файл с информацией о музее и приложении.

Диаграмма связей этих элементов представлена на рисунке 1.

Рис. 1. Логическая схема приложения

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

.2 Разработка пользовательского интерфейса приложения

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

Рис. 2. Схема шаблона MVC

В iOS-разработке контролеры могут являться контейнерами для объектов пользовательского интерфейса или определять навигацию в приложении. Для каждого вида существует свой базовый класс (например, для простого View Controller - UIViewController, где UI - User Interface, Пользовательский Интерфейс). Контроллеры, включающие в своем названии «View», имеют представление (объект класса UIView), на которое можно добавлять другие объекты пользовательского интерфейса (кнопки, надписи, таблицы и т.д.).

Также существует несколько контроллеров, создающих визуальный интерфейс для навигации определенного стиля в приложении. Например, Navigation Controller определяет последовательную навигацию между несколькими View Controllerами с сохранением характерной полосы навигации сверху.

Поскольку в разрабатываемом приложении предполагается реализовать четыре раздела, независимых друг от друга, для их совмещения был выбран Tab Bar Controller. Тогда глобальный интерфейс приложения представляет собой четыре вкладки, переключаться между которыми можно на полосе внизу экрана. При этом каждая вкладка является обособленным контроллером с собственными объектами интерфейса, события которых обрабатываются только им самим.

Очевидно, что в разделах «Библиотека» и «События» должна быть реализована навигация от таблицы с элементами к View Controller с дополнительной информацией и обратно. Для этого в этих вкладках используется Navigation Controller, в котором начальным контроллером является Table View Controller (используется для представления таблиц) и предусмотрен переход на другой View Controller по нажатии на клетку.

Аналогично, в разделе «Дополнительно» также реализуется Navigation Controller, но в качестве начального контроллера используется простой View Controller.

Для раздела «Распознавание» используется простой View Controller с реализацией метода, отображающего всплывающий снизу другой View Controller.

Базовая структура приложения и возможные переходы между контроллерами представлены на рисунке 3.

Рис. 3. Иерархия контроллеров приложения

Еще одной важной составляющей iOS-разработки, имеющей отношение к управлению пользовательским интерфейсом, является делегирование. С помощью этого механизма один объект назначается обработчиком событий другого и действует «от его лица» или в координации с ним [27]. Например, делегирование используется в реализации класса-наследника от базового класса UITableViewController (View Controller для отображения таблиц). В визуальном представлении этого контроллера содержится таблица (объект класса UITableView), которая требует реализации методов, определяющих ее структуру и поведение (количество строк, высота ячейки, событие при выборе ячейки и т.д.). В этом случае класс Table View Controllerа назначается делегатом этой таблицы, и в его коде должны присутствовать упомянутые методы.

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

Тем не менее, оперировать с распознаванием возможно лишь из соответствующего View Controllerа. Значит, возникает необходимость уведомления контроллера об этих событиях. Для этого предполагается использовать интерфейс регистрации событий приложения (класс NSNotificationCenter). NSNotificationCenter предоставляет интерфейс для передачи информации внутри приложения. С помощью этого класса, возможно назначить обработчик события со строковым идентификатором в методе одного класса, а затем в методе другого - явно вызвать это событие. В то же время, идентификатор может быть выражен уже определенной константой языка, как, например, в случае сворачивания (UIApplicationWillResignActiveNotification) и повторного открытия (UIApplicationDidBecomeActiveNotification) приложения. Также важно заметить, что эти события вызываются неявно.

Префикс «NS» в названии стандартных классов iOS - наследие операционной системы NeXTSTEP, приобретенной компанией Apple в 1997 году и использованной в качестве основы для Mac OS X [28].

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

4. Разработка и тестирование приложения

.1 Подготовка данных

Как было сказано, инструментарий для распознавания изображений Vuforia SDK должен быть инициализирован уникальным ключом приложения и базой данных изображений-маркеров. Для этого на веб-сайте developer.vuforia.com был создан аккаунт, в котором было добавлено новое приложение и создана новая база данных изображений. В качестве набора данных был использован ряд фотографий, предоставленных Фондом сохранения фотонаследия C.В. Челнокова. В проект была добавлена созданная база данных и папка с исходными изображениями.

Для всех фотографий доступна следующая информация:

·Запечатленное событие.

·Место съемки.

·Год съемки.

Эти данные хранятся в файле DBData.plist (Приложение 2). Его корень - это словарь, ключи которого - названия файлов изображений, а значения - словари со строковыми значениями для соответствующих ключей:

·«title»;

·«place»;

·«year»;

·«portionID».

Помимо значений с информацией о фотографиях в словаре присутствует текстовое значение для ключа «portionID». В этом значении записан идентификатор набора стереопар, к которому принадлежит данное изображение. Для доступных по умолчанию фотографий значение этого ключа «basic». При покупке некоторого пакета стереопар с идентификатором <ID> все фотографии, имеющие это значение для ключа «portionID», становятся доступными для просмотра.

Для создания платного пакета стереопар были выбраны 10 фотографий по критерию более высокой сложности реставрации и оцифровки. Для всех этих изображений в значение для ключа «portionID» была записана строка «photopack1».

.2 Реализация раздела «Распознавание»

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

·RecognitionViewController (Приложения 3, 4). Является контроллером во вкладке «Распознавание» Tab Bar Controllerа.

·RecognitionEAGLView (Приложения 5, 6). Отвечает за представление кадров, полученных с камеры, на экране устройства и поиск маркеров на них.

·RecognitionSession (Приложения 7, 8). Служит для инициализации Vuforia SDK и его настройки.

Инициализация

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

Рис. 4. Последовательность инициализации процесса распознавания

Инициализация начинается после загрузки RecogitionViewController. Сначала создается объект класса RecognitionSession, который на данном этапе определяет параметры устройства (разрешение экрана, наличие доступа к камере и т.д.). Затем, в соответствии с этими параметрами, инициализируется объект RecognitionEAGLView. Этот этап включает в себя настройку инструментов для анализа и представления изображений.

Vuforia использует для рендеринга (формирования изображения) библиотеку OpenGL ES 2.0 (Open Graphics Library for Enterprise Systems, графическая библиотека для встраиваемых систем). Эта спецификация предлагает программный интерфейс для создания приложений, использующих компьютерную 2D- и 3D-графику, для мобильных устройств и игровых консолей [29]. В этап инициализации RecognitionGLESView входит создание представления с контекстом OpenGL для вывода изображений, подготовка к рендерингу кадров и инициализация шейдеров, обрабатывающих кадры. Шейдер - программа для процессоров видеокарты, которая предназначена для определения параметров изображений и их модификации (например, добавления эффектов освещения или наложения текстур) [30]. Vuforia предполагает использование стандартных шейдеров, предоставляемых вместе с SDK, или пользовательских (для добавления собственных трехмерных объектов на изображение). Поскольку в разрабатываемом приложении не предусмотрен показ 3D-моделей, было принято решение использовать стандартные шейдеры.

Следующий этап - непосредственная инициализация Vuforia SDK. Для этого с помощью следующего метода происходит связывание SDK с 380-значным ключом приложения, полученным ранее на сайте:

Vuforia:setInitParameters (mVuforiaInitFlags, «<ключ приложения>»);

После этого предпринимается попытка инициализации SDK с помощью метода init(), который возвращает целочисленное значение:

int initSuccess = 0;{= Vuforia:init();

} while (0 <= initSuccess && initSuccess < 100);

Переменная initSuccess может принимать следующие значения:

·(0, 100) - процесс инициализации еще не закончен.

·100 - инструментарий успешно инициализирован.

·-3 (INIT_NO_CAMERA_ACCESS) - пользователь не разрешил приложению использовать камеру устройства. На устройствах под управлением системы iOS 8 и новее любое приложение, пытающееся получить доступ к другим базовым приложениям (камера, библиотека фото, контакты и т.д.) явным образом запрашивает у пользователя разрешения на это.

·-4 (INIT_LICENSE_ERROR_MISSING_KEY) - отсутствует ключ приложения.

·-5 (INIT_LICENSE_ERROR_INVALID_KEY) - введенный ключ приложения недействителен.

·-8 (INIT_LICENSE_ERROR_CANCELED_KEY) - введенный ключ был аннулирован.

·-9 (INIT_LICENSE_ERROR_PRODUCT_TYPE_MISMATCH) - несовпадение целевого типа устройства, связанного с ключом приложения, и типа используемого устройства.

·-1 (INIT_ERROR) - в случаях других ошибок.

На следующем этапе происходит инициализация механизма распознавания и отслеживания маркеров:

Vuforia: TrackerManager& trackerManager = Vuforia: TrackerManager:getInstance();.initTracker (Vuforia: ObjectTracker:getClassType());

Наконец, на последнем шаге происходит загрузка базы данных маркеров и ее активация:

chelnokovSet = [self loadObjectTrackerDataSet: @ «ChelnokovPhotosDB.xml»];: ObjectTracker* objectTracker = static_cast<Vuforia: ObjectTracker*>(trackerManager.getTracker (Vuforia: ObjectTracker:getClassType()));>activateDataSet(chelnokovSet);

Идентификация маркеров

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

(void) renderFrameWithState: (const Vuforia: State&) state projectMatrix: (Vuforia: Matrix44F&) projectionMatrix

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

if (state.getNumTrackableResults()!= 0) {.definedPhotoID = [NSStringString: state.getTrackableResult(0)->().getName()];

[[NSNotificationCenter defaultCenter] postNotificationName:

@ «showDetailsEvent» object: nil];

}

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

Однако переход к новому контроллеру может быть осуществлен лишь из другого контроллера, но обнаружение маркеров происходит в классе представления (RecognitionEAGLView). Таким образом, необходимо уведомить RecognitionViewController о необходимости перехода, для чего в данном случае используется описанный ранее класс NSNotificationCenter. При создании контроллера вызывается метод addObserver, который назначает метод, исполняемый при регистрации события с указанным идентификатором:

[[NSNotificationCenter defaultCenter] addObserver: self selector: @selector(showPhotoDetailsViewController) name: @ «showDetailsEvent» object:];

В назначенном методе происходит заранее определенный переход с параметром - идентификатором изображения:

- (void) showPhotoDetailsViewController {

}

Этот идентификатор необходимо передать в DetailViewController, в котором должна быть представлена информация об экспонате. Это выполняется с помощью неявно вызываемого метода prepareForSegue, функция которого заключается в подготовке целевого View Controller к показу:

- (void) prepareForSegue: (UIStoryboardSegue *) segue sender: (id) sender {([[segue identifier] isEqualToString: @ «showPhotoDetailsSegue»]) {*photoId = (NSString*) sender;* dVC = (DetailViewController*) [segue];.definedPhotoID = photoId;

}

}

В случае перехода с идентификатором showPhotoDetailsSegue переданный в метод параметр преобразуется к строковому типу и записывается в поле definedPhotoID класса целевого контроллера. После этого управление переходит к классу DetailViewController и его методам.

Представление информации об экспонате

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

В классе DetailViewController реализован метод displayPhotoInfo, который получает из файла DBData.plist информацию для экспоната, идентификатор которого записан в поле definedPhotoID. Этот метод вызывается при инициализации контроллера. Важно, что изображения маркеров представляют собой стереопары. Это означает, что при выводе фотографии в представлении контроллера ее необходимо разделить на две части (для определенности на экран выводится левая половина).

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

При нажатии на кнопку «Дополнительно» происходит показ дополнительного контента после проверки покупки. В случае, если контент еще не приобретен, выдается уведомление с предложением покупки. Важно отметить, что при простом добавлении на представление контейнера для изображения сохраняется строка с системными символами вверху. В версиях iOS 9 и выше наличие или отсутствие этой строки определяется для всего приложения или для представления каждого контроллера в отдельности, откуда получается, что скрыть ее при показе стереопары в текущем контроллере невозможно. Для сохранения единого стиля в приложении было принято решение создать новый класс StereopairViewController (Приложение 10), в который при переходе передается идентификатор изображения. Для представления этого класса определяется, что строка состояния отсутствует.

Визуальный интерфейс

Далее представлен визуальный интерфейс раздела «Распознавание» на примере изображений из базы данных:

Рис. 5. Пользовательский интерфейс класса RecognitionViewController (а), класса DetailViewController (б), связи с социальными сервисами (в), подтверждения покупки пакета стереопар (г), класса StereopairViewController (д)

Интерфейс 5в появляется по нажатии на кнопку «Поделиться» на интерфейсе 5б справа вверху; 5г - по нажатии на кнопку «Еще» на 5б, если стереопара еще не доступна, иначе появляется интерфейс 5д. Последний можно скрыть, нажав на изображение.

.3 Реализация раздела «События»

Как было сказано ранее, новости и события музея должны выгружаться с его веб-сайта. Для этого необходимо анализировать его HTML-страницы и находить нужные элементы. Для парсинга HTML был выбран инструментарий Objective-C-HTML-Parser, и на основе его методов был создан вспомогательный класс HTMLWrapper (Приложение 11). Его интерфейс содержит два статических метода:

+ (NSArray*) getEvents;

+ (NSString*) getEventContents: (NSString*) url;

Загрузка общих данных о событиях

Первый метод загружает данные из раздела «События» веб-сайта chelnokov.org. События на сайте размещены на нескольких страницах по четыре на одной. Информация о каждом событии заключена в тег DIV с классом «post-item». Этот тег имеет сложную вложенную структуру, но, благодаря возможности инструментария искать теги по названию класса, исключается необходимость последовательного спуска к ним. Таким образом, было установлено, что необходимую информацию о событии можно получить из следующих тегов:

·DIV (Блок) с классом «image_wrapper». Этот тег содержит в себе вложенную ссылку (тег A), в которую, в свою очередь, вложено изображение (тег IMG). Обращаясь к атрибуту «src» этого тега, можно получить ссылку на исходное изображение. Если у события нет прикрепленного изображения, тег A отсутствует.

·H2 (Заголовок второго уровня) с классом «entry-title». В этот тег вложена ссылка (тег A), из атрибута «href» которой получается прямая ссылка на полный текст о событии. Кроме того, между открывающим и закрывающим тегами этой ссылки заключен заголовок события, который можно получить с помощью метода contents класса HTMLNode инструментария.

·DIV с классом «post-excerpt». В рамках этого тега заключено начало статьи, которое можно получить с помощью метода contents.

Метод getEvents проходит по страницам событий, получая описанным образом информацию о них. В результате, метод возвращает массив словарей с ключами «title», «abstract», «imLink» и «moreLink». Этот массив используется для заполнения данных в таблице контроллера NewsTableViewController (Приложение 12), а также записывается в файл events.plist в локальной директории приложения.

Ячейки таблицы

Контроллер реализует методы для таблицы, определяя ее структуру и переходы. Содержание ячеек задается в методе:tableView (_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell

В параметре indexPath содержатся координаты (индекс) ячейки. Метод возвращает инициализированный объект класса клетки UITableViewCell или его наследника. Для клеток таблицы событий используются объекты созданного класса NewsTableViewCell, пользовательский интерфейс которого показан на рисунке 6.

Рис. 6. Визуальный интерфейс класса NewsTableViewCell

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

func tableView (_ tableView: UITableView, didSelectRowAt indexPath: IndexPath)

В коде этого метода осуществляется переход к контроллеру, отображающему полное содержание новости:

self.performSegue (withIdentifier: «SHOW_NEWS_SEGUE», sender: m_Events [indexPath.row])

В описанном ранее методе prepareForSegue получается целевой контроллер класса DetailNewsViewController, и в его поле link записывается ссылка на статью.

Отображение полного содержания

За показ полного текста события отвечает класс DetailNewsViewController (Приложение 13). Его визуальным представлением является интерфейс для просмотра веб-страниц класса UIWebView. Также пользователь может поделиться новостью в социальных сетях, воспользовавшись кнопкой в правом верхнем углу экрана.

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

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

Поскольку объект класса UIWebView способен отображать не только Интернет-страницы, но и части HTML-кода, записанные в строковой переменной, было принято решение отображать в UIWebView только разметку, содержащую текст события. Для этого в классе HTMLWrapper был реализован второй метод (getEventContents), который принимает на вход URL страницы события и возвращает строку, в которой записана разметка с его содержанием.

Было установлено, что основное содержание статьи заключено в двух тегах:

·DIV с классом «section-post-header». Здесь размещаются заголовок статьи и изображение (если есть).

·DIV с классом «post-wrapper-content». В нем содержится основной текст статьи.

Разметки этих тегов совмещаются вместе в одну строковую переменную.

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

·При выводе в UIWebView вверху страницы появляется надпись «$0», которой нет при просмотре полной версии сайта. Было установлено, что такую надпись дает тег DIV с классом «button-love». С помощью инструментария был получен HTML-код этого тега, и он был заменен в общей разметке новости на пустую строку «».

·Внизу страницы остается надпись: «Поделиться в соцсетях». Она была заменена на пустую строку «» в общей разметке.

·После извлечения тегов события, их текстовое содержание остается адаптированным для экрана мобильного устройства, но изображения оказываются значительно растянутыми горизонтально. Это было решено путем присвоения им стилей CSS: во всей строке разметки была произведена замена '<img' на '<img style=» max-width: 100%; height: auto» '. Благодаря этому, изображения принимают максимально возможную ширину (т.е. ширину экрана), и при этом масштабируются, а не растягиваются лишь в одном направлении.

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

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

Визуальный интерфейс

Рис. 7. Пользовательский интерфейс класса NewsTableViewController (а), класса DetailNewsViewController (б), связи с социальными сервисами (в)

Интерфейс 7в появляется по нажатии на кнопку «Поделиться» на интерфейсе 7б справа вверху.

.4 Реализация раздела «Библиотека»

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

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

let key = (DBData.allKeys as NSArray) [indexPath.row] as! String

Здесь DBData - словарь, считанный из файла, indexPath.row - индекс ячейки. После определения ключа можно получить словарь параметров фотографии:

let val = DBData.value (forKey: key) as! NSDictionary

Рис. 8. Интерфейс класса LibraryTableViewCell

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

Рис. 9. Интерфейс класса LibraryTableViewController

Объект класса ячейки имеет поле photoID, в которое записывается идентификатор фотографии, представленной в данной ячейке. Благодаря этому, можно определить выбранное изображение без дополнительных операций, что актуально при передаче данных в DetailViewController, представляющий данные о фотографиях. Для вывода информации об экспонатах здесь используется такой же контроллер, как и в разделе «Распознавание». Единственное отличие заключается в том, что здесь используется переход с другим идентификатором, так как визуальное переключение представлений должно выглядеть иначе.

Таким образом, пользовательский интерфейс раздела «Библиотека» представлен на рисунке 9. При выборе ячейки отображается DetailViewController, интерфейс которого идентичен интерфейсам на рисунках 5а-5д.

4.5 Реализация раздела «Дополнительно»

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

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

При нажатии на кнопку «О фотографе» происходит переход к новому контроллеру с классом MuseumInfoViewController (Приложение 16). Его представление состоит из WebView, в котором отображается HTML-разметка раздела «О фотографе» веб-сайта Фонда. В частности, для вывода выбрано содержание тега DIV с классом «the_content_wrapper», которое содержит несколько абзацев текста и два изображения. Так как предполагается, что эта информация должна быть доступна оффлайн, было выполнено следующее:

·Изображения были сохранены в локальную директорию приложения.

·Адреса файлов изображений, записанные в атрибуте «src» тегов IMG, были заменены на адреса в локальной директории.

·Для верного отображения изображений к тегам IMG были добавлены стили CSS, как описано в пункте 4.3.3.

По нажатии на кнопку «Сайт Фонда» происходит перенаправление запроса и открытие веб-сайта в стандартном браузере устройства.

Наконец, при выборе опции «О приложении» происходит переход на View Controller с общей информацией о приложении (Приложение 17). Здесь пользователь может связаться с представителем Фонда: по нажатии на соответствующую кнопку появляется интерфейс, позволяющий осуществить звонок или написать email. Аналогично этому, реализована возможность связаться по email с разработчиком.

Таким образом, пользовательский интерфейс раздела имеет вид:

Рис. 10. Визуальный интерфейс класса AdditionalViewController (а), уведомления об успешном удалении загруженных из интернета данных (б), класса MuseumInfoViewController (в), класса AppInfoViewController (г), связи с представителем Фонда разными способами

Интерфейсы 10б, 10в, 10г появляются по нажатии на соответствующие кнопки на 10а; 10д можно вызвать по нажатии на кнопку «Связь с Фондом» на интерфейсе 10г.

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

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

Рис. 11. Пользовательский сценарий приложения

Тестирование приложения проводилось на устройстве iPhone 6S под управлением iOS 10.3.2. Тестовая выборка изображений состояла из 47 стереопар. Для каждого изображения из выборки было проведено по 5 замеров времени с момента появления маркера в кадре до момента появления информации о нем. Результат, усредненный по всем замерам, составил 0.96 секунды. Также было замечено, что для идентификации всех изображений достаточно, чтобы в поле зрения камеры находилась только половина изображения. Случаев неверного распознавания выявлено не было.

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

Заключение

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

Анализ предметной области позволил дать оценку подходам к распознаванию экспонатов (раздел 1.2) и сформулировать требования к разрабатываемому приложению (раздел 1.4). Был сделан вывод о том, что распознавание экспоната с камеры устройства является наиболее естественным и эффективным для пользователя способом взаимодействия.

Обзор и сравнительный анализ методов разработки приложения позволили сделать вывод о том, инструментарий Vuforia SDK является наиболее эффективным средством для реализации функционала распознавания изображений (раздел 2.1). Для парсинга HTML-кода веб-страниц был выбран инструментарий Objective-C-HTML-Parser (раздел 2.2).

В результате теоретической части работы была сформирована общая структура приложения, определен функционал разных его частей и порядок хранения данных (раздел 3.1). Также были рассмотрены особенности создания пользовательского интерфейса приложения в ОС iOS 9 или новее.

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

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

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

Предполагается дальнейшее применение приложения на выставках фоторабот С.В. Челнокова. Ожидается, что база распознаваемых изображений будет пополнена и приложение будет размещено в Apple App Store (магазине приложений Apple).

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

1. Number of smartphone users worldwide 2014-2020 | Statista. URL: https://www.statista.com/statistics/330695/number-of-smartphone-users-worldwide/ (дата обращения: 18. 04. 2017).

. He Z. и др. A proposal of interaction system between visitor and collection in museum hall by iBeacon // 2015 10th International Conference on Computer Science & Education (ICCSE). 2015.

. Jevremovic V., Petrovski S. MUZZEUM - Augmented Reality and QR codes enabled mobile platform with digital library, used to Guerrilla open the National Museum of Serbia // 2012 18th International Conference on Virtual Systems and Multimedia. 2012.

. О фотографе - Сайт фонда Челнокова. URL: https://chelnokov.org/o-fotografe/ (дата обращения: 08. 05. 2017).

. Chen B. If Youre Not Seeing Data, Youre Not Seeing // Wired. 2009.

. Azuma R. A Survey of Augmented Reality // Presence: Teleoperators and Virtual Environments. 1997. Т. 4. С. 355-385.

. Zhou F., Duh H., Billinghurst M. Trends in augmented reality tracking, interaction and display: A review of ten years of ISMAR // ISMAR '08 Proceedings of the 7th IEEE/ACM International Symposium on Mixed and Augmented Reality. 2008. С. 193-202.

. Damala A. и др. Bridging the gap between the digital and the physical // Proceedings of the 3rd international conference on Digital Interactive Media in Entertainment and Arts - DIMEA '08. 2008. С. 120-127.

. Навигация в помещениях с iBeacon и ИНС. URL: https://habrahabr.ru/post/245325 (дата обращения: 18. 04. 2017).

. Jevremovic V., Petrovski S. MUZZEUM - Augmented Reality and QR codes enabled mobile platform with digital library, used to Guerrilla open the National Museum of Serbia // 2012 18th International Conference on Virtual Systems and Multimedia. 2012.

. Chang K. и др. Development and behavioral pattern analysis of a mobile guide system with augmented reality for painting appreciation instruction in an art museum // Computers & Education. 2014. Т. 71. С. 185-197.

. CHESS - Project. URL: #"justify">Приложения

Приложение 1

Содержимое файла generalInfo.plist

Приложение 2

Примеры элементов словаря в файле DBData.plist

Приложение 3

Файл RecognitionViewController.h

Приложение 4

Файл RecognitionViewController.mm

Приложение 5

Файл RecognitionEAGLView.h

Приложение 6

Файл RecognitionEAGLView.mm

Приложение 7

Файл RecognitionSession.h

Приложение 8

Файл RecognitionSession.mm

Приложение 9

Файл DetailViewController.swift