Рекомендации к проектам ПО для ОС Аврора

Статья содержит рекомендации, на которые следует ориентироваться при разработке прикладного ПО для ОС Аврора.

Рекомендации к реализации
Предоставляемые артефакты
Рекомендации к безопасности

Рекомендации к реализации

Интерфейс пользователя и локализация

Оформление страниц приложения и обложки, а также логотип приложения разрабатываются в точном соответствии с утверждёнными для проекта макетами. Код должен полностью соответствовать макетам иконок, фонов, полей, цветов, шрифтов стилю платформы.
1. Для разработки макетов рекомендуется использовать UI Kit.
2. Реализацию интерфейса пользователя рекомендуется выполнять с помощью компонентов Silica и Aurora Controls.
Приложение должно поддерживать альбомную и портретную ориентации на тех страницах, на которых это предусмотрено макетами и ТЗ.
Переключение между ориентациями должно происходить плавно и без задержек при соответствующем изменении положения устройства.
Не должно быть резких скачков, зависаний, падений частоты кадров во время взаимодействия. Все переходы между состояниями пользовательского интерфейса должны быть анимированы, анимации плавные.
Пользовательский интерфейс масштабируется. Если шрифты, цвета, поля и другие параметры элементов интерфейса получены из Silica, это обеспечивает масштабируемость интерфейса и соответствие внешнего вида приложения общему стилю ОС Аврора.
Все тексты и надписи в приложении проверены на орфографические и грамматические ошибки соответствующими инструментами.
Должна быть обеспечена локализация интерфейса приложения на русский и английский языки. По умолчанию должен использоваться язык, соответствующий системным настройкам. Если не обеспечена поддержка системного языка, приложение должно использовать английский язык.
Язык контента определяется источниками данных. Но если он допускает локализацию, то она также должна быть произведена.
Все функции приложения должны быть завершёнными. Нет состояний, которые выглядят незавершенными или их смысл непонятен пользователю. В приложении нет пустых экранов, плейсхолдеров (изображений, видео, текстов, надписей, иконок), временных данных разработки.
Пользователю должны предлагаться действия для восстановления работы после возможных ошибок, например, при отсутствии сети или повреждении данных.

Функционирование приложения

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

Исходный код и сборка

Файлы с исходным кодом должны быть снабжены шапками с комментариями об авторском праве и лицензиях.
Исходный код должен быть хорошо структурирован и отформатирован согласно соглашениям об оформлении исходного кода.
QML-объектам должны быть заданы значения свойств objectName для возможности последующей автоматизации тестов.
Сборка проекта должна быть обеспечена стандартными средствами с использованием Аврора SDK (в случае, если сборка требует нестандартного подхода, это должно быть отдельно указано в проектной документации). Проект приложения должен успешно собираться во всех SDK, соответствующих целевым версиям ОС.
Локализация интерфейса пользователя должна быть реализована с помощью стандартных средств Qt. В исходном коде все строки интерфейса должны быть записаны на английском языке или оформлены в виде меток, заменяемых при локализации. В случае использования внешних ресурсов для переводов, следует использовать идентификаторы строк для перевода.

Установочные пакеты

Название пакета должно кратко и ёмко отражать суть предлагаемого пользователю сервиса (конкретные названия и пакета, и приложения указываются в проектной документации).
spec-файл, используемый для сборки пакета, должен содержать секцию %description, описывающую назначение и функциональность ПО.
Собранные rpm-пакеты приложений должны проходить проверку валидатором RPM-пакетов (конкретная версия скрипта определяется целевыми платформами).
Требования к установочным пакетом для актуальной версии ОС доступны в соответствующей статье. В частности:
1. При реализации приложения используются только разрешённые API.
2. В spec-файле, используемом для сборки пакета, не должны использоваться секции %pre, %post, %preun, %postun, %verifyscript.
3. В скриптах spec-файла пакета приложения не должны изменяться или удаляться существующие файлы.
4. Имя проекта и начало имени пакета приложения совпадают и содержат только строчные буквы, цифры и знаки тире.
5. Исполняемый файл располагается по пути /usr/bin/<имя_проекта>.
6. desktop-файл располагается по пути /usr/share/applications/<имя_проекта>.desktop.
7. Иконки располагаются по путям /usr/share/icons/hicolor/<разрешение>/apps/<имя_проекта>.png.
8. Дополнительные файлы, используемые приложением, располагаются в директории /usr/share/<имя_проекта>.
9. Для указания версии следует придерживаться принципов семантического версионирования в формате X.Y или X.Y.Z.
10. Версия приложения для Аврора Маркет может состоять только из цифр, разделённых точками, длина строки версии — от 1 до 20 символов.
Пакет должен быть подписан валидным сертификатом разработчика.

Лицензии и поддержка

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

Предоставляемые артефакты

Предоставляемые файлы

Как результат работы над проектом должны быть предоставлены следующие файлы:

Исходный код проекта в виде git-репозитория (если происходит модификация исходного кода других проектов, должны присутствовать начальные коммиты, включающие их код без изменений для возможности выделения изменённых фрагментов).
Собранные установочные пакеты для архитектур ARM и x86.
Тесты и методика ПСИ.
Файлы документации.

Комментарии и документация

Программный код должен содержать комментарии, описывающие:
1. Особенности реализации.
2. Функции, методы, классы, интерфейсы d-bus и другие сущности, предоставляемые в качестве API для стороннего использования.
Комментарии в исходном коде пишутся на английском языке и форматируются в соответствии с соглашениями об оформлении исходного кода.
Кроме того, должны быть подготовлены сопроводительные документы:
1. Диаграмма, описывающая архитектуру решения (для описания взаимодействия программных компонентов удобно использовать UML).
2. Документация по API и предоставляемым для стороннего использования сервисам (может быть сгенерирована автоматически с помощью QDoc или аналогичных инструментов).
3. Описание особенностей сборки, если таковые имеются.

Тесты

ПО должно поставляться с набором тестов, плана тестов и результатов тестирования. Минимальное содержание:

Unit-тесты по заявленным функциям (до 100% покрытие для happy-path, 80% общее).
Методика ПСИ на основе технического задания и функциональных требований.
Результаты тестирования стабильности и надёжности, а также совместимости для заявленных мобильных устройств и релизов ОС. Рекомендуемый минимальный набор проверок, применимых для всех проектов прикладного ПО:
1. Проверка работы приложения в условиях ограниченного пространства на диске и ограниченного объёма свободной оперативной памяти (отказ в обслуживании или некорректная работа).
2. Проверка работы при нагрузке на приложение (выполнение большого количества вариантов использования).
3. Проверка работы в различных условиях сети (2G, 3G, 4G, WiFi с ограничениями по скорости, переключение между сетями, устройство в сети VPN).
4. Проверка работы в режиме сна, долгого сна и после пробуждения устройства.
5. Измерение уровня заряда батареи при активном и пассивном режиме использования приложения.
6. Проверка работы при низком заряде батареи.
7. Проверка работы при различных ориентациях/расширениях экрана (можно использовать профили эмулятора).
8. Проверка работы на целевых аппаратных платформах (запуск и работа приложений на поддерживаемых устройствах).
9. Проверка работы на целевых версиях поддерживаемых ОС, в том числе после обновления ОС.