Developing mobile application for Aurora OS, part I: general architecture

Executive summary

A first version of the voting system has been developed and delivered to the client for the first launch in the production next week.

The client is a university from Top-12 universities of Russia is interested to replace BOSH system to conduct voting inside the university. Key requirements are to keep it private and secure and to meet with Russian law regarding foreign solution replacement in the state own enterprises.

Solution that has been developed is client-server application with blockchain to store votes and mobile client based on national mobile OS with access to the system by personal ID cards (nfc).

Technologies: Aurora OS - C++ - Qt - NFC - Python - Pydantic - SQLAlchemy - HTML - JS - REST - JSON - Git - GitLab - Hyperledger - Redis - Postgres - WebSocket

Publication below covers the basics of developing mobile application for Aurora OS. This is a relatively new platform that's get boost in potential market share due tensions between Russia and the West.

The intro

Request of my current customer is to perform polls in-house based on solutions authorized by the Russian government. In terms of mobile devices tablets on Aurora are solely solution for this.

Aurora OS is based on Sailfish OS and has been developing by Russian company OMP

The Aurora platform (formerly known as Sailfish Mobile OS RUS) has been in development since 2016.

This year, the Russian company Open Mobile Platform (OMP) received the rights to refine and adapt the Finnish Sailfish OS for use in Russia. Aurora began to develop as an operating system aimed at corporate and government customers, with an emphasis on information security.

Tech stack is quite new and just experience uprising by emerging markets caused by tensions between Russia and USA and necessity to secure Russian positions in the all critical spheres.

In this perspective the short term goal is to deliver a new solution for my customer, but the long term goal is to develop expertise in this new platform to offer upcoming potential customers.

Motivation

Back in the USSR there was a joke that Russian engineers can build a plasma gun from a refrigerator. However, on the West dual-use technologies are also not uncommon.

Twitter is positioned itself as short messaging system for a casual communications. However, he played a crucial role in revolutions in Middle East and North Africa called "Arabian spring". The mobile game "Pokemon Go" might looks like just an entertainment for teens, but at first opening in creates three photos of the space around and sends its back to the server which is used to gather up-to-date maps of the whole world. Reward system of the 'game' could push players to physical locations unavailable for satellites and spies.

The modern mobile phone with its sound record, geo position, accelerometer data and video record is powerful spy tool in a pocket of almost every citizen. It is important to mitigate risks associated with this. The full autarky is achieved over self production of hardware, software and Big Data and own mobile OS is one of the steps towards this.

General architecture

Project structure

  • icons/ - Contains the application icons for various screen resolutions.
  • qml/ - Contains the QML source code and UI resources.
  • cover/ - Contains the application cover implementations.
  • pages/ - Contains the application pages.
  • translations/ - Contains the UI translation files.
  • src/ - Contains the C++ source code for the application.
  • rpm/ - Contains the rpm-package build settings and scripts.
  • ApplicationTemplate.pro - This is the project file for the qmake build system. It describes the project structure and configurations.
  • ApplicationTemplate.qml - This file contains the application window implementation written in QML.
  • main.cpp - The entry point for the application written in C++.
  • ApplicationTemplate.spec - This file is used by the rpmbuild tool to build the RPM package.
  • ApplicationTemplate.desktop - Defines the display and parameters for launching the application.

The main developing language for Aurora OS is a C++, so a project would have a classic C++ separation on headers and implementation files.

The interface is developed with a help of QML and stored in a separate folder.

Others folders includes projects images, translation files and build artifacts. A special note for a .pro file -- it covers configuration for a project.

Entry point

Files main.cpp and .qml serves as an entry point into the app. Main.cpp register all necessary objects and qml files gives a reference to the first screen. 

                        int main(int argc, char *argv[])
                        {
                            QScopedPointer application(Aurora::Application::application(argc, argv));
                            application->setOrganizationName(QStringLiteral("ru.fa"));
                            application->setApplicationName(QStringLiteral("Voting"));

                            qRegisterMetaType("PollViewItem");
                            qRegisterMetaType("PollQuestion");
                            qRegisterMetaType("PollQuestion*");

                            QScopedPointer sharedData(new SharedData());
                            sharedData.data()->setParent(nullptr);
                            QScopedPointer adapterViewModel(new OptionsAdapterViewModel());
                            QScopedPointer authViewModel(new AuthViewModel(sharedData.data()));
                            QScopedPointer pollsViewModel(new PollsViewModel(sharedData.data()));
                            
                            // the rest of the code
                        }

