Deploying Qt to a central place on Blackberry devices
Deployment on BlackBerry 10
This article explains various details about deployment on BlackBerry 10 for Qt developers. Generally, this topic is well explained in the BlackBerry 10 documentation for native application development. In this article, you will find some additional details and tips specific for Qt development.
Start with BlackBerry 10 docs
It is good to get an overview first if you are new to a platform. Please read the following overview articles in the BlackBerry 10 documentation:
- Developing apps [developer.blackberry.com] and all articles in that section.
- The BAR application descriptor file [developer.blackberry.com] and App permissions [developer.blackberry.com]
- App Life Cycle [developer.blackberry.com]
- Working with the file system [developer.blackberry.com]. This article also explains how standard Qt paths, e.g.
QDir::homePath()<code> are mapped to the file system.
- Using low-level functionality [developer.blackberry.com]
Application packaging
The page Packaging, deployment and distribution [developer.blackberry.com] is a good introduction to the tools and how to use them.
In short, applications are packaged in so called BAR files which are zip archives with additional meta information.
Blackberry Application aRchive (BAR) descriptor file
A part of this meta information is the content of the BAR application descriptor file [developer.blackberry.com] which is an XML file. This file describes the content of the package and where this content can be found. This file defines other important meta information as well, but this is less relevant to this article.
Qt Creator has an editor for the BAR application descriptor files which simplifies quite some manual editing.
The content of the package may also include images, sounds and any other data files used by the application in addition the the binary.
See full list of all elements in a BAR application descriptor file [developer.blackberry.com]
blackberry-nativepackager
Application packages are created by the command line tool
blackberry-nativepackager<code> provided in the BlackBerry 10 <span class="caps">NDK</span>. This tool reads a <span class="caps">BAR</span> application descriptor file passed as an argument and builds the application package accordingly.
Application packages can be built in a development mode or can be built as signed packaged. Development mode applications require a debug token and can be installed and run on any device with the same debug token as they were build with.
Signed packaged are usually used for publishing in BlackBerry World. They can also be installed from the command line on any device in development mode and do no need a debug token.
See the full article about Packaging, deployment and distribution [developer.blackberry.com]
Where do the app resources land on the device
Handling the sand box
Each application is installed in its own home folder on a dedicated partition. Shared folders (those which contain data to be shared between apps) are mapped according to permissions requested so that the app can access them under the standard paths. An important thing to keep in mind is that all applications can access files only within the boundaries of their “sandboxes”. When the app asks to access shared data, according folders become available in app’s sandbox as well. See Working with the file system [developer.blackberry.com] for an overview of all sub-folders for different purposes in app’s home folder.
Applications cannot directly access any files outside their sandboxes. Even though it is possible to package and deploy libraries with the application, it is not possible to deploy any libraries into the system folders. Applications cannot share their libraries with other applications either.
Packaging and accessing the files
Even though the article Working with the file system [developer.blackberry.com] explains how the sandbox model influences file access, it might be clear from the beginning how paths can actually be referred in the application code.
Lets assume you have an app which loads an image with Qt Quick . The application code is located in the subfolder “test_assets” in your “projects” folder. The first thing you have to take care of is to add this image to the BAR application descriptor file:
This line is the universal way to add any other “stuff” to the app package, see this application descriptor file DTD article for more details. It is basically:
or even shorter:
Note: we use an absolute path in the above example to handle shadow builds. A relative path works too, but will make shadow builds less portable than absolute paths :-)
You also have to add QML files:
The key thing to know here is that the app installation folder is mapped to the folder “app/native” in the application working directory (referred by QDir::currentPath(), i.e. a “.” folder in the BAR application descriptor file maps to the “app/native/.” folder. Our app, the app would be installed for example in:
The “qt-logo.png” lands here:
The “qml” folder will be recursively copied to
Our app has only one QML file which lands here:
This QML code loads the image in “main.qml” as:
Notice the “../” in the front of the file name! This is because the current folder of an Qt Quick element is where its file was loaded from. We load “main.qml” this way:
“Image” assumes it is located in “app/native/qml/” and so needs to get one level up to get to ““app/native/qt-logo.png”.
One more thing to notice. The article Working with the file system [developer.blackberry.com] also talks about a dedicated “assets directory”. This is a bit confusing, since the “asset” XML element in the BAR application descriptor file can refer to any file, but the “assets directory” refers to the “asset” URI scheme in the Cascades framework. Using Cascades UI components you can load image as”
Doing the same in Qt Quick with Qt 4.8:
does not work, since the “asset” scheme is not available in Qt Quick. There is another approach for this in Qt 5.2 and later.
Prefer using the Qt resources
Using Qt resources (via the “qrc://” scheme) for all small read-only files and especially for QML code files is a more preferred and convenient way! Accessing assets as files makes only sense for large read-only files or files which will be changed/created by the app.
Viewing the folders on the device
In some cases, it might be needed to inspect the actual content of the folders directly on the device. You can do this in an SSH shell in the File Inspector in the Momentics IDE. The article BlackBerry Hints and Tips shows how to use SSH with BlackBerry 10 along with a few other hints and tips.
Packaging and Deploying Qt5 applications using the binary Qt5 overlay
The easiest way to deploy Qt5 applications for testing and distribution in Blackberry World is to use the binary overlay explained in Qt5 on BlackBerry10 . It contains an experimental make specs add-on which provides special make targets for deployment and packaging. See the article Using custom Qt builds on BlackBerry 10 devices for details. This add-on also automates the deployment of a Qt runtime for a shared use which is explained below.
If your application has been packaged in the development mode (the
-devMode<code> option in <code>blackberry-nativepackager<code>), it gets slightly more permissions than if it was in the release mode (see [https://developer.blackberry.com/native/documentation/core/com.qnx.doc.ide.userguide/topic/package_deploy_about.html this article] ''[developer.blackberry.com]'' in the BlackBerry 10 documentation for mode details). One of those permissions is a read/write permission for the <code>devuser<code> home folder. <code>devuser<code> is a user account on the device linked to your debug token. You can use this folder if the apps use the same set of data for development purposes.
This folder can also be used to deploy a Qt runtime in such a way that it can be accessed by multiple applications in the course of development. See the article Using custom Qt builds on BlackBerry 10 devices to learn how this works.