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.

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

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();
   }
}