BlackBerry Developer Blog » qthttp://devblog.blackberry.com
Tue, 03 Mar 2015 20:16:07 +0000enhourly1http://wordpress.com/http://1.gravatar.com/blavatar/9ef0a66c09615fa946c4179662398878?s=96&d=http%3A%2F%2Fs2.wp.com%2Fi%2Fbuttonw-com.png » qthttp://devblog.blackberry.com
The Beta for the BlackBerry 10.3 Native SDK is Herehttp://devblog.blackberry.com/2014/05/the-beta-for-the-blackberry-10-3-native-sdk-is-here/
http://devblog.blackberry.com/2014/05/the-beta-for-the-blackberry-10-3-native-sdk-is-here/#commentsThu, 15 May 2014 18:00:04 +0000http://devblog.blackberry.com/?p=18332/ Read More]]>It can be challenging to develop an application for different form factors without separating pieces of code to handle different screen sizes and pixel densities. Addressing the need for UI adaptability – and making form factor variations less of a challenge – has been one of the main goals for the Cascades UI framework in the 10.3 beta release.

However, there is more to 10.3 than just UI adaptability features. We also enhanced the Momentics IDE with the new 2.1 release, which brings workflow and UX improvements to the table. And to top it off, we also added several new audio-specific APIs in this beta, with more to come in our 10.3 Gold release.

Below are a few of the important new features that come with this beta release. These features will make life easier for you as a developer, which will result in a better experience for your users.

Design Units

The problem we sought to address is simple to understand: if you use pixels as the unit when positioning and defining sizes of UI elements in a layout, the UI will look different on devices that have different pixel densities. The picture below illustrates this problem.

In the implementation of the list layouts in this example, the item height is set to 173 pixels. When displayed on a low PPI screen (left), the item becomes physically larger compared to the high PPI screen (right).

If you use Design Units (DU) instead of pixels to define the list items in this example, the result would be like in the picture below:

So, what is the exact relation between DUs, pixels and physical measurement? On the Z10, one DU equals 10 pixels, and on a Z30, one DU equals 8 pixels. When comparing one device with another, the physical size of one DU is approximately (but not exactly) the same size.

This is how you would use DUs in your code:

Container {

preferredWidth: ui.du(25.3)

preferredHeight: ui.du(6)

background: Color.Red

}

“Buckets” and Selectors

Selectors and Resolution Buckets

Depending on pixel density, different devices belong to different “resolution buckets” (which we also sometimes refer to as “design buckets”). The Z10 belongs to bucket 10 (since it has 10 pixels per DU) and Z30 belongs to bucket 8 (with 8 pixels per DU).

There is a new asset selector feature that makes it possible to provide different assets for different resolution buckets. So similar to how you have been using a folder structure in your project to provide different assets for different resolutions, themes, etc., you would now provide (image) assets using a folder structure that could look like this:

assets

├─ 10ppd (Z10)

├─ 9ppd (Q10/Q5)

└─ 8ppd (Z30)

Automatic Image Scaling

If a device belongs to a resolution bucket for which you have not provided an optimized image, Cascades will take the asset in the closest (higher) bucket and scale it.

This can be a very convenient feature to use for many of your assets. Simply provide one single high resolution asset, and for all other buckets, Cascades will scale it for you.

assets

└─ 16ppd (all)

Selectors and Layout Buckets

With 10.3, Cascades offers a better way to handle alternative layouts for devices with different form factors. While the Resolution Bucket is the technique for different (density dependent) image assets, “Layout Buckets” is the new way to provide device, or more correctly, screen size-dependent layout implementations. This is the syntax for naming the layout assets folders:

min(d)?((w|h)[0-9]+|w[0-9]+h[0-9]+)du

w -> width

h -> height

d -> display dimension (optional)

And this is a more concrete example of how you could name your folders, when you would want separate implementations for devices with large (tall) or small (short) screens:

assets

├─ mindw76h128du (Z10,Z30)

└─ mindw80h80du (Q10/5)

Brand Colors

We all want our own application to stand out from other apps. And perhaps you have a brand color that you want to use across your application. So instead of just using the predefined blue accent color that comes with the dark and light themes, with 10.3 you can choose any color for the Cascades UI controls used in your app.

The implementation of the Cascades UI controls rely on a palette of colors, or color types to be more specific. Using a simple UI example, the image below shows what the different types in this color palette are:

As a developer, you don’t manually define all the colors in this palette. Instead, you define a primaryColor, and optionally the primaryBase. The different types in the color palette are generated by Cascades.

Many developers can just set the brand color (the primaryColor and primaryBase) and then simply verify the result, without having to pay attention to the individual color palette items.

But in the case where you have implemented custom controls, and you want these to adjust the appearance when a brand color is applied, you can access the colorPalette and use it in your implementation.

Audio & Media APIs

On the API front, we’ve added several new native APIs to supplement our current audio offerings.

First, we’ve added in support for OpenMAX AL. OpenMAX is a royalty-free open standard for providing access to codecs and presentation audio, video and images. For a full overview OpenMAX spec, feel free to browse OpenMAX on the Khronos website.

Please be aware that we do not implement all of the mandatory interfaces as noted by the specification, and in certain cases we have added our own extensions – particularly pertaining to buffer queue IO usage. Our current implementation of OpenMAX provides support for audio and voice recording and decoding. In a later release we plan to add support for video encoding.

Along with OpenMAX, we are providing access to our ProVoice API. ProVoice encapsulates a set of audio interfaces and codecs that allow you to add high quality full duplex audio support in your applications – the type of high quality audio that you can find in our BBM application, for example. If you’re building VoIP apps or apps that would benefit from full duplex audio, you should definitely consider incorporating this technology.

Tooling Improvements: Introducing Momentics IDE 2.1

You might wonder why you need to download this new version if you’re perfectly happy with Momentics 2.0.

There are two reasons you will want to upgrade. The first is so that you can move to the 10.3 API level and use some of our new and exciting Cascades features and core APIs. We don’t support the latest 10.3 API level in Momentics 2.0 (and earlier), so you’ll want to upgrade to the new IDE to take advantage of all the new features.

Second, the new IDE includes some valuable workflow improvements that you might find useful when developing your apps. Let’s take a closer look at some of the new features with this 2.1 beta release.

64-bit Installers

The first thing you’ll notice when installing Momentics 2.1 is that you now have the option to select the native 64-bit installers.

Note that this does not mean you can write 64-bit applications on the device or that BlackBerry 10 is now a 64-bit OS – all it means is that the IDE is now supported natively on the 64-bit desktop OS that you’ve installed it on (Windows, Mac or Linux). We continue to support 32-bit versions.

Updated Toolbar

You’ll also notice that we changed the toolbar. The old toolbar focused on projects as the starting point for the debug, run, profile configurations. The new toolbar focuses on launch configurations. Here’s a snapshot of the new toolbar:

Each time you create a project, Momentics creates a corresponding launch configuration in your workspace.

Build: Builds the selected configuration

Launch: Allows you to launch the configuration on the selected target (device or simulator)

Stop: Stops the build

Launch mode: Provides a drop-down of various launch modes you can run from the toolbar including run, debug, profile, code coverage, etc.

Launch configuration: Lists the configuration for each project

Launch target: Allows you to specify the device or simulator target you can launch your project on

New Card Templates and Card Debugging

For more advanced users, we added support for card templates and card debugging. One of the challenges when developing invokable cards is that there were no templates provided for creating a card, nor was it that easy to debug one. We addressed this with the new card templates that allow you to create a card app with a UI component.

The IDE also provides better support for triggering and debugging cards. You can now launch a card from the IDE, attach to it and set breakpoints as you would with a regular app. This workflow has been simplified, so debugging cards should be much easier.

QML Previewer Enhancements

If you’re working with design units, you’ll be interested in the support we added for design units in the QML properties view.

The QML previewer also has some enhancements to make testing easier. For instance, in the preview window you can use the touch interaction feature to test how your app responds to touch events, or use the selection feature to find the code that implements a control. You can also easily see how your UI looks with custom brand colors, themes and screen resolutions.

A few notes about upgrading the Momentics IDE

There are two ways you can upgrade your IDE. The first is via the traditional method of downloading the installers on our Downloads page. The second way is via the IDE itself. First you need to grab the URL of the update site via the Downloads page. Once you have this URL, manually enter this in Momentics as you would when installing any other Eclipse plug-in. Then you’re ready to go!

But wait – there’s more…

There is of course more to the release than the features that we described. For example, on the UI side, a new grid layout as well as APIs for list rearrange.

We also added some NFC, telephony and PIM APIs along with other enhancements to the tooling such as support for pretty printers and a new device properties wizard.

We recommend checking out the Release Notes to get a full walkthrough of all the new features, known issues, and fixed issues.

… and there’s even more to come!

Stay posted for our upcoming 10.3 Gold release, which will offer even more API and tooling additions. You can get a sneak preview of what we’re planning for the Gold release by checking out our roadmap.

As always, please refer to our developer site to access detailed documentation, API guides and samples as well as to download our tools. Have fun with the beta!

Currently in Cascades, the Qt class Graph can’t be used. Several solutions have been used, including the use of a background image with overlaying text written by using a Label {}, but this approach never led to optimal results.

Fortunately, thanks to the great flexibility of the BlackBerry 10 Native SDK and to Angelo Gallarello, a member of our BlackBerry Dev Group in Milan who has shown us a great JavaScript library called jQuery Sparklines, we can solve the problem of using graphs in a very simple, fast and effective way.

jQuery is very flexible and easy to use. It supports seven different chart types and all of them are easily customizable.

A very cool feature is the possibility to test the custom parameters in real time thanks to the dedicated box and very detailed documentation on customizing charts.

The integration into a Cascades project is very easy: the first step is to create an HTML file with a simple text editor. In our case, we name it “grafico.html” and it looks like the following:

To display the graph, you just need to add a WebView to your project (in the QML file that should display the graph), setting its URL to the location of your HTML file.

WebView {

id: idWebView

objectName: "idWebView"

url: "local:///assets/webview/grafico.html"

verticalAlignment: VerticalAlignment.Fill

horizontalAlignment: HorizontalAlignment.Fill

}

The next step is to create the string with the values ​​that will be inserted in the grafico.html file to produce the graph.

In our case, I took a SQLLite database, and while rushing records with a Select, I created the string using the method of creating a function callable from the QML in the header file (HPP):

Q_INVOKABLE void readData (QString search);

and a Q_SIGNALS

void gotSparky(QString Sparky);

In CPP, I scrolled the database and for each record found and built the string in the global variable Sparky, maintaining the structure required by the jQuery library.

Finally, after reading all the records, I finished the creation by integrating the Sparky string with Sparky_Full which also contains the parameters for the creation of the chart. So I have set the string in QML “emit gotSparky(Sparky_Full);”

In the QML file you just need to add a few lines of code. I created two “property” that have the task of checking if the app is already connected to the “onGotSparky” signal (because in that case the data is duplicated), and a support string for the output string coming from the C++ function.

import bb.cascades 1.0

import bb.system 1.0

Page {

property variant connessoSparky:0

property string sparky_String: ""

onCreationCompleted:

if (connessoSparky == 0){

_app.gotSparky.connect(onGotSparky)

connessoSparky = 1

}

_app.readData(“SELECT * FROM myDataBase”)

}

function onGotSparky(stringa) {

sparky_String = stringa

}

I put in the evaluateJavaScript() in a ActionItem to keep everything separate. In practice, when onTriggered:{} is issued, the string is passed to the HTML page that elaborates it and gives the graph.

actions: [

ActionItem {

id: actGraph

title: "Titolo"

imageSource: "asset:///images/menuicons/ic_chart.png"

ActionBar.placement: ActionBarPlacement.OnBar

onTriggered: {

waterWebView.evaluateJavaScript(sparky_String)

}

}

]

That’s all! Let us know if you have any questions in the comments below, and happy coding!

Today we’re excited to announce that our friends over at Apress have just published their new book, Learn BlackBerry 10 App Development: A Cascades-Driven Approach. This handy, offline resource will help you learn how to build a native BlackBerry 10 app from the ground up.

Is your knowledge of C++ a bit rusty? Not a problem! This book explains key C++/Qt fundamentals for building your app’s logic, and it will also show you how to use QML and JavaScript for designing your app’s UI with the Cascades framework.

More specifically, this book will show you how to:

Design and create native BlackBerry 10 apps using the declarative expressiveness of QML

Integrate your app with BlackBerry 10 core apps, such as Contacts and Calendar

Send email and short text messages from your app

Use your device’s camera and sensors such as the accelerometer and gyroscope

Where/how/when can I get the book?

Beginning tomorrow, March 25*, you’ll be able to download a free copy of the eBook at Apress, Amazon, and Springer. Barnes & Noble will also be offering the eBook free beginning on March 31. You read that correctly, the eBook is 100% free!

The eBook will also be available on Safari Books Online, Google Play Books, Books 24×7, and Apple’s iTunes Bookstore shortly. We’ll add updates in the comments section of this blog post once the book becomes available in these additional channels.

Happy reading!

*Please note an earlier version of this post incorrectly noted that the eBook would be available for download on March 24.

]]>http://devblog.blackberry.com/2014/03/free-ebook-on-native-blackberry-10-app-development-now-available/feed/0BlackBerry Cascades BookinsideblackberryblogBlackBerry Cascades BookPresentations from Qt Developer Days Now Availablehttp://devblog.blackberry.com/2014/03/presentations-from-qt-developer-days-now-available/
http://devblog.blackberry.com/2014/03/presentations-from-qt-developer-days-now-available/#commentsMon, 17 Mar 2014 17:00:46 +0000http://devblog.blackberry.com/?p=17999/ Read More]]>Qt Developer Days is the premier event of the year for Qt developers. It offers workshops, training and technical presentations for Qt developers to learn more about the framework and related technologies.

BlackBerry was well represented at this year’s Qt Developer Days right from the start, with a hugely popular keynote address delivered by QNX’s Dan Dodge. There were also training sessions on how to begin development for BlackBerry 10 and advanced topics showcasing the contributions BlackBerry has made to the Qt community.

If you weren’t able to attend Qt Developer Days in person, there’s no need to despair! Several of the technical presentations were recorded and Digia has made them publicly available. Check out these talks from BlackBerry folks:

“Enterprise Applications are just the same as Consumer Applications.”

This is a point of view that I often hear expressed, more often than not, by developers who have primarily focused on the consumer space. I don’t share that point of view. Enterprise Applications and Consumer Applications exist in different ecosystems, have different constraints, and often different requirements.

My colleague Martin Woolley covered many aspects of Enterprise Mobile Applications in A Flexible Architecture for Enterprise Mobile Applications Parts One and Two, where he outlined many of the considerations that need to be weighed when working in this area. He also identified a potential re-usable pattern for such applications that share many common features and requirements.

Like Martin this activity has catapulted me back into the world of Enterprise Applications, which is where I spent most of my time before joining BlackBerry about 5 years ago. I’m no stranger to Enterprise Architecture, Oracle Enterprise systems or even SAP Basis Component, though I’ve been focusing on technologies like NFC and Bluetooth more recently.

In this article I’d like to build on what Martin has described and discuss one possible way of accommodating this application architecture within Momentics when working with Cascades and native applications. There are other potential implementations of this same pattern using, for example, a web-based framework. (Watch out for these in the near future.)

The Target Application Structure in Momentics

The starting point is the overall application architecture, in Figure 1, that Martin has already described.

Figure 1: Overall Application Architecture

If we pare away the details, there are really four major elements as shown in Figure 2.

The GUI component of the Application

The Background Service component of the application

The Common Functions and Data component

The Adapter component of the application

Figure 2: Major Application Elements

Figure 3: Project Structure

I’ve chosen to name the complete application “AnnualLeave” letting me name the main components as shown in Figure 3 as:The components in green, the GUI and Background service, map nicely to the GUI and Headless service components of a Headless application. The components in orange, Common Functions and Adapter, map nicely to a pair of shared libraries.

AnnualLeave

AnnualLeaveService

AnnualLeaveCommon

AnnualLeaveAdapter

I use Git as a source code control tool and as a vehicle to share the development. In fact this is a significant point that’s worth dwelling on. The four projects live outside the Momentics workspace in a folder called “AnnualLeave;” this directory has a Git Repository associated with it – take a look at Figure 4.

This allows me to manage all four projects as a single unit in Git, but it also has other consequences. All four of these projects have dependencies on one another.

Figure 4: Folder Structure

This is much easier and much more transportable if all these projects live outside the Momentics workspace and are just imported into Momentics without copying. I’ve been there and tried it various other ways and it’s just much easier this way without any side effects.For example, the GUI project (AnnualLeave) needs to have access to the header files that the Common library project (AnnualLeaveCommon) has exposed to allow its APIs to be used at build time and to its shared library – once built – to allow external references to be resolved at link time.

Let’s look at each of these projects with a bit more detail, starting with the two shared library projects first since they are dependants of the GUI and Service projects and are almost identical in terms of structure.

Figure 5: Library Project Structure

The “AnnualLeaveCommon” and “AnnualLeaveAdapter” projects

These projects are both shared library projects, so they have three important aspects.

The header files of many of the classes need to be exposed to other projects since they embody the API exposed by the library. This is achieved by placing these header files in a folder called “/public” in the project, in contrast to the implementation of the APIs in the “/src” folder.

The shared library itself that is built is called “libAnnualLeaveCommon.so”.

The Common project is identical in layout and has its shared library under the name “libAnnualLeaveAdapter.so”

You can see this in the case of the “AnnualLeaveCommon” project in Figure 5.

There is a slight wrinkle with both of these shared library projects. I needed these projects to understand Qt constructs and for their classes to inherit from QObject in many cases.

The wrinkle is that the current version of Momentics only contains a shared library template that allows you to create a shared library project that uses the built-in tool-chain rather than qmake. A library that you can create using this template does not understand Qt since it’s unable to run the MOC pre-processor against the project’s header files.

The “AnnualLeave” and “AnnualLeaveService” projects

These two projects just represent the GUI and Headless Service components of a “Headless Application.” In principle, they are quite simple to create since there is already a Headless Application Template in the Momentics tools. Just use: “New -> BlackBerry Project – > Cascades -> Headless App”

I did find one wrinkle with this process where the destination of the pair of projects was outside the Momentics workspace. I found it more convenient and less error-prone to create the project in the Momentics workspace, export the two projects to a new location, delete the original projects from the workspace and re-import them without copying from the new location.

Now that we have established four projects supporting the application, the next thing is to ensure that they know about one another and that the application is packaged correctly into a .bar file with all the assets in the correct locations for installation on the BlackBerry 10 device.

Project Dependencies

Let’s take a look at the “AnnualLeave” project first; the one that is the GUI part of the application. This project really needs to know how to access the APIs in the “AnnualLeaveCommon” project; this would include things like the Operations API that Martin has already described.

There are three aspects of this:

The header files needed at compile time in /public in “AnnualLeaveCommon”

The shared library itself, needed at link time – “libAnnualLeaveCommon.so”

Where to find the shared library “libAnnualLeaveCommon.so”at run time on the device. (I’ll address this later in this article.)

The compile-time and link-time dependencies are expressed in the “AnnualLeave.pro” file. This file is used by qmake to construct the Makefiles that orchestrate the overall build process.

Figure 6 shows the additions I’ve made to the .pro file for the AnnualLeave project. I’ve added the /public path in the “AnnualLeaveCommon”project to the INCLUDEPATH for the build of the project. This is the same whether you’re building a Debug-Build or a Release-Build.

We have to be a little bit more careful when adding the information used to locate the shared library “libAnnualLeaveCommon.so” at link-time. Take a look at Figure 6.

Figure 6: AnnualLeave.pro file changes

You can see that I’ve had to deal with each of the possible target build cases, Debug, Release, Profile and Simulator, separately. Each of these build-permutations builds the library itself in a different location.

The “AnnualLeaveService” project is handled in exactly the same way, except that it needs to be aware of the details of the location of both the “AnnualLeaveCommon” and “AnnualLeaveAdapter” projects, and its .pro file needs to be updated appropriately. Similarly, the “AnnualLeaveAdapter” needs to be aware of the “AnnualLeaveCommon” and “AnnualLeaveService”projects.

You may also find it useful to identify the references that these projects have with respect to one another. It helps make building and cleaning projects a bit simpler in that Momentics knows what projects need to be re-built if another project changes.

You can see how to do this in Figure 5.

Figure 7: Project References

Now that all the projects build consistently individually, the next task is to ensure that all the necessary assets are collected together into the .bar file when the application is packaged.

Packaging the Complete Application with all Four Components

The specification of the packaging of an application is the responsibility of the bar-descriptor.xml file. Since there is only a single .bar file to be created for this application, even though it consists of four constituent projects, only a single bar-descriptor.xml file is needed and this lives in the GUI project.

Figure 8: bar-descriptor.xml file for the AnnualLeave Project

Figure 8 shows a section of that file. This happens to be the section that describes how the assets are assembled for a Debug-Build, but the principle works for other build types as well.

There are two points to draw your attention to. Each “<asset …/>” stanza identifies where to find a particular asset and where to place it in the target .bar file. In this case:

“libAnnualLeaveCommon.so” is found in the directory: “../AnnualLeaveCommon/arm/so.le-v7-g/”

And, placed into the .bar file under the directory: “lib/”, under the name: “libAnnualLeaveCommon.so.1”

Did you notice the “.1” at the end of the shared library name? This is a technique for associating version numbers to shared libraries. I had discovered that when the BlackBerry 10 OS tried to locate the shared library for “libAnnualLeaveCommon.so,” it was actually searching for “libAnnualLeaveCommon.so.1,” so I had to add it to the .bar file under this name. If you look at Figure 5 you can see that a variety of different version annotations have been created by the build process itself.

You can see that both of the shared libraries are placed under the “lib/” directory in the .bar file. But how do we let BlackBerry 10 know where to find these files at run-time on the device? Take a look at Figure 9.

Figure 9: Where to find the shared libraries at run-time

The highlighted directive makes sure the application is launched with the environment variable LD_LIBRARY_PATHset to include the path “app/native/lib,” which is where they end up on the BlackBerry 10 device as a result of the instructions in Figure 8.

How the Adapter Shared Library is able to Leverage Qt Signals and Slots

You may wonder why I wanted to have the AnnualLeaveAdapter implemented as a shared library that understood about Qt and have its contained classes inherit from QObject.

I wanted the ability to be able to interact with the objects defined in the library through Qt Signals and Slots. I also wanted to be able to communicate with the adapter through ordinary methods and have events returned from the adapter as Qt Signals. Lastly, I wanted to define the interface to the adapter in terms of C++ methods and Qt Signals.

So, how should we define and implement an interface to achieve this? If we were working only in C++, then we’d define an abstract class, and the developer who was implementing the “Adapter” library would create an implementation class that implements this abstract parent class.

This works nicely for methods that call into the implementation; however, it takes a bit of Qt magic to get it working for Signals. Here’s how I did this.

Figure 10: How to define a Qt aware interface

This class “IAdapter” in Figure 10 is a standard abstract class with added “Qt Magic.” It has a pure virtual function “annualEntitlementRequ()“ which will request, for example, leave entitlement for a specific year, and a Qt signal “annualEntitlementResp()” representing the response – also defined as a pure virtual function.

The key to getting this to work is the Qt declaration “Q_DECLARE_INTERFACE()“. This identifies the class “IAdapter” as being a Qt Interface, in addition to just being an abstract class, and allows the MOC compiler to get behind the scenes of the class and weave all the Qt meta-data together.

The implementation side of a class, “IAdapterImpl,” that implements this interface, looks something like Figure 10.

Figure 11: How to implement a Qt aware interface

This class is dependent on both QObject, to give me the Signal/Slot functionality, and IAdapter, since I’m implementing its interface. Q_DECL_EXPORT just ensures that this class is visible externally from the shared library.

The Qt magic here is the declaration Q_INTERFACES(IAdapter). This is what tells Qt that we’re implementing an interface declared previously by Q_DECLARE_INTERFACE , and allows the MOC compiler to weave Qt goodness into the implementation.

Figure 12: Using the interfaces

In Figure 12 you can see how I might actually use the interface. In the first instance I can use this to call a method in the adapter, and in the second I can connect a “Signal” in the adapter implementation with a “Slot” in my application.

Notice the subtle part where you need to cast the pointer to the implementation instance to a QObject* to have it as the correct type for QObject::connect().

Implementing the adapter in this way supports extensibility in that it makes it easy to substitute other adapters that support other Enterprise interfaces while retaining a well-defined interface to the rest of the application.

Summary

I hope you found this post useful. We suspect that, because of its generality, this project structure will be useful in many other enterprise mobile applications.

Today I want to highlight a small change that can shave hundreds of milliseconds off the startup time of your network-connected application. Many applications set up their UI first and then start their network requests later in the execution sequence. This is not the optimal approach, as loading the QML files needed for the UI can be a time-consuming activity. A better approach is for an app to perform its network requests before setting up the UI; then those tasks can execute in parallel.

This idea of starting app execution with network requests is expanded in Peter’s article on Pre-Connecting to a Web Server. BlackBerry 10.2 developers have the option to connect to a web server before sending an HTTP(S) request. This is helpful when the network request requires your app to read credentials, like an OAuth token, from storage.

And finally, if your app connects to a web service over SSL, take a look at Peter’s article on Re-Using SSL Sessions in Cascades apps. He shows you how your app can save time on startup by persisting SSL sessions via TLS session tickets. Re-using a TLS/SSL session has the benefit of saving one network round trip of the SSL handshake. This could result in your app being able to display content 200-300 milliseconds faster! This feature is available as of BlackBerry 10.2.

Let us know if implementing these methods helped you speed up your launch times!

The BlackBerry Developer Relations team will be at the upcoming Qt Developer Days in San Francisco. The conference runs from November 6th to November 8th and will help both Qt experts and those new to Qt learn how to get the most out of this robust framework.
Both myself and Manny Elawar will be meeting with developers at the BlackBerry booth and discussing how developers can bring their existing Qt apps to the BlackBerry 10 platform. Additionally, BlackBerry Qt experts will be giving talks on a number of topics:

Developing with Qt and Cascades for BlackBerry 10 – Erin Rahnenfuehrer gives a hands-on overview of developing apps for the BlackBerry 10 platform. Learn about the tools and capabilities of BlackBerry 10 and how to start using Qt and Cascades for native application development.

Qt 5 on BlackBerry 10 – Beyond the Myth – This talk will help you learn how Qt5 will be integrated into the BlackBerry 10 platform and Fabian will explain how you can use Qt5 for your BlackBerry application development.

Adaptable UIs with Qt Quick – Alan Alpert proposes that pixel perfect cross-platform design is possible with QtQuick. Learn how to achieve this ideal with bindings, loaders, and file selectors.

]]>http://devblog.blackberry.com/2013/11/blackberry-loves-qt/feed/0dev-blackberry-loves-qt-featureerahnenQt Developer Days 2013Qt in the Multi-Screen Agehttp://devblog.blackberry.com/2013/09/qt-in-the-multi-screen-age/
http://devblog.blackberry.com/2013/09/qt-in-the-multi-screen-age/#commentsFri, 06 Sep 2013 15:00:35 +0000http://devblog.blackberry.com/?p=16124/ Read More]]>Being a developer today means developing for multiple device types. When supporting different form factors, operating systems, and browsers, it’s not easy to write an app that targets a wide audience. By using cross-platform frameworks like Qt and providing a POSIX compliant operating system in BlackBerry 10, BlackBerry helps developers target multiple platforms. Additionally, this approach allows developers to learn only one API and technology instead of many.

Even with a framework like Qt, careful planning is needed to write an app that can be easily ported to different platforms. Let’s discuss some strategies for writing cross-platform Qt apps.

Separate Application Logic and UI

When designing your app, start by determining what logic can be shared across all platforms. For existing apps that you want to bring to BlackBerry 10, review your code and identify the components that are consistent across all targeted platforms.

Store the Qt/C++ code that targets multiple platforms in one project and use the “.pro” file used by qmake to control compilation for each platform. To facilitate the portability of your code, the UI design can be implemented in QML and separated from the core business logic. Each platform can have its own QML file, while reusing the same business logic across platforms. The C++ code can be connected to your QML UI through plugins or export properties.

The chart below illustrates how your C++ and QML code can be integrated for both Cascades and pure Qt projects:

Minimize Platform Specific Code and Encapsulate It

Not all of the business logic will be able to be shared across all platforms. Some things, like accessing sensors and handling in-app payments tend to be platform-specific. Encapsulate this code in separate modules, which will be built only for the platforms that need it. For example, you won’t need NFC code for a device that doesn’t support NFC. Try to minimize the code in these modules to the distinct calls needed by each supported platform.

An Example of Sharing Data Between Qt Quick and Cascades Apps

In many applications the C++/Qt layer supplies data to the QML layer through models. When writing cross-platform Qt apps, you should be aware that Cascades ListView elements expect different data models than Qt Quick. Data in Qt that is organized as lists of values or objects can be used to instantiate a model in a Cascades UI, and adapters can be created to expose more complex data models. We’ve created a sample for a straightforward case that shows you how to structure your app and share a data model across two different platforms:

Cascades running on BlackBerry 10

Qt Quick which will run on BlackBerry 10 as well as desktop platforms

The sample, available here, contains a data model that is a QList of our custom QObject class. The data model and data object classes are shared between the two projects. Each project has its own QML and its own way of binding the data to its list. You can see below in this snapshot how the two projects bind the data:

C++ application code of the Qt Quick based UI:

QDeclarativeView view;
// create a new model in the C++ backend
MyDataModel *myDataModel = new MyDataModel(view.rootContext());
// The dataModel needs to be added before loading the QML file
view.rootContext()->setContextProperty("dataModel", QVariant::fromValue(myDataModel->data()) );

…

C++ code for the Cascades based UI:

// create a new model in the C++ backend
MyDataModel *myDataModel = new MyDataModel(app);
// create a data model for Cascades UI
QListDataModel<QObject*> *cascadesModel = new QListDataModel<QObject*>(myDataModel->data());
// load QML
QmlDocument *qml = QmlDocument::create("asset:///main.qml").parent(this);
// make the data model available via a property in the context of the loaded QML file
qml->documentContext()->setContextProperty("myCascadesDataModel", cascadesModel);

Notice that the only real difference is that the Cascades code creates a QListDataModel object with the QList defined in the MyDataModel class. Then the QListDataModel is bound to the QML. You can also see how the QML in the two apps differ:

As mentioned above, complex data organized in trees or tables might require more sophisticated models than shown in our example. More advanced models are also needed for large amounts of data. This is available in Qt as a set of Item Model classes, and adapters can be written in Cascades to support these models. Tobias Koenig from KDAB has a great article and code sample on using the QAbstractItemModel with a Cascades ListView to implement these models.

]]>http://devblog.blackberry.com/2013/09/qt-in-the-multi-screen-age/feed/0erahnenqt in the multi-screen ageGetting Started with the V-Play Gaming Enginehttp://devblog.blackberry.com/2013/08/getting-started-with-the-v-play-gaming-engine/
http://devblog.blackberry.com/2013/08/getting-started-with-the-v-play-gaming-engine/#commentsWed, 21 Aug 2013 20:00:04 +0000http://devblog.blackberry.com/?p=15952/ Read More]]>This guest post was provided by the V-Play Development Team and edited by Lou Gazzola

After the announcement of BlackBerry 10 support for V-Play Game Engine, specialized for creating cross-platform mobile 2D games, it’s finally time to have a look at the advantages and concepts behind V-Play for you as a BlackBerry game developer.

Familiar Tools & Powerful Programming Concepts

The great thing about V-Play is that it’s built on top of Qt framework which is integrated into BlackBerry 10. Besides using already familiar tools, programming concepts and even reused existing source code for games and apps created with V-Play games run with maximum native performance in comparison to other HTML5-based solutions.

V-Play also uses QML as the main language for creating games, so declarative concepts already well-known from Cascades framework like property bindings can easily be utilized when using provided V-Play gaming components. These components are designed for tasks needed in almost all 2D-based games: sprite sheets, entity pooling for performance optimizations, AI components for path finding or steering behavior, to name just a few. These give the prototyping and development of your game an even bigger boost.

A simple “Hello World” example with V-Play may look like the following:

Furthermore V-Play includes full source code of live app store games for some of the most popular genres. These can be used as gaming templates to rapidly create games like tower defenses, platformers, physics games, side scrollers or action games.

Another great feature of V-Play is the resolution and aspect ratio-independent development approach (GameWindow & Scene components). Games look exactly the same during development on desktops as they do once they’re published on any mobile device – now including the BlackBerry Z10, and BlackBerry Q10 and BlackBerry Q5 smartphones with their square displays. Black borders on your screen or distorted graphics will be a thing of the past.

Social Networks and Gaming Services

Besides the core gaming components V-Play already offers, plugin components for most gaming services and social networks can easily be used from within QML. For example, displaying and hiding an AdMob banner depending on an in-app purchase state looks like the following:

Upcoming Level Editor & Game Network

Beside the shipped plugins (BlackBerry 10 support for all available plugins will be added within the next couple of updates) the upcoming launch of V-Play Game Network, in combination with integrated level editor components to quickly create your own levels and share & rate them over social networks, enrich the possibilities for monetizing games in mobile app stores.

Speaking of the level editor, you can also use the editor to create levels quickly during development and further cut development time and costs as you’re able to see the balancing changes immediately while your game is running, without having to restart the app, another cool feature V-Play is offering you.

Finally, the great news is that BlackBerry 10 support comes at no additional cost for existing V-Play subscribers, and it’s even possible to test V-Play created games on local development devices with V-Play’s free license (publishing a game in BlackBerry App World requires an upgrade to a pro subscription). More information on V-Play, including lots of useful tutorials, can be found here: http://v-play.net.

Qt developers often ask the following questions: Is there a porting guide to help me port my Qt apps to BlackBerry 10? What about porting Qt Quick to BlackBerry 10? How do I configure Qt Creator for BlackBerry 10?

The good news has arrived: you now have a porting guide covering the most commonly-encountered use cases. This guide provides the necessary information to developers of native mobile apps who fall in one of the following categories:

Developers who have Qt apps written in C/C++/ QML/JavaScript and intend to have their apps running on the BlackBerry 10 platform;

And finally, developers who want to take advantage of the Cascades UI framework and change their existing UI to the Cascades framework.

BlackBerry supports developers in all of the above described scenarios, and so this guide provides developers with best practices for each category. It also explains why a particular practice is considered the best one.

