Upgrading to 10.2 Gold

This document lists the major changes that affect applications that are upgrading from the 10.2 beta API level to the 10.2 Gold API level of the BlackBerry 10 Native SDK. Upward compatible changes are not listed here.

Here are some links that you can visit for more information:

  • For more information about functionality in the 10.2 Gold release and known issues that affect this upgrade, see the 10.2 Gold release notes.
  • If you are interested in upgrading to the 10.2 beta release, see Upgrading to 10.2 beta.

Changes to APIs

PNG library (libpng library)

The libpng 1.4.x library has been deprecated. Use libpng 1.6.x instead. For more information, see the libpng manual at http://www.libpng.org/pub/png/libpng-manual.txt.

Cascades accessibility APIs (abstractaccessibilityobject.h)

The AbstractAccessibilityObject class has been renamed to AbstractA11yObject. For more information about accessibility, see Accessibility and the Accessibility APIs.

Sound library (asound.h)

The following enumerated value has been removed:

  • The value SND_CHMAP_BB_FCT has been removed from the snd_pcm_chmap_position enumeration.

A reminder about signal-slot connections

To ensure that your app works as you designed, you must evaluate the Boolean value that is returned by the QObject::connect() function. A signal-slot connection fails if the sender or the receiver objects are invalid or the types of the signal arguments are not registered in Qt as meta-types. In these cases, Qt generates a warning that is posted to slog2info logs on the device.

This situation is a critical error. A signal-slot connection is not established, which means that the execution flow of your app is not correct and your app might behave unexpectedly. For example, you might encounter strange UI behavior, memory leaks, device crashes, and so on. Your app assumes that the connection has been established and that the signal will arrive when it is sent, but this never happens.

You must resolve any signal-slot connection failures before publishing your app for distribution on the BlackBerry World storefront.

Recommended solution

You should use the Q_ASSERT() macro to evaluate the return value of connect() as suggested in Signals and slots. This technique affects only the debug builds of your code, because the release builds define QT_NO_DEBUG, which disables Q_ASSERT(). Because all apps and libraries (including Qt) are released in release mode (not debug mode), the handling of the connect() return values using Q_ASSERT() will not have any effect on published apps. This technique has no code to recover from a failed connection because it assumes that there is no safe recovery.

// If any Q_ASSERT statement(s) indicate that the slot failed 
// to connect to the signal, make sure you know why this happened. 
// This is not normal, and will cause your app to stop working!
bool connectResult;
// Since the variable is not used in the app, this is added to avoid 
// a compiler warning.
connectResult = QObject::connect(smokeDetector, 
// This affects only Debug builds.

Alternate solution

You can also check the return value of the connect() function using an if statement and add some code to recover from the failed connect(). You can use qWarning() to send a message to the console. This technique should not be used to recover from coding errors. If a signal-slot connection fails because of an error in code, it should be fixed before it is published to users.

if(!connect(...)) {
   qWarning("Recovering from the failed connect()");
   // Add your code here to make sure that your app 
   // still works correctly, even though this connection 
   // has not been established.

You can also set the QT_FATAL_WARNINGS environment variable in your bar-descriptor.xml file. If the QT_FATAL_WARNINGS environment variable is set to 1, your app will exit after qWarning() prints the warning message.

Another alternate solution

If you think that recovery is impossible because a successful connection is critical to your code, you can use qFatal() to close the app immediately. You can also consider adding additional code to clean up before closing the app.

if(!connect(...)) {

   // If your app uses shared files, write details about what
   // happened into a log file and ask users to send it to you.
   // Make sure that you save as much user data as possible.
   // Consider notifying users about the fatal error and 
   // warning them that the app will close now.
   qFatal("Cannot recover from the failed connect()");

Last modified: 2015-03-31

Got questions about leaving a comment? Get answers from our Disqus FAQ.

comments powered by Disqus