View - ViewModel - Model

I have not noticed any architecture pattern in publicly available Aurora OS projects, so I introduced a modern architecture which I used in Android projects.

It is know as a Clean Architecture, but basically it is a result of following key engineering the best practices: single responsibility principle, low coupling, dependency inversion. ChatGpt gives such more detailed explanation:

Clean Architecture is a software design philosophy that emphasizes separation of concerns, maintainability, and testability. It is a result of following key engineering best practices, such as:

  • Single Responsibility Principle (SRP): Each module should have one reason to change.
  • Low Coupling: Components should depend on abstractions rather than concrete implementations.
  • Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules; both should depend on abstractions.

Additional Key Aspects of Clean Architecture:

  • Layered Structure: Clean Architecture divides software into well-defined layers, typically:
    • Entities: Core Business Logic
    • Use Cases: Application Logic
    • Interface Adapters: Controllers, Presenters, Gateways
    • Frameworks & Drivers: External Systems, DB, UI, etc.
  • Independence from External Frameworks: The core business logic does not depend on external databases, UI frameworks, or third-party tools.
  • Testability: Since business logic is isolated from external dependencies, it is easy to write unit tests.
  • Flexibility & Maintainability: Changing frameworks (e.g., switching from PostgreSQL to MongoDB) or replacing external APIs does not affect the core business rules.

In the foundation of the app there is a model of data. It might be cached in storage or requested from network and operated directly -- this is the core of application. The next layer is business logic implemented as UseCases. They encapsulates all necessary specific transformations and operations on the data. The next layer if a ViewModel which connect UI layer defined in QMl with data passed through business rules of the use cases.

Signal-slot mechanism

Similar to broadcast messages I first met in 2010 in Android, C++ & Qt offers low coupled mechanism to connect two parts of the code from different layers. Interestingly is that signal-slot mechanism had been developed back in 1995 and inspired event driving programming itself! 

                        signals:
                            void requestFinished(const QString &response, const RequestId requestId);
                            void requestError(const QString &error, const RequestId requestId);

                        private slots:
                            void onReplyFinished(QNetworkReply *reply);
You defined signals as a member fields and after it 'connect' them with each other 
                        connect(m_networkManager, &QNetworkAccessManager::finished, this, &NetworkManager::onReplyFinished);

In this way emitting signal 'finished' would trigger 'onReplyFinished' finished slot and associated with it logic.

Notify View layer about model changes

ViewModel objects registered in main.cpp become available globally in qml. To respond on changes in model, we have to register special slots which would listen signals associated with changes in model. 

                    Connections {
                        target: authViewModel
                
                        onAuthenticationSuccess: {
                            Common.log("Authentication successful")
                            signInByCard.errorText = ""
                            parent.parent.currentScreen = 2  // Switch to the next screen
                        }
                
                        onAuthenticationFailure: {
                            Common.log("Authentication failed: " + message)
                            signInByCard.errorText = "Не удалось авторизоваться"
                            signInByCard.setError()
                            infoMessage.show("Не удалось авторизоваться")
                        }

                        // the rest of the code 
                    }

Create custom component

Quite soon after the beginning of the development you will face with a necessity to encapsulate code into separate components to cope with code cluttering and maintain scalability and maintainability of project. It is possible to do by implementing custom component in a separate file and register it in main.cpp

Share data among screens

Architecture of the app implies one ViewModel per screen. It opens an issue how to share data among multiple screens.

Aurora OS supports sqlite as a storage layer, but in our case we need to have something in-memory. This issue had been solved by introduction a separate object called Cache which is registered in the same as a ViewModel and passed over constructor to an each ViewModel. In this way it becomes a databus where each view model might gain access.

Register images

                    
                        
                            
                            assets/images/background_authorization.png
                            assets/images/background_auth_form.png
                            assets/images/background_auth_form_shadow.png
                            assets/images/background_auth_form_merged.png
                            
                        // the rest of the code
Registering images is done over a special file assets.qrc which is later could be referred in the code this way: 
                    Image {
                        source: "qrc:/assets/assets/images/background_authorization.png"
                    }

NFC

Work with NFC is done over DBus system. You have to implement several its interfaces in your client to call its API. On receiving signal you can run business logic associated with it. 

                    Image {
                        source: "qrc:/assets/assets/images/nfc-interface.png"
                    }

Related publications: