For the first few posts in our Super Apps series – in the Java® stream – I wanted to talk about the BlackBerry® platform’s ability to allow applications to run in the background and on startup. This ability is important to a few of the Super App aspects, notably the “Always-on Experience,” and in making your app “Proactive and Notification-driven.” It’s also part of the “Tight Integration with the Native Apps” concept, as we’ll see later. Above all, a true Super App will be “Designed for Efficiency,” particularly when running in the background.
In this series of posts, we’ll look at several aspects of running in the background, as well as application states and how to be efficient. With this amount of material to cover, we’ll spread it over four parts. First, let’s look at how to make an application start automatically and never close, and when you’d want to do so.
The simplest example of running in the background – the literal creation of the “Always-on Experience” – is to make an application run at startup and never close. Making an application start automatically is done in the BlackBerry® Java® Plugin, by editing the BlackBerry® Application Descriptor and checking the “Auto-run on startup” checkbox.
Having made the application start automatically, the next step is to keep it running. The default behavior when the last screen is popped off the stack is to close the application. To make an application move to the background instead, override the onClose() method of the Screen to call UiApplication.getUiApplication().requestBackground().
Keeping the application running all the time is a model followed by some core apps, and this makes sense for an application that the user will frequently switch to, like messaging and IM clients. However, users will not thank you for cluttering up their switch application dialog without reason. Ask yourself this: How often will a user want a way to switch to your application quickly, that isn’t already provided through another mechanism? Also remember that you will want to stop any UI processing and release unneeded resources when you go to the background. We’ll cover this in more detail in the fourth part of this series.
Most likely, you will only want to run part of your application in the background to do certain processing or to listen for events. In this approach, your application could be separated into two parts: the UI portion that the user opens and closes as needed, and the background process which listens for specific events, such as pushed data. This is a more common model that will serve the majority of Super Apps well.
You may not need to leave the background process running all the time. Many integration options are configured during startup, such as the Homescreen icons, or ApplicationMenuItems. If your application doesn’t need to process incoming messages, your background processing can be minimized.
Check back soon as we dive into using Alternate Entry Points, and setting up a background process to listen for pushed data and other events.
Any questions so far?