The Content Handler API is an optional package for the JavaTM ME platform. This API and model let an application invoke registered Java ME and non-Java applications for content by URL, by content type, or by content handler ID. The application can use actions provided by the handler on the invoked content.
Content Handler API works as specified in the JSR-211 API specification, with the following exceptions:
In addition to HTTP support mandated by JSR-211 specification, HTTPS and 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 but they must handle the invocations in foreground only. In other words, when receiving the invocation notification through the listener, the handler must go to foreground before getting the invocation object. When the handler has completed the invocation, it does not have to exit but can go to background instead. The same applies to invoking applications.
The basic rules are as follows: