Всем привет! Меня зовут Илья, и я разработчик ПО в области автоматизации документооборота в компании «Диджитал Дизайн». Так получилось, что изначально я iOS-разработчик, но по воле случая мне удалось поучаствовать в создании мобильного приложения — клиента СДУ «Приоритет» (далее — СЭД, система электронного документооборота) для устройств под управлением мобильной ОС «Аврора». И сейчас, когда первая версия приложения готова, а сам проект находится на этапе внедрения, я бы хотел поделиться полученным опытом и рассказать про особенности разработки под ОС «Аврора» и трудности, с которыми нам пришлось столкнуться в процессе.

Кратко о проекте

Дано:

  • существующий мобильный клиент СЭД под iOS и его бэкенд (веб-сервис, который выступает в качестве интерфейса для взаимодействия с сервером приложений СЭД);

  • сжатые сроки (~5 месяцев).

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

Цель, которую мы преследовали при выполнении задачи — проект нужно писать с ориентацией на кросс-платформенность, т.к. все больше заказчиков начинают проявлять интерес к портированию знакомого мобильного клиента СЭД для iOS на другие платформы (в частности, на ОС Android, а кто-то даже на мобильную Astra Linux).

Из особенностей и возможностей мобильного клиента СЭД можно выделить:

  • доступ в офлайн-режиме к документам СЭД, назначенным пользователю;

  • офлайн-просмотр файлов локальных документов самых распространённых форматов: pdf, офисных форматов (doc, docx, xls, xlsx), форматов графических изображений;

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

  • подписание файлов документов личным сертификатом электронной подписи по ГОСТ 34.10-2012.

Проведя небольшое исследование технологий для кросс-платформенной разработки мобильных решений, которые бы позволяли реализовать приложение под ОС «Аврора», мы решили остановиться на фреймворке Qt (C++, QML).

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

Средства разработки под ОС «Аврора»

Разработчик операционной системы ОМП («Открытая Мобильная Платформа») предоставляет партнёрам-разработчикам набор средств и компонентов для создания мобильных приложений под ОС «Аврора» — Аврора SDK, в состав которого входят:

  • Aurora IDE (IDE) — интегрированная среда разработки, основанная на Qt Creator, для написания приложений на языках С, С++ и QML для ОС «Аврора» с использованием компонентов Sailfish Silica. IDE предоставляет продвинутый редактор кода с интеграцией системы контроля версий, управления проектами и сборками;

  • Aurora OS Emulator (эмулятор) — виртуальная машина, которая позволяет выполнять приложения в окружении ОС «Аврора» аналогично работе на физических мобильных устройствах;

  • Aurora OS Build Engine (среда сборки) — окружение, которое обеспечивает среду для сборки приложений, не зависящую от домашней операционной системы (ОС).

Также разработчикам предоставляются руководства и примеры приложений для ОС «Аврора» с открытым исходным кодом.

Архитектура проекта

За основу архитектуры взят шаблон программирования MVC (Model-View-Controller), где View — QML-компонент (в частности, Page), Controller — класс С++, который подключается в QML.

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

Для работы с базой используется стандартный класс Qt QSqlDatabase, а для более удобной работы с данными базы реализован Data Access Object (DAO). Из-за отсутствия ORM в Qt внутри классов происходят прямые SQL-запросы к базе данных.

Сам проект для удобства был разделен на модули:

  1. App — интерфейс и жизненный цикл приложения.

  2. Core —логика приложения на C++.

  3. Quazip — код для работы с архивами.

  4. Crypt — работа с криптографией (электронная подпись, ГОСТ-соединение, шифрование) методами криптографического провайдера КриптоПро.

UI

В Aurora SDK входит собственный модуль для разработки интерфейса на QML — Sailfish Silica, который включает в себя все необходимые компоненты.

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

Другая не менее важная для нас причина невозможности использования готовых UI-элементов, которые предоставляет Aurora SDK, — это привязка к платформе ОС «Аврора», что противоречит нашей цели по реализации кросс-платформенного решения.

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

Для отрисовки UI в самом фреймворке Qt есть два основных модуля с компонентами: Qt Quick Controls и обычный Qt Quick. Qt Quick Controls реализован на базе компонентов из QtQuick и предоставляет набор готовых UI-элементов управления, таких как Button, CheckBox, Label и многие другие. Благодаря ему можно было бы значительно ускорить разработку пользовательского интерфейса. Изначально планировалось брать компоненты из Qt Quick Controls. Но, как оказалось, при их применении приложение не проходит валидацию (в Aurora SDK не разрешено использовать данный модуль).

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

  • Text — компонент для создания текста;

  • Rectangle — создание фигуры (любых форм элементов интерфейса);

  • MouseArea — компонент, с помощью которого можно отслеживать нажатие пользователя;

  • Image — создание изображения;

  • ListView — формирование списка;

  • Item — создание кастомного компонента.

