Invoking applications in Java ME

MIDP 2.1 compliant devices support the javax.microedition.MIDlet classes completely as defined in the MIDP 2.1 JSR. The text below lists additional implementation information for this package.

It is recommended to implement MIDlets in a way that ensures that the startApp and destroyApp methods return quickly.

For example, if the MIDlet startup requires several time-consuming initializations, it is recommended to do the startup in a separate thread so that the startApp returns quickly.

platformRequest

Return value of platformRequest is always false , as the request is executed immediately. The return value indicates that the calling MIDlet does not need to exit for the object to run.

In Symbian, if the handler application already prompts for user confirmation, the method doesn't prompt. Support for a new protocol can be added dynamically afterwards to the device. In this case, the "Allow this application start an application?" prompt is shown to the user.

Table: Supported URI schemes:

URI scheme

Supported in Symbian

Supported in Series 40

Java user confirmation prompt

Behavior

http:

Yes

Yes

"Allow this application to use network for sending/receiving data?"

Open URI in Browser

https:

Yes

Yes

"Allow this application to use network for sending/receiving data?"

Open URI in Browser

mms:

Yes

No

"Allow this application to use network for sending/receiving data?"

Open URI in RealPlayer

rtsp:

Yes

Product dependent

"Allow this application to use network for sending/receiving data?"

Open URI in RealPlayer

file:

Yes

No

"Allow this application start an application?"

Open file in MIME type specific application

tel:

Yes

Yes

No user prompt

Asks confirmation before making phone call

wtai:

Yes

No

"Allow this application start an application?"

Like tel: / open address book for edit / send DTMF sequence

cti:

Yes

No

No user prompt

Computer telephony integration. Like tel:

sms:

Yes

No

No user prompt

Open SMS editor

mmsto:

Yes

No

No user prompt

Open MMS editor

mailto:

Yes

Product dependent

No user prompt

Open E-mail or MMS editor

localapp:

Yes (JRT 2.1 onwards)

Yes

"Allow this application start an application?"

Start local application In Series 40, only allowed for manufacturer and operator MIDlets. In Symbian Java all domains work but only some applications are supported. See following table.

javaapp:

Yes (JRT 2.1 onwards)

No

"Allow this application start an application?"

Start Java application

For more information, see Launching a MIDlet from another MIDlet.

nativeapp:

Yes (JRT 2.1 onwards)

No

No user prompt

Start native application. Only allowed for manufacturer and operator MIDlets.

For more information, see Launching a native application from a MIDlet.

jrt:

Yes (JRT 2.2 onwards)

No

No user prompt

Hides an application from Task Manager.

Only allowed for manufacturer and operator MIDlets.

For more information, see Hiding applications from TaskManager.

Added protocols

Yes

No

"Allow this application start an application?"

For more information on URI schemes, see also Web Browser for Symbian URI scheme support, in the Web Developer's Library.

The 'Allow this application start an application?' prompts resulting from calling the platformRequest method are independent from other possible prompts in the MIDP runtime.

In Symbian, for http: and https: schemes, prompt is not shown if the MIDlet already has permission javax.microedition.io.Connector.http for the http: scheme and javax.microedition.io.Connector.https for the https: scheme. For rtsp: and mms: schemes, prompt is not shown if the MIDlet already has permission javax.microedition.io.Connector.rtsp. If the access permission is denied, platformRequest fails just like if the user canceled it. In Series 40, prompt is shown for trusted third party and untrusted MIDlets, also Browser confirmation prompt can be shown.

If the application is in operator or manufacturer domain, the method doesn't prompt.

Note: After closing the handler application, the MIDlet is brought to the foreground. In Symbian, however, after closing "telephone" application, the MIDlet is left to background.

In Symbian, localapp supports launching only the following applications:

Table: Localapp usage in Symbian

Application

Accepted arguments

Contacts

localapp://contacs

Calendar

localapp://calendar/Today

localapp://calendar

Messaging

localapp://messaging

Invoking Browser with a specified access point

In Symbian, for http: and https: URIs, platform Browser supports a (non-standard) URI format in which the access point ID number can be added to the end of the URI, preceded with space. When the access point ID is given, Browser uses that access point in creating a network connection, regardless of whether or not there already is an available connection, for example WiFi.

Note: The ID does not indicate access point priority. It is only used for the identification of the access point.

When using platformRequest, Java Runtime passes http: and https: scheme URIs as they are to Browser. If a MIDlet provides the access point ID in the URI, it behaves in the same manner as Browser, described above. MIDlet can query the list of available access points using IAP Info API. The method IAPinfo.getIApInfo().getAccessPoints() lists the access points. The method getAccessPoint(String) is used to get access point ID if the access point name is known.

Example: platformRequest("http://www.forum.nokia.com 1");

Concurrency

Series 40 and Symbian platforms allow running of the MIDlet and the handler application concurrently, so there is no need to terminate the MIDlet, except when installing a new version.

Platform requests are executed immediately, they are not queued.

Note: In Symbian, If a MIDlet makes many platform request calls (from multiple threads or sequentially from a single thread) this can result in multiple handler applications running at the same time. If multiple requests are targeted to a single handler application, this can result in the handler not being able to deal with them properly. Multiple requests are not prevented in any way. In Series 40 each new request overrides the previous one

Examples

Making a phone call:

platformRequest("tel:+19143680400"); 

Opening a web page:

platformRequest("http://www.forum.nokia.com/"); 

Opening web page using network access point 1:

platformRequest("("http://www.forum.nokia.com 1");

Opening an RTSP streaming connection:

platformRequest("rtsp://ra.yle.fi/ramgen/tv2/viihde/zencafe.rm"); 

Opening a local file with default handler application:

platformRequest("file://E/image.png"); 

Opening SMS editor for sending SMS to a specified telephone number:

platformRequest("sms:+19143680400"); 

A Forum Nokia use case that contains the complete source code of a sample MIDlet that makes a platform request: Code snippet of phone call