AR drawing tool for iOS

Programming language: Swift 5

Technologies: UIKit, ARKit, SceneKit

Platform: iOS 13 and latter

Requirements
Diagrams
Code

Архитектура

Содержание:

  1. Часть 1
    1.1 Тип приложения
    1.2 Выбор стратегии развертывания
    1.3 Выбор технологии
    1.4 Показатели качества
    1.4.1 Графический дизайн и взаимодействие с пользователем
    1.4.1.1 Стандартный дизайн
    1.4.1.2 Навигация
    1.4.2 Функциональность
    1.4.2.1 Права доступа
    1.4.2.2 Звук
    1.4.2.3 Графика и интерфейс пользователя
    1.4.3 Производительность и стабильнотсть
    1.4.3.1 Стабильность
    1.4.3.3 Качество визуализации
    1.5 Сквозная функциональность
  2. Часть 2
    2.1 "To Be Архитектура"
    2.2 "As Is" архитектура
  3. Часть 3
    3.1 Сравнение и анализ
    3.2 Пути улучшения архитектуры

Часть 1

1. Тип приложения

Проект предпологает проектирование и создание мобильного приложения для создания простых 3D сцен в дополненной реальности. Проект предпологает реализацию на языке Swift с использованием фреймворков ARKit, SceneKit, UIKit.

2. Выбор стратегии развертывания

Нераспределенное развертывание приложения предпологается посредством установки приложения из AppStore на мобильное устройство под управлением iOS 13 и старше

3. Выбор технологии

Язык Swift выбран как наиболее популярный для разработки мобильных приложения для платформы iOS. Технологии UIKit, ARKit, SceneKit имеют хорошую документацию поскольку являются фреймфорками поставляемыми компанией Apple, что позволяет нам быть уверенными в результате. Технология ARKit предоставляет весь необходимый функционал для работы с дополненной реальностью и имеет невысокий порог входа. Технология SceneKit выбрана поскольку имеет расширенные возможности для отрисовки сцены в дополненной реальности.

4. Показатели качества

4.1. Графический дизайн и взаимодействие с пользователем

4.1.1. Дизайн
  • Дизайн разрабатывался в соответствии с Human Interface Guidelines, которые предоставляет Apple.
  • В приложении используются системные цвета, что способствует поддержке светлой и темной темы, а тажке режима высокой контрастности.
  • Все бизнес-методы являются вызываемыми, т.е. созданы не потому, что может понадобиться в будущем.
4.1.2. Навигация
  • В приложении поддерживается стандартная системная навигация с помощью контроллера навигации.
  • Основной экран имеет минимально необходимое количество элементов навигации, что позволяет пользователю сосредаточится на работе с приложением.
  • Навигации приложения свойственна простота, интуитивность и минимальные затраты времени для перемещения между экрнами.

4.2. Функциональность

4.2.1. Права доступа

Приложение запрашивает минимум прав доступа:

  • Доступ к камере
4.2.2. Звук
  • В приложении не предполагается использование звуковых эффектов.
4.2.3. Графика и интерфейс пользователя
  • Приложение поддерживает вертикальную ориентацию экрана, а так же адаптируется под разные размеры экранов мобильных устройств.
  • Все виджеты и методы разметки экранов определены набором инструментов UIKit.

4.3. Производительность и стабильнотсть

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

5. Сквозная функциональность

  • В приложении все модули выделены, соответственно сквозная функциональность отсутствует.

Часть 2

To Be Архитектура:

Архитектурное решение команды по реализации идеи можно увидеть на Структурной схеме
Наглядный пример желаемого GUI приведен с помощью мокапов





As is architecture:

Диаграмма классов

Часть 3

1. Сравнение и анализ На данный момент архитектура AS-IS не имеет отличительных особенностей от архитектуры TO-BE, поскольку она является довольно простой и не имеет сложных связей и решений реализации. Также команда старается жестко придерживаться изначального решения в виде схем, мокапов и диаграмм для воплощении идеи.

2. Пути улучшения архитектуры Возможно внедрение паттерна MVP для уменьшения ответствености контроллера