Standby MIDlets

With the Sony Ericsson Java™ Platform 7 (JP-7) phones such as the K610, K800, K790 and W850, a feature that lets the developer create a Java wallpaper was introduced. Just like assigning pictures and themes as wallpaper it is also possible to select Java applications for this purpose. A standby application is a powerful alternative to images or flash wallpapers exposing all features of a normal MIDlet presenting itself as a normal wallpaper. Furthermore a standby MIDlet can be brought up to focus by the user, giving interaction possibilities just like any other Java MIDlet installed on the phone.

In order to optimize a MIDlet for running as a wallpaper some steps are necessary to take. This article focuses on the following areas:

• The standby MIDlet lifecycle
• User interaction
• Performance issues
• Battery consumption
• Changes to the Java platform
• Code example

Standby MIDlet lifecycle

A standby MIDlet that is installed as a wallpaper is a constantly running application, even though obstructed by other graphics or even when the phone has gone into hibernation. In order to better understand the different modes of operation of a standby MIDlet the following figure illustrates the MIDlet lifecycle as a finite state machine.



As illustraded above there are several modes of operation for a standby MIDlet. The application manager is responsible for handling the state transitions and notifying the standby MIDlet (events marked in red) of state changes due to change of mode of execution. Because of this a standby MIDlet have to adapt to the current mode of execution. When running, the main modes of exectution are the following:

• (B) Background
• (C) Inactive
• (D) Active

A standby MIDlet mainly executes in "Background" and "Inactive" mode, acting as the current wallpaper. Running in any of those two modes the end-user can't interface with the MIDlet. A standby MIDlet can be activated or put in "Active" mode however (see section "Switching between Active and Inactive mode"), but this requires user interaction. Once running in "Active" mode a standby MIDlet performs just like any other MIDlet installed on the phone. A standby MIDlet must therefore optimize the graphics and user input for the different modes as explained below.

(A) Not running

The standby MIDlet is set as wallpaper but not yet started by the application manager. When a user selects a standby MIDlet as wallpaper the MIDlet is automatically put into this state.

(B) Background

Running in the background without any visible graphics or user input. A standby MIDlet is most of the time executing in this mode. Whenever there is something obstructing the wallpaper (the standby MIDlet is not able to show any graphics) the standby MIDlet is put into this state. Any of the following events might put the standby MIDlet in the background:

• The phone is hibernated and the screen is turned off.
• An ongoing phone call.
• Another graphical element is covering the screen, for example a menu or SMS editor etc.
• Another application is executing on top covering the screen.

Whenever the standby MIDlet is obstructed the application manager will automatically put the MIDlet into the "Background" mode. Once the standby MIDlet is no longer obstructed the application manager will put the MIDlet back into the previous state. The following are normal scenarios:

Running in "Inactive" mode.

• Obstructed: (C)->(B)
• No longer obstructed: (B)->(C)

Running in "Active" mode.

• Obstructed: (D)->(C)->(B)
• No longer obstructed: (B)->(E)->(D)

Since a standby MIDlet is constantly running it must be optimized for background execution. A standby MIDlet must therefore react correspondingly to events signaling that the MIDlet is no longer visible. Since the MIDlet is not able to display any graphics it should pause animations and try to minimize occupied resources if applicable. The following needs special attention when running in the background:

• Phone performance. Constantly rendering graphics or performing computation might dramaticly decrease phone performance.
• Battery consumtion. Constantly rendering graphics or performing computation will lead to heavy battery consumption and a dramatic decrease of standby time.
• MIDlet performance. Since running in the background the MIDlet has lower priority than other applications and execution performance is lower than running in "Active" mode.

(C) Inactive

Running as a wallpaper showing graphics on the standby screen, not taking user input. When a standby MIDlet is running in "Inactive" mode it is able to display graphics as the phone wallpaper. The MIDlet is however assigned a low priority by the application manager. This means that the expected frame rate is considerably slower compared to running as a normal MIDlet. Due to this any heavy execution might be slow and graphics have to be optimized for lower priority. Furthermore, running in "Inactive" mode, the application needs to be quick off the mark. It has only 4-5 seconds to do something useful and show this to the user before the phone hibernates and the screen is turned off. Because of this, the following needs special attention when running in "Inactive" mode:

(D) Active

Running in the foreground taking user input, just like any other MIDlet installed on the phone. A standby MIDlet can be activated or put in "Active" mode (see section "Switching between Active and Inactive mode") by the user. Running in "Active" mode the MIDlet has the possibility to take user input which is very suitable for configuration of the standby MIDlet. Any user interaction should be performed running in this mode. The following needs special attention when running in "Active" mode:

• MIDlet performance. The standby MIDlet will run in with full capacity performing like any other MIDlet installed on the phone.
• User interaction. The MIDlet can react to normal key events making "Active" mode very suitable for presenting configuration screens or any other type of oprational mode requiring user input.

(E) Obstructed

Transitional state due to implementation. When transitioning straight from "Background" to "Active" if MIDlet has been obstructed when running in "Active" mode. Please see the section "(B) Background" describing the transitions between "Active" and "Background" mode.

Switching between Active and Inactive mode

You can put a MIDlet into the "Active" state by pressing the activity key as illustrated below.

• Activate: Activity key->Running apps->Resume
• Inactivate: Red key (JP-8 onwards) or "long back" key (JP-7)

Changes to the Java platform

There has been some changes in the Java platform between JP-7 and JP-8 that affects implementation and performance of standby MIDlets. In JP-8 the "red key" has replaced the "long back key" functionality. There are also new events introduced when going between Active and Inactive mode. In JP-7 permission dialogs for restricted application programming interfaces cannot be answered correctly which has been corrected in the JP-8 platform. One way of working around this is on JP-7 is to get the application signed and request the user to manually set the permissions to "do not alsk" or "blanket" before setting it as wallpaper. To summarize the following are changes that affect a standby MIDlet:

• Red key replaced the "long back" key.
• New events for when a standby MIDlet is brought Active mode / put in Inactive mode in JP-8 (keyPressed and keyReleased events).
• Better security permission dialog handling on JP-8 compared to JP-7.

Assigning an application as wallpaper

Setting an application as wallpaper just involves a few basic steps. This can be done in two ways, either by selecting the wallpaper in the settings menu or by selecting an application as wallpaper in the normal application list.

Selecting the wallpaper


Selecting the application

Code example

There are just a few steps necessary to enable a MIDlet to run properly as a standby MIDlet. Fist you need to add a specific property to the .jad file and secondly you need to implement the support for the different execution modes by reacting to some specific events.

Enable a MIDlet as a standby MIDlet

You need to add the following line in the .jad file so that the application manager will treat the MIDlet as a standby MIDlet:

SEMC-StandbyApplication: Y

Using a Canvas to handle state changes

In order to be able to react to events properly the MIDlet needs to use a Canvas or a GameCanvas for displaying the graphics. This is because the Canvas class provides the necessary callback methods:

public class MyCanvas extends Canvas {
 
    public void paint(Graphics g) {
        //Paint method
    }
 
    protected void hideNotify() {
        //Background
        //Pause your application
    }
 
    protected void showNotify() {
        //Not in background
        //Resume your application
    }
 
    protected void keyPressed(int key) {
        if (key == -9999) {
            //In focus
            //Change to drawing graphics for user input etc..
        }
    }
 
    protected void keyReleased(int key) {
        if (key == -9999) {
            //Lost focus
            //Change to drawing graphics for Inactive mode (wallpaper graphics)
        }
    }
}

Attached is a simple standby MIDlet and source code illustrating a complete implementation, handling the state transitions.