Update – Brian Scheirer pointed out that there have been some awesome community samples too! -Ed.

For me, 2012 has definitely been a year of helping developers learn about our native and Cascades development tools. If you’re like me, you’re probably spending the holiday nights doing some coding – so I’ve put together this list of “The Best of Native Development for 2012″.

Cascades WebcastsThousands of developers from across the globe joined us for four webcasts to learn beginner to advanced Cascades concepts. We were able to interact with developers directly, answer questions, and get immediate feedback as samples and code were displayed. The format proved so successful that we’ve hosted many more webcasts on topics such as the BBM social platform, augmented reality apps, and OpenGL integration.

Porting GuidesIf you have existing content for another platform, we are making it easy to bring that content to the BlackBerry 10 platform. Being able to re-use code across platforms reduces development and maintenance costs. Distributing your application to multiple platforms opens you up to whole new market segments and increases your potential user base. There a number of informative porting guides available to help you build for BlackBerry 10.

Samples
The best and easiest way to learn to program is to look at sample code. For every feature that BlackBerry 10 offers there is a sample project showing you how to put it into action. Whether it’s integrating with BBM, using the Invocation Framework, getting sensor information, or communicating via Bluetooth, we’ve got you covered.

There are samples built right into the Momentics development environment, on the Cascades and Native microsites, and hosted on our github repo. And if you find a feature that we missed, or an API without a clear example then let us know on Twitter @BlackBerryDev or in our developer forums and we’ll add what you need to get started!

Stump the BlackBerry DevsIn August we launched a challenge to the BlackBerry Developer community to come up with a UI that would be difficult to implement in the Cascades UI framework. The Cascades tools development team would try to implement the submissions in a flexible manner that could handle multiple screen resolutions and form factors. They implemented three of the challenges and presented the solutions during the Unconference Day at BlackBerry Jam Americas. We were able to show that Cascades is robust framework that is able to create stunning interfaces even when faced with challenging design requirements. All the solutions are hosted on ourgithub repo.

If you have any Cascades or native dev questions – check out our forums and connect with me on Twitter.

]]>http://devblog.blackberry.com/2012/12/the-best-of-native-and-cascades-development-2012/feed/0Alex K.TITLE_IMAGEBlackBerry 10 Community Port-A-Thonhttp://devblog.blackberry.com/2012/12/blackberry-10-community-port-a-thon/
http://devblog.blackberry.com/2012/12/blackberry-10-community-port-a-thon/#commentsFri, 21 Dec 2012 17:50:10 +0000http://devblog.blackberry.com/?p=12828/ Read More]]>Community developers we have you covered! We want you to be part of all of the BlackBerry 10 excitement and bring us your applications. After the success of our previous Port-A-Thons we are bringing you our BlackBerry 10 Community Port-A-Thon. Do you have a mobile app created using Appcelerator, Maramalade, Sencha, jQuery, PhoneGap, Qt or other platforms? If the app hasn’t already been submitted to BlackBerry World for BlackBerry 10, this Port-A-Thon is for you! Android apps are not eligible but you can check out our Android portathon here.

The BlackBerry 10 Community Port-A-Thon will start on noon ET January 11, 2013 and run for 36 hours. This is also going to be a virtual event, so it is up to you to decide where you would like to join us from.

Port ten (10) or more approved apps – THE FIRST TEN (10) QUALIFIED PARTICIPANTS one (1) paid trip to BlackBerry Jam Europe to celebrate the launch of BlackBerry 10 with us plus a Dev Alpha Device as well as $100!!!

Additionally for those that did not receive a BlackBerry Dev Alpha, or Trip to BlackBerry Jam Europe, we will be conducting a random draw for one hundred (100) BlackBerry 10 Dev Alphas and ten (10) trips to BlackBerry Jam Europe. All those who meet the criteria for a Dev Alpha Device or the Trip but were not one of the firs 200 or 10 , respectively, to qualify, are eligible for the respective draws.

Get Ready to Port

Take advantage of the tips below to get a head start before you join the event.

Request signature keys. Make sure that you select for BlackBerry® PlayBook™ OS and BlackBerry 10 and higher. Downloading in advance is strongly recommended as the time involved to do so could prevent you from earning rewards.

* A total of $500,000USD is available for distribution. To qualify for a Reward, you must register on the website at http://developer.blackberry.com/offers/communityportathon and submit your App into the BlackBerry World Vendor Portal between 12:00:01 pm on January 11, 2013 and 11:59:59pm ET on January 12, 2013. Any apps submitted outside this time frame are not eligible for this Reward program. Only those apps that have been approved through BlackBerry World and RIM will be considered towards a Reward. No purchase necessary to be eligible for the draw. The odds of winning the draw depend on the number of eligible Vendors entered. Skill-testing question applies to Canadian residents. Limit one (1) Dev Alpha Device and one (1) Trip per person. Cash rewards limited to 20 per Vendor regardless of reward category. See the Official Terms and Conditions for complete details.

Qt is an important part of our BlackBerry 10 Cascades framework. We were proud to be part of Qt Developer Days in Santa Clara, where we had our own booth set up to showcase the BlackBerry 10 OS and to speak to developers about the excitement surrounding the upcoming BlackBerry 10 launch event on January 30th (not long to go now!). Some developers did not really know what BlackBerry 10 was but after seeing the platform for themselves, they shared our excitement. This was a user interface that they had not seen before, and something a lot of the MeeGo community liked with its simple but powerful gestures.

Alec Saunders, VP Developer Relations at RIM, had a keynote speech where he presented our BlackBerry 10 ecosystem story. He also spoke to RIM’s involvement with Qt and how developers can be rewarded for porting their Qt applications to BlackBerry 10. BlackBerry World is a going to be a level playing ground for your applications to actually have a chance of being discovered and not lost in the crowd like on other platforms.

We seeded eager developers with BlackBerry 10 Dev Alpha testing devices for them to port over their existing MeeGo / Symbian Qt applications, and also provided technical support. For Qt Mobile Application Developers, BlackBerry 10 offers the ability to get a return on your existing development investments. Depending on the complexity of your application, the port over to BlackBerry 10 can really be a painless experience.

We do realize that not everyone can get to these events, and so we have the BlackBerry Qt Porting Program, an online offer so that eligible developers can get their hands on BlackBerry 10 Dev Alpha testing devices. For complete details, see the Official Program Terms and Conditions.

We also have an offer of a one-time donation of $10,000 USD to the Qt Project Hosting Foundation if 50 eligible Qt apps are ported to BlackBerry 10 by the Qt Community and then posted and available for sale in BlackBerry World by January 30, 2013 (1)

Apps must be submitted to BlackBerry World by January 20, 2013 and be approved.

50 Qt apps must be up for sale in BlackBerry World by January 30, 2013.

It was fantastic being part of Qt Developer Days in Santa Clara, but this is really just the start for us and by no means the end. We are actively working with Digia and the Qt foundation to further strengthen Qt and our relationship with it and also with you.

