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 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.
return peer.platformRequest(URL);