Feature description

In addition to HTTP support mandated by JSR-211 specification, HTTPS and to a limited extent, file URL support are also provided.

There is no limit set on the number of levels of MIDlet chaining, this is only limited by platform memory availability.

There is no Gallery integration for invoking MIDlet content handlers using the content file in the Gallery.

MIDlet to native invocation is not supported as the files are already on the phone.

Native applications do not have assigned application IDs that would enable MIDlets to invoke native content handlers directly by an application ID. They can, however, invoke native content handlers by content type for HTTP schemes.

Native content handlers cannot be overridden by MIDlet content handlers. For example, when content is viewed in Gallery, the native content handler is always triggered. MIDlets can still use a specific MIDlet content handler rather than a native content handler if it is referenced by application ID or specifies a particular action that the MIDlet content handler supports.

It is not possible to exchange data between MIDlet and native content handlers.

It is not possible for native content handlers to pass the result of an operation back to the invoking MIDlet. The state INITIATED is used.

If the MMC card is removed then content handlers are automatically unregistered unless there is a shortcut file to the MIDlet on the MMC card.

Not all of the native content handlers are accessible through a MIDlet invocation.

Native handlers are only found when the content type is explicitly searched for.

MIDlet content handlers are only registered on the WAP download channel. This means that MIDlet content handlers can be triggered when content is downloaded through the web browser but not when content is pushed to the phone by Bluetooth.

There is no UI to ‘choose’ between content handlers registered for exactly the same content type and action(s). The MIDlet that registered for the content type last takes precedence.

WAP push delivered content can also trigger MIDlet content handlers – assuming that the MIDlet is signed appropriately (Manufacturer and Operator domains only).

Background MIDlets can be content handlers. When a content handler MIDlet has completed the action for which it was invoked, it does not have to exit but can move to the background instead or, if it handled the action in the background to begin with, it can remain there.

The basic content handling rules for background MIDlets are:

1. If one MIDlet invokes the content handler in another MIDlet, the invoking MIDlet must exit to allow the content handler MIDlet to run in the foreground.

2. If the invoking MIDlet is a background MIDlet, it can instead move to the background to allow the content handler MIDlet to run. The invoking MIDlet must still perform the invoking in the foreground.

3. If the content handler MIDlet is a background MIDlet and is not running when invoked, it is started in the foreground.

4. If the content handler MIDlet is a background MIDlet and is running in the background when invoked, it is allowed to handle the invoked action while remaining in the background. However, it depends on the MIDlet whether it can actually handle the invoked action in the background. Moreover, the invoking MIDlet must know whether the invoked content handler MIDlet performs the handling in the background or in the foreground.

5. If the content handler MIDlet can perform the invoked action in the background, the invoking MIDlet need not exit or move to the background.

The Registry.invoke method returns true if the MIDlet must exit to allow the invoked application to run. Even if the method returns false, the MIDlet must either exit or move to the background if the invoked application is in the background and must come to the foreground to handle the invoked action.

The MicroEdition-Handler-<n>-ID attribute contains the content handler ID. If the MIDlet suite is trusted, then this attribute and value must be present in both the manifest and application descriptor and the values must be the equal or it must not appear at all. If not present in the application descriptor or manifest, the implementation must supply a default ID as defined above using the classname from the MicroEdition-Handler-<n> attribute.

MIDP applications that do not register as content handlers need an application ID to be allowed access to restricted content handlers. The MIDlet-<n>-ID attribute contains the application ID for the MIDlet registered with the MIDlet-<n> attribute. When the application has gained access to the Registry the ID is available using the Registry.getID method. If the MIDlet suite is trusted, then this attribute and value must be present in both the manifest and application descriptor and the values must be the equal or it must not appear at all. If an ID is not provided, the implementation MUST supply a default ID as defined above using the classname in the MIDlet-<n> attribute.