Just An Application

June 16, 2009

What’s New In MIDP 3.0 ? Part 11: javax.microedition.midlet.MIDlet

Filed under: Java, JME, MIDlets, MIDP, MIDP3, MIDP3API, Mobile Java — Tags: , , , , , — Simon Lewis @ 2:14 pm

There have been changes to existing javax.microedition.midlet.MIDlet methods to support the new MIDlet lifecycle model, and new methods have been added to support new MIDP 3.0 functionality.

1. Modified Method Contracts

1.1 destroyApp(boolean)


    protected abstract void destroyApp(boolean unconditional)
                            throws
                                MIDletStateChangeException

Originally if the value of the unconditional argument was false then a MIDlet could indicate that it did not want to be destroyed by throwing a MIDletStateChangeException.

This is no longer supported. The method will always be invoked with the unconditional argument set to true. Once the method has completed, normally, or by throwing an Exception, the MIDlet is considered to have been destroyed.

Note

In the current version of the specification the method documentation is badly mangled, although interestingly enough in different ways, in both the Javadoc and the PDF.

2 Deprecated Methods

2.1 public int checkPermission(String)

This method was originally defined in MIDP 2 to enable the checking of named permissions. As they are no longer supported it is now deprecated.

This method will continue to work if invoked by a legacy MIDlet, but will throw an IllegalStateException otherwise.

New MIDlets should use the java.security.AccessController.checkPermission(Permission) method to perform permission checking.

2.2 public final void notifyPaused()

MIDlets can no longer pause themselves.

New MIDlets should not use this method.

To support legacy MIDlets which have been implemented in terms of the notifyPaused()/resumeRequest() methods, this method will result in the MIDlet’s startApp() method being called immediately.

Notes

  1. It is not clear whether immediately means during the call to notifyPaused() itself, or after it has returned.
  2. It is not clear that this behaviour is actually going to ensure backwards compatibility. See here.

2.3 protected void pauseApp()

MIDlets are no longer paused using this method.

New MIDlets no longer have to implement this method. See below.

2.4 public final void resumeRequest()

As MIDlets are no longer paused and can no longer pause themselves there is no longer any need to be able to resume. This method has no effect when called. New MIDlets should not use it.

2.2. New Methods

2.2.1 public static String[] getAppProperty(String,String,String,String)


    public static String[] getAppProperty(
                               String name, 
                               String vendor, 
                               String attributeName, 
                               String attributeDelimiter)

This method can be used to get attributes defined by the MIDlet Suite containing the currently executing MIDlet, or defined by any of the LIBlets upon which that MIDlet Suite is dependent.

The method will tokenize the returned attribute value if a delimiter is specified.

The name argument specifies the name of the MIDlet Suite or LIBlet.

The vendor argument specifies the vendor of the MIDlet Suite or LIBlet.

The attributeName argument specifiers the name of the attribute to get.

The attributeDelimiter argument specifies the delimiter to use to tokenize the attribute value. If null then the value will not be tokenized.

The method returns an array of Strings if the attribute is found, null otherwise.

Note

As it is static LIBlet code can use this method to get attributes defined by the containing LIBlet, other LIBlets, or the MIDlet Suite. If it wishes to do so the LIBlet code will need some out-of-band mechanism to obtain the appropriate vendors and names as there is no programmatic way of obtaining them.

3.2 public final MIDletIdentity getMIDletIdentity()

This method returns the identity of this MIDlet as an instance of MIDletIdentity.

3.3 public final long getSplashScreenTime()

This method returns the number of milliseconds the splash screen, if any, associated with this MIDlet has been visible, or -1 if there is no splash screen associated with this MIDlet visible.

3.4 public final boolean isSelectedScreenSaver()

This method returns true if this MIDlet is the currently selected screensaver on the device, false otherwise.

4. New Concrete Methods

4.1 protected void pauseApp()

The pauseApp() method is no longer abstract. It was originally defined as abstract in MIDP 1.0, which ensured that a MIDlet developer had to implement it and at least in theory implement the appropriate behaviour if the MIDlet was paused.

As it has been deprecated and there is no need for it to be implemented on a per-MIDlet basis an implementation is now supplied.

Advertisements

2 Comments »

  1. […] the splash screen has been visible to the user can be determined by calling the MIDlet’s getSplashScreenTime() […]

    Pingback by What’s New In MIDP 3.0 ? Part 34: MIDlet Splash Screens « Just An Application — July 23, 2009 @ 7:39 am

  2. […] What’s New In MIDP 3.0: Redux – javax.microedition.midlet.MIDlet Filed under: JME, Java, MIDP, MIDP3, MIDP3Issues — Tags: Java, JME, JSR271, MIDP, MIDP3, MIDP3SpecIssues — Simon Lewis @ 6:26 pm Original Post […]

    Pingback by What’s New In MIDP 3.0: Redux – javax.microedition.midlet.MIDlet « Just An Application — December 13, 2009 @ 6:26 pm


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: