javax.microedition.midlet
Class MIDlet

java.lang.Object
  javax.microedition.midlet.MIDlet

public abstract class MIDlet
extends java.lang.Object

A MIDlet is a Mobile Information Device Profile application. The application must extend this class to allow the application management software to control the MIDlet and to be able to retrieve properties from the application descriptor and notify and request state changes. The methods of this class allow the application management software to create, start, and destroy a MIDlet. A MIDlet is a set of classes designed to be run and controlled by the application management software via this interface. The states allow the application management software to manage the activities of a MIDlet within a runtime environment. It can select which MIDlet is active at a given time by starting and destroying them individually. The application management software maintains the state of the MIDlet and invokes methods on the MIDlet to notify the MIDlet of change states. The MIDlet implements these methods to update its internal activities and resource usage as directed by the application management software. The MIDlet can initiate some state changes itself and notifies the application management software of those state changes by invoking the appropriate methods.

Note: The methods on this class signal state changes. The state change is not considered complete until the state change method has returned. It is intended that these methods return quickly.

Since:

MIDP 1.0

Constructor Summary

protected

MIDlet() Protected constructor for subclasses.

Method Summary

int	checkPermission(java.lang.String permission) Deprecated. The permissions model in this specification does not use named permissions. MIDP 3.0 MIDlets needing to check permissions should use java.security.AccessController.checkPermission.
protected abstract void	destroyApp(boolean unconditional) Signals the MIDlet to terminate and enter the Destroyed state.
java.lang.String	getAppProperty(java.lang.String key) Provides a MIDlet with a mechanism to retrieve named properties from the application management software.
static java.lang.String[]	getAppProperty(java.lang.String name, java.lang.String vendor, java.lang.String attributeName, java.lang.String attributeDelimiter) Provides a mechanism to retrieve and at the same time parse application property values from the application descriptor and the manifest of the MIDlet or bound LIBlets.
long	getSplashScreenTime() Gets the length of time that the application's splash screen has been shown to the user.
void	notifyDestroyed() Used by an MIDlet to notify the application management software that it has entered into the Destroyed state.
void	notifyPaused() Deprecated. The application does not need to inform the implementation that it is quiescent.
protected void	pauseApp() Deprecated. To be informed of changes in resources available to the application use the listeners in the respective APIs. For example, to be notified that the application is not in the foreground register a DisplayListener.
boolean	platformRequest(java.lang.String URL) Requests that the device handle (for example, display or install) the indicated URL.
void	resumeRequest() Deprecated. MIDP 3.0 MIDlets will not be paused and do not need to be resumed.
protected abstract void	startApp() Signals the MIDlet that it has entered the Active state.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

MIDlet

protected MIDlet()

Protected constructor for subclasses. The application management software is responsible for creating MIDlets and creation of MIDlets is restricted. MIDlets should not attempt to create other MIDlets.

Throws:

java.lang.SecurityException - unless the application management software is creating the MIDlet.

Since:

MIDP 2.0

Method Detail

startApp

protected abstract void startApp()
                          throws MIDletStateChangeException

Signals the MIDlet that it has entered the Active state. In the Active state the MIDlet may hold resources. The method will only be called when the MIDlet is in the Paused state.

Two kinds of failures can prevent the service from starting, transient and non-transient. For transient failures the MIDletStateChangeException exception should be thrown. For non-transient failures the notifyDestroyed method should be called.

If a Runtime exception occurs during startApp the MIDlet will be destroyed immediately. Its destroyApp will be called allowing the MIDlet to cleanup.

Throws:

MIDletStateChangeException - is thrown if the MIDlet cannot start now but might be able to start at a later time.

Since:

MIDP 1.0

pauseApp

protected void pauseApp()

Deprecated. To be informed of changes in resources available to the application use the listeners in the respective APIs. For example, to be notified that the application is not in the foreground register a DisplayListener.