1) To be eligible, fifty (50) Qt Apps (“Apps”) must be submitted to BBAW by the Qt Community by 11:59:59 PM Eastern Time (“ET”) on January 20, 2013. Apps will be accepted beginning at 8:00 AM ET on December 8, 2012. Allow a minimum of ten (10) days for BBAW approval. Approved apps must be posted on BBAW for sale on or before January 30, 2013. Apps are not eligible if they simply contain a web launcher or shortcut or a web browser (“Excluded App”). RIM will confirm if Qt Community is eligible for $10,000 USD donation to the Qt Project Hosting Foundation (“Donation”) by February 28, 2013. Allow 8-12 weeks for delivery of Donation. Void where prohibited or restricted by law.

Since the introduction of Cascades in May, developers have been asking us one question: Is there something I can do to make my app start faster? Cascades is a marvelous piece of technology, but like any new technology, it takes time to work out the kinks and optimize performance. It took a while, but the Cascades team figured out a way to make it faster. Let me introduce you to Project Zygote.

When a detailed performance analysis was conducted on a Cascades application while it was starting up, it was discovered that loading shared libraries was taking up the majority of time. Cascades uses a number of different Qt and platform-specific libraries, so this made sense. After some investigation, we learned that you can save a lot of time by pre-compiling these shared libraries into one library that could be pre-loaded. Thus, Project Zygote was born.

How do you get in on the party? With this latest beta release of BlackBerry 10, all new Cascades projects will have Zygote enabled by default. You get it for free!

For those with pre-existing projects, there are some minor changes you need to make to your existing projects to enable Zygote for your release target. A little bit of work that goes a long way!

Let’s start by looking at the original project file for the Cascades Cookbook sample app:

As mentioned earlier, Zygote is configured primarily for release targets. The reason behind this is that the differences in packaging make it difficult for developers to debug applications built in this way. The first step to upgrading the project configuration is to add a template override from app to lib in the device-release configuration section:

After making these changes, export your project to a zip file. If you haven’t already done so, create a new workspace. Import the project into the new workspace, change the active build to Device-Release, and clean and rebuild the project. You should have a Cascades Cookbook sample app that starts up faster! My testing showed a reduction in start time from 1.96 seconds to 0.68 seconds. Feel free to convert all of your Cascades apps and spread the word!

Have a BlackBerry 10 Dev Alpha testing device, but hit a few stumbling blocks and need some help to just get it moving again?

Got an Android, iOS or Qt app that you want to port to the platform?

Are you an HTML5 dev with a great app that could be a hit on BlackBerry 10?

Then look no further! We are holding a series of open days at our Tech Centre in Slough in December with a technology focus for each event! Just book your place at the event that suits you, come along and spend the day with our experts who will guide you through the process and give you some one to one help with your development issues.

Cascades™ and Qt are two major frameworks available on the BlackBerry® 10 platform. Qt on BlackBerry 10 provides a complete set of standard Qt 4.8 APIs with the exception of the QtWebKit module. BlackBerry 10 provides a selected set of APIs from the QtMobility project as well. I will provide an overview of Qt 4.8 APIs coverage on BlackBerry 10, with a focus on APIs that are different or not available on BlackBerry 10, and will refer to alternative Cascades APIs in relevant cases. More details are provided here:https://developer.blackberry.com/cascades/reference/qt_index.html

To start, I wanted to share two fundamental facts about the use of Qt within Cascades and Qt on BlackBerry 10 in general:

1. Cascades uses its own backend to render on the screen. This backend does not use Qt because Cascades needed several features, which Qt addresses only starting with Qt5. Developers have to decide upfront if an application will use Cascades or Qt to render on the screen, because it is not possible to mix Qt and Cascades APIs to access the screen in one application. Developers can write “pure” Qt Quick or QWidget apps and have the app directly deployed and run on the BlackBerry 10 platform with little or no platform adaptations. Cascades apps can use all Qt APIs which do not access the screen; e.g. the modules QtCore, QtNetwork, QtSql, QtXml.

2. QtMobility APIs have been developed, published and maintained in a separate project outside of the Qt 4.8 base line; therefore QtMobility does not belong to a standard Qt4 package. QtMobility should be separately built and integrated into mobile and embedded platforms based on Qt4. Since the work on QtMobility was focused on standards and services used by Nokia devices, the use of these APIs on modern platforms provided by other vendors requires changes. This applies to the BlackBerry 10 platform as well. The current release of BlackBerry 10 therefore provides a subset of QtMobility API implementation.

In addition to the Cascades UI framework, RIM® has created a rich set of middleware Qt-based APIs to access the key BlackBerry 10 features. Since these APIs do not render to the screen, they can be used in Cascades apps as well as in applications based on Qt widgets and Qt Quick.

Using Qt widgets with C++ on the BlackBerry 10 platform

Qt widgets are fully supported on the platform and included in the BlackBerry 10 NDK. Even though almost no changes in the code are needed to get a Qt widget-based application running on BlackBerry 10, this approach will rarely provide acceptable results. Qt widgets have been developed for desktop applications and only few of them are suitable for a mobile platform. For example, QButton, QCheckBox or QProgressBar can be effectively used, but using QMainWidow or QDialog in an app for a mobile device does not make much sense. Moreover, the implementation of animations and effects in widget based UIs requires considerable effort or can even be not possible in some cases. Cascades and Qt Quick provide much better solutions tailored to use cases on mobile devices.

Qt in the current Beta releases of the NDK and on Dev Alpha devices uses a default style for Qt widgets. The final version will contain a style tailored to the appearance of the BlackBerry 10 native UI elements.

Developing with Qt Quick

Qt Quick 1.1 is fully supported on the BlackBerry 10 platform as a part of Qt 4.8 package. Additional Qt Quick plugins provided in the QtMobility package are supported according to their general availability on BlackBerry 10.

Developers who used Qt Quick on a desktop platform should note that the “qmlviewer” application is not available on BlackBerry 10. The security and deployment models on BlackBerry 10 require using own C++ code to load Qt Quick files. An example of this code in provided in Qt as well as in the template application which can be created in the category “BlackBerry Qt Quick Application” via the “New Project” wizard in QtCreator 2.6 and newer.

Qt Quick applications intensively using animations and transitions should use QGLWidget as a view port in QDeclarativeView. Using QGLWidget will enable hardware acceleration and therefore usually provides better rendering performance.

When it comes to the UI development, Qt Quick is a good choice when an application needs its own custom appearance with a custom set of UI elements, or when the application code should be ported from another platform to BlackBerry 10. Since Qt Quick 1.1 does not provide high-level UI components, developers have to provide an implementation of these UI elements. If an application needs an authentic BlackBerry 10 look-and-feel and a seamless integration with the platform, using Cascades UI framework is a much better approach.

QtMultimedia

This module is deprecated and not supported. Please use QtMultimediaKit from QtMobility instead.

QtOpenGL

QtOpenGL is fully included in the BlackBerry 10 NDK. However, QtOpenGL APIs cannot be used in a Cascades app. Please check the Cascades documentation to find how to use OpenGL in Cascades apps.

QtScriptTools

