QML wrapper service explained

C++ code for the wrapper

The service compiles small C++ program which creates QDeclarativeView instance and loads the QML file.

Tries to be as simple as possible

This code could be more complicated based on the features which we would like to expose to the QML side. This is the place to load all external libraries, open databases and generally do whatever a C++ program normally does. But in this service it is as simple as it can be.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

#include <QApplication>
#include <QDeclarativeView>

int main(int argc, char *argv[])
{
    QApplication app(argc, argv);

    QDeclarativeView view;
    view.setSource(QUrl("qrc:/wrapped-main-app.qml"));

    view.show();
    return app.exec();
}

In line 9 is the name of the QML file. This file is loaded and run. It is a resource named wrapped-main-app.qml which is put in place to the resource file by the service.

Line 11 is used to show the UI and line 12 enters the event loop and starts the program.

This is all there is to the wrapper, and this is all C++ code in the whole service. Everything else is needed just to get this code compiled and packaged to something that can be installed and run in the device.

At the moment only Nokia N900 is supported

At the moment only Nokia N900 is supported, but in the future we might add support for other platforms. The most interesting one would be S60 but at the moment Linux toolchain is in “will work eventually” state.

Also, this code does not use any special tricks to get better performance. For example it could change to OpenGL based renderer etc. There are, however, plans to support these in the future.

Resource template

Second piece to the puzzle is the resource file.

1
2
3
4
5
6

<RCC>
    <qresource prefix="/">
        <file alias="wrapped-main-app.qml">%%qmlfilename%%</file>
        %%additionalresources%%
    </qresource>
</RCC>

This is the template that is expanded by the system. As explained in the service, the project repository should have only one .qml file in the top level. The name of that file will be the project name, and that file is used in this template as %%qmlfilename%% in line 3. There is also an alias for that file. The alias is used by the C++ code.

Second template variable in line 4 is %%additionalresources%% which is expanded to contain all files in the repository with the same directory structure and names as in the repository. This means that in the QML file you can query the files in your repository by qrc://path/in/the/repo.qml.

Project template

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

QT += core gui declarative

TARGET = app
TEMPLATE = app

SOURCES += main.cpp

CONFIG += mobility
MOBILITY = 

RESOURCES += resources.qrc

The project has one source file and one resource file. Qt components used are core, gui and declarative. Also mobility is enabled.

With these in place the service can now create a binary.

Package template

Hopefully in the future the whole package skeleton is configurable

Nokia N900 device uses .deb packages for distributing apps.

The .deb format is quite extensive and this service uses only the bare minimum what can be done with it. Only the package name is changed each run.

The Nokia Qt SDK contains tools to generate the skeleton package template. To this template the system changes the package name, and copies the executable in place.

There are plans to allow more customization of this step in the future.

Web site

The website itself is written in Python using Werkzeug WSGI utility library. It is served with NGINX and gunicorn. Werkzeug was chosen for the task because it is the lightweight cousin of Django which we usually use for all web stuff.

The purpose for this is to send commands to the cluster. At the moment there is obviously only one command: start the build. And only parameter is the repository URL.

Cluster

The last part of the stack is the build cluster. This ties everything together and makes the build in these steps:

1. Checks the URL agains regexp pattern. It has to point to BitBucket
2. Send tweet “Starting to process”
3. Creates temporary build directory
4. Clones the repository
5. Checks if the repo contains build result already
6. Reads the repository content
7. Populates template variables based on the repository file list
8. Creates qmake project file
9. Creates package files
10. Runs qmake and make
11. Runs mad dpkg-buildpackage
12. Copy the results to work area
13. Add, commit, push
14. Clean the build directory leaving no trace of the build
15. Send tweet “Done”

The cluster is running Celery and RabbitMQ is taking care of the messaging.

Celery is really cool little piece of software. Altought Celery might have been created for different types of applications in mind it works beatifully as a build cluster. The nature of the service and Celery makes this really scalable. There is no limit in the number of build nodes.

The communication to the user is handled by Twitter.

Templating and substitutions are done by custom Python tool created for this service. The templating system could be used to power pretty much any type of build system as the templating is quite flexible. It is repository based and on each build the temporary build directory is created by cloning the template repository.