Pausing of MIDlets is deprecated in MIDP 3.0. For MIDP 3.0 applications, pauseApp MUST NOT be called. For backward compatibility, the pauseApp method MAY be called for MIDP 2.x applications as follows.

Calling pauseApp signals the MIDlet to enter the Paused state. In the Paused state the MIDlet must release shared resources and become quiescent. This method will only be called when the MIDlet is in the Active state.

If a RuntimeException occurs during pauseApp the MIDlet will be destroyed immediately. Its destroyApp will be called allowing the MIDlet to cleanup.

Since:

MIDP 1.0

destroyApp

protected abstract void destroyApp(boolean unconditional)
                            throws MIDletStateChangeException

Signals the MIDlet to terminate and enter the Destroyed state. In the destroyed state the MIDlet must release all resources and save any persistent state. This method may be called from the Paused or Active states.

MIDlets should perform any operations required before being terminated, such as releasing resources or saving preferences or state.

Note: The MIDlet can request that it not enter the Destroyed state by throwing an MIDletStateChangeException. This is only a valid response if the unconditional flag is set to false. If it is true the MIDlet is assumed to be in the Destroyed state regardless of how this method terminates. If it is not an unconditional request, the MIDlet can signify that it wishes to stay in its current state by throwing the MIDletStateChangeException. This request may be honored and the destroy() method called again at a later time.

If a Runtime exception occurs during destroyApp then the exception is ignored and the MIDlet is put into the Destroyed state.

When an uncaught exception occurs in a thread, the thread MUST be stopped in accordance with the Java Language Specificcation. In addition, further handling of the uncaught exception MAY occur as follows:

• If an implementation can identify the MIDlet that created the thread (the MIDlet to which the thread belongs), the MIDlet.destroyApp(false) method of this MIDlet MAY be called.
• If an implementation can only identify the MIDlet suite that created the thread (the MIDlet suite to which the thread belongs), the MIDlet.destroyApp(false) methods of all MIDlets from this suite MAY be called.
• If an implementation cannot identify either a MIDlet or a MIDlet suite that owns the offending thread, MIDlet.destroyApp(false) methods of all MIDlets executing in this VM instance MAY be called.

In all of these cases, the behavior after a call to MIDlet.destroyApp(false) is as follows:

• If a MIDlet attempts to recover by throwing javax.microedition.midlet.MIDletStateChangeException, the implementation MAY allow the MIDlet to continue running.
• If a call to MIDlet.destroyApp(false) results in a different exception of any kind, the implementation MUST terminate the MIDlet

Parameters:

unconditional - If true when this method is called, the MIDlet must cleanup and release all resources. If false the MIDlet may throw MIDletStateChangeException to indicate it does not want to be destroyed at this time.

Throws:

MIDletStateChangeException - is thrown if the MIDlet wishes to continue to execute (Not enter the Destroyed state). This exception is ignored if unconditional is equal to true.

Since:

MIDP 1.0

notifyDestroyed

public final void notifyDestroyed()

Used by an MIDlet to notify the application management software that it has entered into the Destroyed state. The application management software will not call the MIDlet's destroyApp method, and all resources held by the MIDlet will be considered eligible for reclamation. The MIDlet must have performed the same operations (clean up, releasing of resources etc.) it would have if the MIDlet.destroyApp() had been called.

Since:

MIDP 1.0

notifyPaused

public final void notifyPaused()

Deprecated. The application does not need to inform the implementation that it is quiescent.

Pausing of MIDlets is deprecated in MIDP 3.0. For MIDP 3.0 applications, calling notifyPaused throws an exception. For MIDP 2.0 applications, the implementation must handle notifyPaused as follows.

Notifies the application management software that the MIDlet does not want to be active and has entered the Paused state. Invoking this method will have no effect if the MIDlet is destroyed, or if it has not yet been started.

It may be invoked by the MIDlet when it is in the Active state.

If a MIDlet calls notifyPaused(), in the future its startApp() method may be called make it active again, or its destroyApp() method may be called to request it to destroy itself.

