J2ME: Alert followed by Alert

I have been working on a J2ME application. There is an instance where a message box appears to confirm an action with the user, if the user confirms the action then a subsequent alert may be shown. Whilst in theory this should have been straightforward the application just kept throwing an IllegalArgumentException.

In the API documentation for J2ME I found that the Display.setCurrent(alert, nextDisplayable) function will throw such an exception when nextDisplayable is an Alert instance. However, I was not using this function. The alert was being displayed using Display.setCurrent(displayable), and upon selecting “Confirm” was simply displaying another alert again with Display.setCurrent(displayable).

With thanks to James Mernin’s blog (Alert after Alert in J2ME) I found that this is in fact a result of the same limitation within J2ME. For my purposes I found that the simplest solution was to create a blank canvas, and upon the first paint event switch to the intended alert. This essentially breaks the chain into Alert -> Canvas -> Alert.

Continue reading

Advertisements

Problems with the JMUnit TestSuite Class

I attempted to use the ‘JMUnit’ unit testing library that is shipped with NetBeans for the first time today. I created a couple of simple TestCase classes and a TestSuite that combines each of these. However, every time I attempted to load the test suite I was presented with the following exception:

result 0: first.AdderTest
java.lang.SecurityException: MIDlet not constructed by createMIDlet.
        at com.sun.midp.midlet.MIDletStateHandler.newMIDletPeer(), bci=24
        at javax.microedition.midlet.MIDlet.(), bci=9
        at jmunit.framework.cldc10.Assertion.(), bci=1
        at jmunit.framework.cldc10.Test.(), bci=1
        at jmunit.framework.cldc10.TestCase.(), bci=2
        at first.AdderTest.(), bci=4
        at java.lang.Class.newInstance(), bci=0
        at jmunit.framework.cldc10.TestSuite.(), bci=57
        at java.lang.Class.newInstance(), bci=0
        at com.sun.midp.main.CldcMIDletLoader.newInstance(), bci=46
        at com.sun.midp.midlet.MIDletStateHandler.createMIDlet(), bci=66
        at com.sun.midp.midlet.MIDletStateHandler.createAndRegisterMIDlet(), bci=17
        at com.sun.midp.midlet.MIDletStateHandler.startSuite(), bci=27
        at com.sun.midp.main.AbstractMIDletSuiteLoader.startSuite(), bci=52
        at com.sun.midp.main.CldcMIDletSuiteLoader.startSuite(), bci=8
        at com.sun.midp.main.AbstractMIDletSuiteLoader.runMIDletSuite(), bci=161
        at com.sun.midp.main.AppIsolateMIDletSuiteLoader.main(), bci=26

Continue reading

Simplified ‘Display’ Management for J2ME

Switching between displayable objects such as canvases and alerts can become tricky when working on more complex applications. Code can easily become cluttered with excess ‘display’ and “midlet” references, despite that there is usually only one unique display instance.

This mess can be cleaned up by creating some static helper methods which provide instant access to the display instance without the need to maintain either midlet or display references.

public final class DisplayManager {
   // The one and only display object.
   private static Display display;

   // Get the one and only display object.
   public static final Display getDisplay() { return display; }

   // A one off call is required to prepare the display manager.
   public static final void initialize(Display display) {
      current = (DisplayManager.display = display).getCurrent();
   }
}

Continue reading

Enhancement on Soft-Key Detection

With many thanks to Graham over at the Nokia Discussion forums I came across an interesting Wiki article (Platform independent key events processing) which provides a class that tries to determine common non-standard keycodes for a variety of handsets. The second handset that I tested was an LG KS360, unfortunately this detection class was unable to detect the soft key buttons.

I have combined my welcome screen based soft-key detection into that class as a fail-safe, and this seems to be working great. So, where possible the correct keycodes are detected by working out the device vendor, and then where all else fails, accept the first non-standard keycode that is returned from the welcome screen for the left soft-key.

I have also added a SOFTKEY_GUESSED field which indicates if the left soft-key value was guessed. If it was, then you can decide whether or not to allow other non-standard keys to represent the right soft-key. You might decide against guessing the right soft-key in more critical scenarios where data could potentially be lost by pressing another unrelated button on the keypad.

The combination of these two techniques seems to provide a much better solution.

Generic soft key detection in J2ME

As many of you are aware, the soft key buttons on a mobile phone are general purpose buttons that are reused over and over again. On most handsets there are two of these directly beneath the screen (one on the left, and one on the right).

In a recent project I needed to be able to detect when the left and right soft keys were being pressed, but unfortunately, J2ME does not define a standard key code. Instead it is up to the developer to specify different codes for all of the different phones in their target audience.

Two solutions came to mind:

  1. Compile the application for each target handset (perhaps overkill given that this be the only difference).
  2. Get the user to specify which button is which (even if they do not realize this!).

Continue reading