Java Doc for MIDletPeer.java in  » 6.0-JDK-Modules » j2me » com » sun » midp » midlet » Java Source Code / Java DocumentationJava Source Code and Java Documentation

All state changes are synchronized using midletStateHandler retrieved from the MIDletStateHandler. NotifyPaused, ResumeRequest, and NotifyDestroyed methods invoked on the MIDlet cause the appropriate state change. The MIDletStateHandler is aware of changes by waiting on the midletStateHandler.

The peer MIDlet field is set later when the MIDlet's constructor calls newMidletState.

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 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 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 request is interpreted 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.

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 acknowledge 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.

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.

To be called only by the MIDletStateHandler or MIDletState while holding the lock on midletStateHandler.
Parameters:
  newState - new state of the MIDlet