If the application pauses itself it will need to call resumeRequest to request to reenter the active state.

Throws:

java.lang.IllegalStateException - if the MIDlet Suite is a MIDP 3.0 MIDlet suite.

Since:

MIDP 1.0

getAppProperty

public final java.lang.String getAppProperty(java.lang.String key)

Provides a MIDlet with a mechanism to retrieve named properties from the application management software. The properties are retrieved from the combination of the application descriptor file and the manifest. For trusted applications the values in the manifest MUST NOT be overridden by those in the application descriptor. If they differ, the MIDlet will not be installed on the device. For untrusted applications, if an attribute in the descriptor has the same name as an attribute in the manifest, the value from the descriptor is used and the value from the manifest is ignored.

Parameters:

key - the name of the property

Returns:

A string with the value of the property. null is returned if no value is available for the key.

Throws:

java.lang.NullPointerException - is thrown if key is null.

Since:

MIDP 1.0

getAppProperty

public static final java.lang.String[] getAppProperty(java.lang.String name,
                                                      java.lang.String vendor,
                                                      java.lang.String attributeName,
                                                      java.lang.String attributeDelimiter)

Provides a mechanism to retrieve and at the same time parse application property values from the application descriptor and the manifest of the MIDlet or bound LIBlets. This method retrieves property value for a specific LIBlet or MIDlet, so same property name is allowed to be used by multiple LIBlets without ambiguity in the same binding.

Parameters:

name - name of the LIBlet or MIDlet to retrieve named property information from. If both name and vendor are null , this retrieves information from the MIDlet JAD/Manifest

vendor - the vendor of the LIBlet or MIDlet

attributeName - the name of the property to retrieve

attributeDelimiter - The characters in this parameter are the delimiters for separating the retrieved property value into tokens. Delimiter characters themselves will not be treated as tokens. If this is null , the value is not tokenized.

Returns:

An array of string with the value of the property tokenized. null is returned if no value is available for the attributeName

Throws:

java.lang.NullPointerException - is thrown if attributeName is null.

Since:

MIDP 3.0

resumeRequest

public final void resumeRequest()

Deprecated. MIDP 3.0 MIDlets will not be paused and do not need to be resumed.

Pausing of MIDlets is deprecated in MIDP 3.0. For MIDP 3.0 applications, calling resumeRequest throws an exception. For MIDP 2.0 applications, the implementation must handle resumeRequest as follows.

Calling resumeRequest provides a MIDlet with a mechanism to indicate that it is interested in entering the Active state. Calls to this method can be used by the application management software to determine which applications to move to the Active state.

When the application management software decides to activate this application it will call the startApp method.

The application is generally in the Paused state when this is called. Even in the paused state the application may handle asynchronous events such as timers or callbacks.

Throws:

java.lang.IllegalStateException - if the MIDlet Suite is a MIDP 3.0 MIDlet suite.

Since:

MIDP 1.0

platformRequest

public final boolean platformRequest(java.lang.String URL)
                              throws javax.microedition.io.ConnectionNotFoundException

Requests that the device handle (for example, display or install) the indicated URL.

If the platform has the appropriate capabilities and resources available, it SHOULD bring the appropriate application to the foreground and let the user interact with the content, while keeping the MIDlet suite running in the background. If the platform does not have appropriate capabilities or resources available, it MAY wait to handle the URL request until after the MIDlet suite exits. In this case, when the requesting MIDlet suite exits, the platform MUST then bring the appropriate application (if one exists) to the foreground to let the user interact with the content.

This is a non-blocking method. In addition, this method does NOT queue multiple requests. On platforms where the MIDlet suite must exit before the request is handled, the platform MUST handle only the last request made. On platforms where the MIDlet suite and the request can be handled concurrently, each request that the MIDlet suite makes MUST be passed to the platform software for handling in a timely fashion.

