BlackBerry Java to BlackBerry 10 Cascades Porting Series – Part 2: Application Life Cycle

Native SDK Development

Guest post from Roberto S. – Ed.

In Part 2 of this series, we would like to introduce BlackBerry Java developers to what has changed with respect to application lifecycle in BlackBerry 10, and what you should be aware of when you port this aspect of your application to Cascades.

All BlackBerry 10 applications have a similar lifecycle that includes three possible states: running in the foreground, running in the background, and stopped.

  • An app running in the foreground is visible and is taking up the entire screen.
  • An app running in the background is either displayed as a thumbnail, such as when a user swipes up from the bottom of the screen to display a list of running apps, or is invisible but has the run_when_backgrounded permission to run in the background.
  • An app that is stopped is not visible and doesn’t have permission to run in the background.
  • An app that is pooled (the app is paused and ready to be opened in the foreground)



Developers porting their apps from BlackBerry OS will need to take this into account and make the following changes to their apps:

  1. Unlike in BlackBerry OS, apps do not have an extra entry point available to them for starting up a background thread at startup, or for modifying theirs icons. Homescreen Icons are not modifiable in BlackBerry 10 so any such logic is not portable as is. However, the active frames feature allows developers to customize their frames when minimized. Therefore, this may allow some of the icon logic to be applied to the cover instead on a BlackBerry 10 version of the app. For more information about Active covers, go to .
  2. Background services capabilities are currently not available to third party developers. They will be available in a future release of BlackBerry 10. Developers relying on background services to poll servers for updates or execute code when they are not running will have to implement an alternative approach for the time being. The alternative currently recommended is to use push to launch your apps when new data is available. With Push, your server side application can poll for new data on behalf of the client application and deliver any new data in a push message which can be processed even if the client application is closed. Check out this recent blog post on push for more information: .
  3. To handle the life cycle changes that occur in your app, there are several signals made available to Cascades apps that an app developer can intercept and process accordingly. For more details on application lifecycle and the various signals available, go to and for more information. The developer must take their state into consideration and reduce app activity accordingly:
    • When your app enters the thumbnail state, it should stop any extraneous processing and use only the resources it needs to update the cover or maintain critical functionality like maintain a server connection or check a remote server for updates. Your app should stop other threads that aren’t required when running in the background. Examples of what to stop are rendering, multimedia playback, audio playback, etc.
    • The invisible signal is emitted when the app (and its thumbnail) is no longer visible. This state might occur if the device backlight is off or if another app has been brought to the foreground. When your app is in this state and doesn’t have the run_when_backgrounded permission, it is considered stopped and won’t receive any processing time. If your app does have the run_when_backgrounded permission, your app should stop any rendering operations (for example, updating the UI) and any other unnecessary operations. Your app should only listen for events that it needs to respond to, and process these events when they occur.
    • It is very important for applications to reduce processing as much as possible while thumbnailed or invisible. It will conserve CPU usage and also save on battery life. This is an important criterion that is taken into consideration when applications are evaluated during the BlackBerry World approval process.
  4. When a user closes your app, your app usually needs to perform some final cleanup operations, whether it be saving the user’s data, shutting down your threads in a particular way, or manually closing the app database or network connections. Cascades provides developers with a choice of automatic or manual exit mechanisms that they can take advantage depending on their cleanup needs.
  5. BlackBerry OS developers should be aware of the fact that C++ does not have automatic garbage collection like Java does. However, Qt does provide some built-in mechanisms that provide limited object cleanup. Please refer to the API references for QObject and other QtCore classes like QSharedPointer for additional information on how to manage pointers and automatically delete objects after use. For more information about object ownership in C++ and QML and what that entails, go to
  6. The new pooled state is designed to take advantage of the extra memory added to BlackBerry 10 devices. The system sends a signal to the app to prepare to be pooled. The app is expected to reset its UI t o a point that matches startup conditions and signal back that the operation is completed. If the app fails to do this, the app will be terminated.
  7. Another limitation to be aware of is that currently only eight apps can run at the same time on BlackBerry 10. As a best practice, developers should ensure that any apps launched in the background to process push events should exit as soon as possible if user interaction is not required or if they launch a notification to alert the user to launch the app later. This will prevent push interactions from bumping up the number of running apps for more than a short period of time.

Please stay tuned for series Part 3 – UI Overview.

Join the conversation

Show comments Hide comments
+ -