Самое интересное, что удалось сделать на компонентах Qt Quick, — это анимированные выпадающие списки и модальные/диалоговые окна для показа, например, сообщений пользователям.

Рисунок 1 — pop-up с подсказкой
Рисунок 2 — модальное окно
Рисунок 3 — диалоговое окно

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

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

Рисунок 4 — интерфейс главного экрана

Просмотр файлов внутри приложения

Для работы приложения в качестве мобильного клиента СЭД жизненно необходима возможность отображать все самые распространенные форматы файлов (от графических и обычных текстовых до pdf и офисных). Если с изображениями проблем не возникло, то с pdf-файлами и текстовыми/офисными форматами начались трудности.

PDF

Для отображения pdf-файлов существует библиотека AmberPDF, разработанная коллегами из ОМП, которая является оберткой над библиотекой PDFium и позволяет использовать ее в Qt. Но помимо отображения, нам было также необходимо реализовать возможность добавлять аннотации на pdf-файлы (перо, выделение, текстовые аннотации и наложение изображения).

Из «коробки» обертка предоставляла возможность использовать только графические аннотации (перо и выделение), а текстовые аннотации и наложение изображений не поддерживались. Поэтому было решено немного дописать AmberPDF в части этого функционала. Но после доработок обнаружилась новая загвоздка — пакет с доработанной библиотекой AmberPDF не проходит валидацию. Для решения этой проблемы потребовалось передать правки по AmberPDF коллегам из ОМП для согласования и включения в репозиторий и, как следствие, локальное внедрение в сборочное окружение подписанных библиотек для успешной валидации приложения.

Правки, которые были внесены в AmberPDF, в будущем должны появиться в составе «Аврора SDK». Это:

  • добавление графических аннотаций (линии различной ширины);

  • добавление изображений;

  • добавление текстовых аннотаций.

Также обнаружилась проблема, из-за которой в pdf-файлах не отображаются шрифты, если они не встроены в сам pdf и отсутствуют в системных шрифтах. Например, большая часть документов использует Times New Roman или Arial, но по умолчанию в системных шрифтах их нет, из-за чего AmberPDF не может отрендерить такой файл. В качестве временного решения недостающие шрифты сейчас вручную добавляются в /usr/share/fonts на устройствах.

Текстовые и офисные форматы

С отображением офисных файлов дела обстоят сложнее. Библиотек или QML-компонентов для отображения нет.

Мы попробовали отображать файл в WebView, но при попытке передать путь файла в качестве URL в WebView открывается диалог выбора каталога для сохранения файла.

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

Такое решение, однако, принесло некоторые неудобства, т.к. нам пришлось перетащить к себе в код как submodule полную коллекцию модулей LibreOffice (более 3 гигабайт до сборки), из-за чего очень сильно увеличилось время сборки и итоговый размер rpm-пакета приложения. Также после внедрения библиотек LibreOffice собирать приложение стало возможно только вручную через sfdk, а осуществлять отладку только с помощью gdb на физическом устройстве. Это обусловлено тем, что библиотеки LibreOffice собираются в момент сборки самого приложения и команды (configure, make..) находятся в spec-файле, а при такой конфигурации запуск и отладка в IDE становится невозможной.

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

Пример того, как собираются и используются библиотеки LibreOffice, можно посмотреть в проекте DocumentConverter, опубликованном в репозитории «ОМП».

Сборка приложения

Сборка в «Аврора SDK» происходит в среде Build Engine, которая представляет из себя либо виртуальную машину, либо Docker-контейнер. Способ выбирается при установке SDK.

По мере увеличения кодовой базы и подключения сторонних модулей в проект время сборки приложения также начало увеличиваться. И в какой-то момент сборка «на холодную» в SDK начала занимать около 15-20 минут.

Для использования в CI/CD системах у ОМП есть компонент Platform SDK, который предоставляет возможность сборки приложений из командной строки с подписанием и валидацией пакета. На удивление, полная сборка нашего проекта со всеми шагами проходит примерно за 4-7 минут.

Проблемы с отладкой

Проблемы начались, когда необходимо было дебажить код. Были моменты, когда при остановке на брейкпоинте остановка происходила вообще в другой части кода, а сам брейкпоинт удалялся. Такое поведение было замечено в IDE, которая установлена на macOS и на Windows. После перехода на Linux Ubuntu подобные проблемы практически не наблюдались.

Вторая сложность — использование эмулятора. Сам эмулятор является виртуальной машиной в VirtualBox, и он очень медленно работает. Данная проблема была замечена по большей части на macOS, если запускать в Linux, то эмулятор работает куда лучше, но все равно не идеально.

Поэтому самым лучшим вариантом, как и везде, остается иметь физическое устройство с ОС «Аврора». Подключение устройства к IDE происходит без проблем, и при подключении через SSH дебаг можно проводить в терминале уже в запущенном приложении с помощью gdb.

Послесловие и благодарности

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

Верим, что в дальнейшем средства разработки и сама ОС будут только совершенствоваться.

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