QtScriptTools is fully included in the BlackBerry 10 NDK. However, QtScriptTools APIs cannot be used in a Cascades app. Cascades apps use QScriptEngine as described in the BlackBerry 10 documentation.

QtSvg

QtSvg is fully included in the BlackBerry 10 NDK. However, QtSvg APIs cannot be used in Cascades apps.

QtWebKit

QtWebKit is not supported, but RIM is planning to include a solution in later releases of BlackBerry 10.

QtTest

QtTest is fully included in the BlackBerry 10 NDK. However, QtTest APIs cannot be used in Cascades apps.

Not supported

Phonon

Qt3Support

QtDesigner

QtUiTools

QtHelp

QAxContainer

QAxServer

QtDBus

APIs from the Qt Mobility 1.2 project:

QtNetwork

Most of these APIs have been included in the Qt 4.8 and are supported on BlackBerry 10.

The QtMultimediaKit module is included in the BlackBerry 10 NDK except for QMediaRecorderControl (and so no QMediaRecorder) and Camera APIs. Development teams in RIM are working to provide support for these and other modules in the future. It is important to note that QtMultimedia APIs in Qt 4.8 have dependencies on the QtGui module and so they cannot be used in Cascades apps. Cascades app should use MediaPlayer APIs instead.

RIM is currently working on adding support for NFC and Bluetooth®. BlackBerry 10 also provides the QtNfcSubset module which provides access to NFC on enabled BlackBerry 10 devices. More details will be provided in the BlackBerry 10 documentation.

Following modules are not supported:

QtServiceFramework

QtContacts

QtMessaging

QtSystemInfo

QtPublishSubscribe

QtOrganizer

QtFeedback

QtGallery

QtVersit

Related Resources

We are planning to provide more detailed documentation about Qt applications on BlackBerry 10 in the next blog posts. In the meantime, please find below some selected links related to Qt on BlackBerry 10:

Happy Qt development for BlackBerry 10! Please note that RIM is committed to Qt and is continuously working to expand the selection of own add-on modules as well as standard modules provided by Qt in the future.

Qt developers and BlackBerry® 10 developers often ask the following questions:

What is the relationship between Cascades™ and Qt, and how do they interact with each other?

Cascades and Qt frameworks are two major frameworks available in BlackBerry 10 application development. From a high-level architectural point of view, you can say that Cascades sits on top of Qt modules as it is built, using the Qt application framework leveraging Qt object model, event model and threading model. This also uses QtCore, QtXML, QtSql, QtNetwork and QDeclarativeEngine for QML components. Both frameworks use standard C++, signals and slots in Qt for inter-object communication. However, Cascades uses own UI rendering engine and does NOT use any QtGui functionality, while Qt uses raster and the OpenGL graphics engine.

BlackBerry 10 supports BOTH Cascades and Qt

The key point here is that BlackBerry 10 supports BOTH Cascades and Qt frameworks. If you have developed an application using Qt framework for other platforms, you can deploy and run the application on BlackBerry 10 with the minimum effort of fixing a few compile and runtime issues. The downside of this approach is that your application may not have consistent look and feel with the BlackBerry 10 platform, nor have the best integration with the platform itself.

Cascades includes a set of core UI components and platform APIs to create interactive applications accessing the underlying features of the BlackBerry 10 platform. Cascades UI components are designed to have a consistent look and feel, and are optimized for BlackBerry 10 integration such as touch screen interactions. You can use Cascades Builder, the main development tool, for creating BlackBerry Native applications, which is built into the QNX Momentics IDE. The UI preview and the components view are specific features of Cascades Builder when editing QML. Cascades Builder is also integrated to access the BlackBerry platform features and services like audio/video, camera, Ad Service, app integration, BBM™ Social Platform, external data storage access, file system access, internationalization, location, payment service, PIM (Personal Information Management), push services, networking, notifications and sensors. To learn more about the Cascades framework, see Introduction to Cascades.

When porting a Qt application to BlackBerry 10, you can access the same subset of Qt APIs directly without using wrappers for BlackBerry 10. This is powerful and convenient for Qt developers and Qt applications. If you have any Qt applications using Qt APIs such as QGeoCoordinate or QSensor, the same APIs are available and accessible on BlackBerry 10. Currently, the subset of QtCore, QtNetwork, QtLocation, QtSensors, QtSql and QtXML modules are supported. You can check out our sample applications to learn more about these APIs.

Which Framework to Choose to Port your Qt Application?

We recommend that you choose Cascades framework if you are developing a native look-and-feel application on BlackBerry 10 and want to maximize the platform integration. If you are planning to develop an application with specific and customized GUIs, you can choose Qt framework. The decision has to be made before you start writing your application, however, since you can’t mix the UI components between Cascades and Qt. We will walk you through the porting tips based on the framework in the following section.

Basic Step-by-Step for porting a Qt application to BlackBerry 10

If you choose to use Qt Creator, download and configure Qt Creator 2.6 for BlackBerry 10 development. This version is recommended since it has the full support for BlackBerry 10 development including BlackBerry® PlayBook™ tablet and QNX. In order to deploy an existing Qt application project in Qt Creator, you need to add the kit which you defined for BlackBerry 10 to your project. Read the configuration instructions.

Some of you may have noticed that the Beta 3 release of the BlackBerry® 10 Native SDK got a bit quieter in the console when creating Cascades™ applications. As of Qt 4.8.3, all output that used to code to the console (qDebug(), qWarning(), qCritical() etc) is now output to slog2. This not only affects the logging from C++ but also any console.log() JavaScript logging done from within QML as well as error messages at runtime. No console output can make troubleshooting even simple issues very frustrating. Luckily there are a few workarounds detailed in the “Known limitations” section of the release notes that can get you access to the logging information.

1) This workaround gets you the logging information back to the console, but should be removed prior to publishing your application to the BlackBerry App World™ storefront. Either of the following can be done:

a. Use the fprintf() function with stdout or stderr as the output stream to receive output directly to the console. This is easy to do to add in-line console output from C++, but will not restore logging to the console from QML.
ex fprintf(stdout, “I am a console message\n”);

b. Register your own message handler with the application to have all qDebug() (etc) and QML output handled however you wish (including using fprintf() as mentioned above). To do this, open your main.cpp file (the default main file for a Cascades application) and add a function similar to the following above the main method:

BlackBerry® is serious about developers, serious about applications, and serious about Qt. With this in mind, we are asking for all you Qt ambassadors and Qt superstars to try porting your Qt applications over to the BlackBerry® PlayBook™ tablet and upcoming BlackBerry® 10 smartphones.

For you to be a member of the “Qt on BlackBerry and QNX” group (if you are not, then please register to become a member)

Send a proposal of the application(s) you will / are considering porting or have ported

Send us a link to where you will make your code available OR if you do not to make the code public, then please provide us evidence that you are developing using Qt

In return, you will be automatically entered into our weekly draw for a free BlackBerry PlayBook tablet. We even have Mondays reserved for Qt porting at the BlackBerry Tech Center in Slough, UK if you need some in-person help.

Sounds good? Log on to the Qt Project website for all the links and info!