At this point in our blog post series, we’ve looked at making applications start automatically and remain running in the background (part one), as well as how to use Alternate Entry Points to run a process in the background or to do setup tasks (part two). Now let’s look at making an application move between foreground and background states, and what can trigger an application to do so.
The BlackBerry® platform is a multi-process, multi-threaded operating system, which today supports up to 64 concurrent processes – each with up to 64 threads. Applications can move easily between the foreground and background by both the user’s actions and through various other triggers. Let’s look at some of the ways that an application can transition between these states.
BlackBerry users will be familiar with the Switch Application Dialog which is accessed through the menu, or by holding Alt and pressing the Esc key. This dialog appears on top of the currently-running application – partially placing it in the background – and allows the user to switch to another running application by selecting the application icon from the list in the dialog. Upon selection, the selected application will be brought to the foreground, and the currently-running application will move to the background.
The green and red Phone keys will also change the foreground application. The green key, otherwise known as the “Send” key, will launch the user into the Phone app. The red, or “End” key, will send the current application to the background and return the user to the HomeScreen. Similarly, the convenience keys are used to launch applications, taking the foreground from the current application.
Your application or another can also trigger a change of foreground application, using APIs like Invoke, ContentHandler (CHAPI), or ApplicationManager. As shown in the first post of this series, an application can request movement to the foreground or background through the methods requestForeground() and requestBackground(), which are in the UiApplication class.
Finally, notifications and other global events – like incoming phone calls – can take the foreground from the current application. Applications are able to present Global Dialogs to the user, pushing the current application to the background. The Lock Screen will also take precedence over all applications.
Given all those triggers, it becomes clear that moving between the foreground and background is a very common part of the BlackBerry platform. Let’s look at how your application is notified of a change in this state: A BlackBerry Java® Application will have its activate() method called when it comes into the foreground, and the deactivate() method called when it goes to the background. By default these methods do nothing, but they can be overridden to make the application intelligently respond to its state. J2ME developers need to be aware that MIDlets will also support background processing. The MIDlet startApp() and pauseApp() methods will be called, but the application is not forced to stop processing.
When talking about changing application states from foreground to background, it’s important to discuss the Backlight. When the Backlight goes off, the foreground application doesn’t move to the background, so the deactivate() method is not called. However, using a SystemListener2 provides a backlightStateChange(boolean) event when the Backlight state changes. The system will pass a true value in when the Backlight turns on.
Besides listening to the Backlight state, some apps will need to keep the Backlight on while their app is running. The Backlight class provides this feature, and some implementation details are available in our Knowledge Base’s Backlight article. It’s important to keep in mind that keeping the Backlight on takes power and should only be done with reason; in particular, don’t keep the Backlight on if the user is not even using your application. If you implement a loop to enable the Backlight, include a call to UiApplication.isForeground().
Now we’re starting to get into the topic for the fourth post in this series, which is efficiency. We’ll look at efficient memory, battery and network use, to conclude our series on background processing.
Any questions so far? Please leave them in the comments.