If the URL specified refers to a MIDlet suite (either an Application Descriptor or a JAR file), the application handling the request MUST interpret it as a request to install the named package. In this case, the platform's normal MIDlet suite installation process SHOULD be used, and the user MUST be allowed to control the process (including cancelling the download and/or installation). If the MIDlet suite being installed is an update of the currently running MIDlet suite, the platform MUST first stop the currently running MIDlet suite before performing the update. On some platforms, the currently running MIDlet suite MAY need to be stopped before any installations can occur.

If the URL specified is of the form tel:<number>, as specified in RFC2806, then the platform MUST interpret this as a request to initiate a voice call. The request MUST be passed to the "phone" application to handle if one is present in the platform. The "phone" application, if present, MUST be able to set up local and global phone calls and also perform DTMF post dialing. Not all elements of RFC2806 need be implemented, especially the area-specifier or any other requirement on the terminal to know its context. The isdn-subaddress, service-provider and future-extension may also be ignored. Pauses during dialing are not relevant in some telephony services.

Devices MAY choose to support additional URL schemes beyond the requirements listed above.

Many of the ways this method will be used could have a financial impact to the user (e.g. transferring data through a wireless network, or initiating a voice call). Therefore the platform MUST ask the user to explicitly acknowlege each request before the action is taken. Implementation freedoms are possible so that a pleasant user experience is retained. For example, some platforms may put up a dialog for each request asking the user for permission, while other platforms may launch the appropriate application and populate the URL or phone number fields, but not take the action until the user explicitly clicks the load or dial buttons.

Parameters:

URL - The URL for the platform to load. An empty string (not null) cancels any pending requests.

Returns:

true if the MIDlet suite MUST first exit before the content can be fetched.

Throws:

javax.microedition.io.ConnectionNotFoundException - if the platform cannot handle the URL requested.

Since:

MIDP 2.0

checkPermission

public final int checkPermission(java.lang.String permission)

Deprecated. The permissions model in this specification does not use named permissions. MIDP 3.0 MIDlets needing to check permissions should use java.security.AccessController.checkPermission.

The Named Permissions of MIDP 2.x have been deprecated in this specification. For MIDP 3.0 applications, calling checkPermission throws an exception. For MIDP 2.0 applications, the implementation must implement checkPermission.

Gets the status of the specified legacy named permission. If no API on the device defines the specific permission requested then it must be reported as denied. If the status of the permission is not known because it might require a user interaction then it should be reported as unknown.

Parameters:

permission - to check if denied, allowed, or unknown.

Returns:

0 if the permission is denied; 1 if the permission is allowed; -1 if the status is unknown

Throws:

java.lang.IllegalStateException - if the MIDlet Suite is a MIDP 3.0 MIDlet suite.

Since:

MIDP 2.0

getSplashScreenTime

public long getSplashScreenTime()

Gets the length of time that the application's splash screen has been shown to the user.

An application may specify a splash screen in its manifest (see section X for more details). The splash screen is shown only when the application is started by the user and is not shown during subsequent restarts of the application (i.e. after being paused). The splash screen is shown on the primary Display.

The implementation should show the splash screen as soon as possible after the MIDlet is launched, but it must guarantee that it is visible to the user by the time the MIDlet's startApp method is called.

Once shown, the splash screen will remain visible until one of the following events occurs:

• The MIDlet shows a Displayable by calling setCurrent on its primary Display
• The MIDlet's startApp method returns
• The MIDlet is no longer in the foreground

If the splash screen is still visible, this method returns the elapsed time since when it was first shown. Implementations are required to provide a time value that is accurate to within +/-100 milliseconds, as measured by viewing the physical display of the device. A value of -1 is returned if the splash screen has been hidden or if a valid splash screen image is not specified in the MIDlet's manifest.

Returns:

the length of time (in milliseconds) that the currently visible splash screen has been shown, or -1 if no splash screen is currently visible

Since:

MIDP 3.0