Design

Table of Contents

• 1 Introduction
  • 1.1 Purpose
  • 1.2 Scope
  • 1.3 Definitions
  • 1.4 References
  • 1.5 Overview
• 2 Planned Implementation
  • 2.1 Structural Breakdown of Implementation
  • 2.1.1 User Interface Technical Design
  • 2.1.2 Database Technical Design
  • 2.1.3 AR Technical Design
  • 2.2 Integration
• 3 Interface Description
  • 3.1 Colour Guidelines
  • 3.2 Font Guidelines
  • 3.2.1 App Icon
  • 3.3 Module Interface
  • 3.3.1 HomeView
  • 3.3.2 UserRegistrationView
  • 3.3.3 UserAuthenticationView
  • 3.3.4 CarListView
  • 3.3.5 DetailedCarView
  • 3.3.6 ARCamView
  • 3.3.7 UserSettingsView
  • 3.3.8 ExternalCarListingView
  • 3.3.9 CarRecordView
• 4 Class Diagrams
• 4.1 Model Class Diagrams
• Top Level View
• Detailed Class Diagrams
• ARKit and ARCore
• Data Dictionary

1. Introduction

cAR is a camera application that leverages augmented reality technology to provide a real-time 3-D model of sports cars within the camera view of a user’s living room or garage. cAR allows users to create an account on the application, and pick any car from the internal database to view.

1.1 Purpose

This document describes the software design and architecture of cAR application and is intended to allow any developer to reproduce the cAR application from scratch.

1.2 Scope

The cAR app is an iOS/Android application that was developed to generate AR videos of a car within a user’s camera application. The document is aimed at a developer with a background in Android and iOS development, who wishes to develop cAR from scratch.

1.3 Definitions

The following common acronyms are used in this document. Any acronym not mentioned here will be present in the Data Dictionary.

1.4 References

Below is a comprehensive list of documents that were used as references to create the cAR software design document.

1.5 Overview

The SDD consists of a detailed description of cAR’s software architecture. This architecture can be classified into two categories, the frontend, and the backend.

The frontend and backend software architecture is described using UML diagrams. A data dictionary further elaborates and describes the purpose of each attribute and method found inside the respective class diagrams.

2. Planned Implementation

2.1 Structural Breakdown of Implementation

2.1.1 User Interface Technical Design

The user interface for the application is designed using two major tools: Adobe Xd for rapid prototyping, and the Google Flutter API for cross-platform uniform implementation. The layout and design of the interface are written in Dart, the language used by the Flutter API. This Dart code is then converted by the API into Swift and XML code for iOS devices, and Java/Kotlin and XML code for Android devices. The packages for each OS are then exported and made available for installation.

Due to the vast amount of screen size options available for Android devices, an explicit decision to render the UI for devices with an 18:9 aspect ratio screen is due to time constraints. This decision was made keeping in mind the fairly strenuous hardware requirements for running an AR application. Since almost all newer (and hence, more powerful and compatible) Android devices are available in an 18:9 aspect ratio, we have decided to target this screen ratio moving forward.

2.1.2 Database Technical Design

Initially, the project design proposal was to use two different database systems: Google Firebase API to manage user authentication and maintenance, and MySQL to manage the requirement of a Car database. Upon further investigation, it was found that the Firebase API proved a superior alternative for the database needs of the Car database as compared to MySQL. This was due to its ability to provide a cloud-based, easily updatable solution to entering new cars into the database, and the ability to use an offline version of the database in case network connectivity was unavailable, thus removing the possible need for an internet connection upon app reuse. Another advantage was the Flutter API providing in-built support for all Firebase features, significantly reducing the complexity of implementing any required database features. These advantages, combined with the reduced complexity of using only one database solution over two, led us to focus on using the Firebase API as our sole tool for both the User and Car databases while eliminating MySQL as a workflow tool.

2.1.3 AR Technical Design

The AR technical design was handled across two teams, iOS and Android. Both platforms require different implementations of the AR toolkit. On the iOS side, we plan on implementing the ARKit API, which combines the graphical capabilities of the SceneKit API to render 3D car models in a Camera scene. This API allows us to create powerful 3D AR renders using native iOS hardware without compromising performance. One limitation of ARKit is the lack of an available first-party implementation of a recording feature; this issue is resolved by using an external open-source implementation of this feature called SCNRecorder, which we list in Section 1.4.

On the AndroidOS side, we will use a similar implementation of the ARCore API designed by Google. ARCore also has a recording trigger built-in, so there is no inherent need for any external solutions, thus making ARCore a powerful self-contained system for not only displaying AR projections but also recording and reviewing them. As for the sharing and saving capabilities, Flutter allows us to implement a ‘Share’ functionality in our user interface, which provides a cross-platform solution to sharing or saving user recordings managed by the OS itself.

2.2 Integration

The front-end team is responsible for the development, implementation, and testing of the user interface and all responsive elements. A bottom-up approach will be used to develop the skeletal layout of the user interface using Dart with the Flutter API. Once the pre-designed prototype of the app is agreed upon, members of the front-end team will begin to integrate the app elements together to form a base for back-end integration.

Once the UI is developed, the back-end team will work with the front-end team to implement Firebase features into the pre-existing UI skeleton. This involves user authentication as well as the Car database features. Due to the strong flexibility of Flutter’s Firebase implementation, this step of the back-end process will not require platform-dependent development.

On the AR side, due to the platform dependency of the ARKit (iOS) and ARCore (AndroidOS) APIs, the implementation of the AR Camera projection features, as well as their recording capabilities, will be handled by separate iOS and Android teams. An effort will be made to use existing Flutter support for both iOS and AndroidOS AR APIs to simplify this process. However, due to limited support for this functionality, the majority of AR development will be done through Swift and Xcode on iOS and Kotlin and Android Studio for AndroidOS. To support parallel development, the AR team will use a static Car object to implement and develop AR features until the Firebase Car Database features can be integrated.

3. Interface Description

3.1 Font Guidelines

3.2 Font Guidelines

The main font used throughout the app will be Segoe UI and its derivatives, depending on the requirement for stronger cases such as bolding.

3.2.1 App Icon

3.3 Module Interface

3.3.1 HomeView

3.3.2 UserRegistrationView

3.3.3 UserAuthenticationView

3.3.4 CarListView

3.3.5 DetailedCarView

3.3.6 ARCamView

3.3.7 UserSettingsView

3.3.8 ExternalCarListingView

3.3.9 CarRecordView

4 Class Diagrams

4.1 Model Class Diagrams

Top Level View

Detailed Class Diagrams

ARKit and ARCore

Data Dictionary

Data Dictionary

Authors

Document: Talal Elagha, Zhenyang Ding, Hussain Phalasiya, Omoma Eriamiantor, Lovette Oyewole, Abhirup Das, Matthew McBurnie, Jordan Den Hoed

Diagram: Lovette Oyewole, Zhenyang Ding, Hussain Phalasiya, Omoma Eriamiantor