BlackBerry Apps That Won’t Die

Starting BlackBerry applications

Despite the proliferation of iPhone and Android applications running about the globe, BlackBerry still matters.

At least for a while — and who knows, maybe they will always be a player. I for one am not ready to write them off just yet.

Building on the idea of “running forever”, in this article we take a look at a technique for launching BlackBerry applications that need to run continually.

Broadly speaking third party BlackBerry applications come in a couple of basic forms: user-started and system-started.

A user-started application is an application that is initiated by the user selecting the application’s icon from the home screen. When initiated, the application launches and the user interacts with the application as expected. Because the BlackBerry OS is capable of multi-tasking, the application can persist for sometime until it is selectively shutdown by the user.

A system-started application is launched when the device boots. After all of the core system level applications are initialized, the OS starts any applications which have been marked as “Auto-run on startup”.

Auto-run application when the device boots

What kinds of applications would be set for auto-run? Applications which respond to events are good candidates for auto-starting and running “in the background”. For example, a BlackBerry application can listen for phone calls, emails, text messages, in holster, out of holster, low memory, and lots of other “events of interest”.

Regardless of which option is chosen, auto-run or not, the entry point to a BlackBerry application is the same, namely the main method:

public static void main(String args[]) {
	MyApp theApp = new MyApp();
	theApp.enterEventDispatcher();
}

The main method is called once by the operating system to launch the BlackBerry application. The method is marked as public static and has no return type, i.e. “void”.

The method is a static method of the application class which extends the UiApplication class. So a typical BlackBerry application looks like this:

package com.linuxmag.mypackagename;

import net.rim.device.api.ui.*;
import net.rim.device.api.system.*;
// add other import statements here

class MyApp extends UiApplication {
	// constructor
	MyApp() {
	}

	public static void main(String args[]) {
		MyApp theApp = new MyApp();
		theApp.enterEventDispatcher();
	}
}

Upon entry of the main method, an instance of our application class is instantiated with the new keyword. Then we ask the class to enter into its event dispatching loop which runs for the duration of the application.

This sequence of events takes place each time the application icon is selected and the application is started.

With an auto-run application, this sequence happens only once when the device boots. Generally speaking, this is not a problem as an auto-run application is generally written to run continuously in the background.

So if the application runs forever, why do we care about how it starts up?

Bean counting

When designing an application on the white board, we often don’t (adequately) plan for the unexpected. The unexpected should not always be the unexpected I confess, however there comes a point where we sometimes need a solution to a problem we either created ourselves or inherited from someone else — as is often the case in the world of software development and application maintenance.

I recently had an opportunity to sort out why an application would crash every now and again and only on some devices.

My first instinct on this sort of problem is to add some carefully placed logging into the application and try to reproduce the problem. This can sometimes be a laborious (read: expensive) process. In this situation, time and dollars are not readily available to perform the potentially exhaustive search for the villainous and offending code, so after “counting the cost” I decided it was better to find a means to just keep the application running and over time we will find the root cause. In the meantime, I need to keep this application running. The solution called for a means to restart the application if, and when, it crashed.

Restarting automatically

It turns out that the BlackBerry platform supports an “auto-restart” flag for applications. If this flag is set and the application is terminated (for whatever reason), the application is restarted. Great, that will solve my problem!

Almost.

The trick is that this flag cannot casually be set in the properties dialog in the same manner that we set the auto-run flag. In order to solve this riddle, we have to actually let the application start in the usual manner and then selectively re-start it with the important flag set.

public static void main(String args[]) {

        if (args.length == 0) {
            System.out.println("running once, setting up restart");
            ApplicationDescriptor descr = ApplicationDescriptor.currentApplicationDescriptor();

            ApplicationDescriptor newDescr = new ApplicationDescriptor(descr, descr.getName(), new String[] { "startmeagainplease" },

                    descr.getIcon(), descr.getPosition(), descr.getNameResourceBundle(), descr.getNameResourceId(),

                    ApplicationDescriptor.FLAG_AUTO_RESTART);

            ApplicationManager.getApplicationManager().scheduleApplication(newDescr,

                    System.currentTimeMillis() + 30001, true);
            System.exit(0);
            return;
        }
        System.out.println("restarted !");
       MyApp app = new MyApp();
        app.enterEventDispatcher();
    }

Here is the basic sequence of events:

1. The application is started, either by the system at boot-time or via a user clicking on its icon.
2. The code examines the arguments (args.length) and determines that it needs to run the restart sequence.
3. We get a copy of the currently running Application’s “descriptor”.
4. We prepare to re-start the application and this time add a “command line argument”.
5. We make sure to include the Application.Desriptor.FLAG_AUTO_RESTART flag!
6. We schedule our newly constructed descriptor to be launched.
7. We exit the application
8. When the application fires again it will have the command line argument and will proceed in the “usual manner” by instantiating our class and entering the event dispatch loop.

One more item to note here is the duration used in the scheduling of the application launch. This time needs to be sufficiently past the original start-up to run properly. This snippet sets the application to “relaunch” just over 30 seconds (30000 milliseconds is 30 seconds) from the time of running the main method.

My first pass at this with a delay of 10 seconds turned out to be not quite long enough. I have seen some samples of similar code where the delay was 60 seconds. So, your mileage may vary.

The implication of this longer delay is that the application may not be actually running until 30,60 or more seconds after the phone reboots, depending on where you wind up with this delay. This may or may not be an issue for your particular situation, but it is something to be mindful of.

Please let me know if this is of value to you and if you have other ideas for “bean counting” solutions for BlackBerry or other mobile platforms. You can email your ideas to me at fableson at navitend.com