Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Map J2ME Applications to Content Types with JSR-211 (CHAPI) : Page 4

If you've been frustrated when trying to write J2ME apps that communicate with other applications, help is at hand. This brand new J2ME API improves the way mobile devices handle content.

Step 3: Getting the Response
When the content handling is completed (in the sample code, that occurs when the user presses the 'ok' softkey, which in turn executes the commandAction() method), the application must invoke the ContentHandler.finish() method. The invoking application is then notified of the completion and can return to the main execution thread (if it is active). The behavior of the finish() method is similar to invoke()—depending on the implementation, the content handler may need to finalize before the callee can continue execution.

Discovering the Registered Handlers
Several methods of the Registry class allow developers to discover the registered handlers responsible for specific content types. You can also determine which registered content handlers are responsible for specific actions, such as delete, open, or rename for a given file extension (.png, .vcard, .mid, etc), or MIME-type (text/html, image/gif, etc). Finally, you can locate the content handler identified by a specific ID.

Registering a Content Handler
For the VCardViewer MIDlet to be recognized as a content handler, you must register it with the AMS. The most common approach is static registration; as long as the MIDlet declares its content handling attributes in the .jad descriptor, it is registered automatically during installation on the device. The sample code below shows the descriptor for the VCardViewer MIDlet. Content handling is a sensitive system resource and prone to misuse, so MIDlets registered as content handlers must be signed/authorized by the author for them to work. The specification states that you must add the MIDlets into the javax.microedition.content.ContentHandler security domain for them to work properly as content handlers.

MIDlet-1: VCardViewer, /icons/vcard.png, example.VCardViewer MicroEdition-Handler-1: example.VCardViewer, text/vcard, open, .vcard MicroEdition-Handler-1-en-US: View MicroEdition-Handler-1-br-PT: Visualizar MicroEdition-Handler-2: example.VCardEditor, text/vcard, edit, .vcard MicroEdition-Handler-2-en-US: Edit MicroEdition-Handler-2-br-PT: Editar MicroEdition-Handler-ID: http://jsr-211.java.net/vcardhandler MIDlet-Jar-Size: 2751 MIDlet-Jar-URL: http://java.net/example/jarFileName.jar MIDlet-Name: Example Content Handlers MIDlet-Vendor: Sun Microsystems, Inc. MIDlet-Version: 1.0 MicroEdition-Configuration: CLDC-1.0 MicroEdition-Profile: MIDP-2.0 MIDlet-permissions: javax.microedition.content.ContentHandler

Among the attributes on this descriptor, only the ones starting with the prefix "MicroEdition-Handler" deserve a detailed explanation in the context of the sample application:

  • MicroEdition-Handler-. These attributes describe the handlers included in the MIDlet Suite. The arguments are the name of the MIDlet responsible for handling the content (VcardViewer and VCardEditor), the supported MIME-types, the supported operations (only open and edit), and the suffix of the supported files.
  • MicroEdition-Handler--. This stores the descriptive names of the actions. Applications can retrieve these names using the ActionNameMap class. The list is typically useful for exhibition on the user interface. The locale suffix allows for handler internationalization—associated with different languages (en-US, br-PT, etc.).
  • MicroEdition-Handler-ID. This specifies the unique identifier of this content handler package on the device. Although I've shown it with an identifier value in the sample descriptor, you don't have to supply the identifier, because the underlying implementation will create it.
You can also register MIDlets dynamically. The sample code below registers a MIDlet as the content handler for image/png files and declares that the MIDlet will be responsible for handling opening requests (ContentHandler.ACTION_OPEN) for that file type. The code calls the Registry.register() method to perform the registration. The complementary Registry.unregister() method lets you unregister an application previously defined as a content handler. Content handlers are unregistered automatically when their corresponding MIDlets are removed (uninstalled) from the device.

try { // Create a content handler instance for the // Generic PNG Handler String[] chTypes = { "image/png" }; String[] chSuffixes = { ".png" }; String[] chActions = { ContentHandler.ACTION_OPEN }; String chClassname = "example.content.PNGHandler"; ContentHandler handler = Registry.register(chClassname, chTypes, chSuffixes, chActions); } catch (ContentHandlerException ex) { // Handle exception }

Before you get too excited about these new capabilities, remember that CHAPI is both optional and not yet final. The final reviews are due to take place in the fourth quarter of this year and should not add many changes to the current API specification. In addition, CHAPI's availability on any particular device depends on whether the device manufacturer implement and include it with their devices' VMs. But because of CHAPI's usefulness and the new level of interaction it brings to the J2ME world, many manufacturers will probably elect to implement it on their MIDP 2.00-compliant devices fairly quickly.

Herval Freire is a Sun Certified Java Programmer (SCJP), Web Components Developer (SCWCD) and Micro Application Developer (SCMAD). He works as a senior consultant on wireless and mobility projects.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date