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


Tackle Device Fragmentation with NetBeans and the NetBeans Mobility Pack : Page 5

Building J2ME applications with a single code base that deploys to an ever-growing set of platforms is a tough and maybe impossible task. Find out how using Sun's NetBeans IDE with the NetBeans Mobility Pack can help.

Additional APIs
Some devices may have special features and optional J2ME APIs installed on the device to use the special features. For instance, in this example, the new J2ME phone devices that the NewPhone project configuration targets can play sound files (WAV, MIDI, etc) using the optional J2ME multi-media API (MMAPI). This is another case where a separate application code base would often be needed in order to use this API. Instead, more ability related preprocessor blocks and a special project configuration property can be set to allow the inclusion and use of the MMAPI without the need for a separate application.

In the code, when a new commodity price has been requested, receiving the price quote reply from is asynchronous. Therefore, when the price is received, it is nice to provide the user with an audible signal (in addition to displaying the price information on the screen) so they know when the price has been displayed. In the RequestQuoteMidlet, you will find the preprocessor blocks that include a call to the MMAPI to play a .wav file when sound is available. In other words, when the hasSound ability is associated with the project configuration.

/*#!hasSound#*///<editor-fold> //-- Alert symbolAlert = new Alert("Check Symbol/Type", //-- "No quote found.", null, AlertType.WARNING); /*$!hasSound$*///</editor-fold> /*#hasSound#*///<editor-fold> Alert symbolAlert = new Alert("Check Symbol/Type", "No quote found.", null, null); try { InputStream is = getClass().getResourceAsStream("/audio/bong.wav"); Player audioPlayer = Manager.createPlayer(is, "audio/x-wav"); audioPlayer.start(); } catch (IOException ioe) { } catch (MediaException me) { } /*$hasSound$

As a second step in dealing with this device fragmentation issue, for the NewPhone project configuration must also designate the inclusion of Mobile Media API as part of the target platform. Switch to the NewPhone project configuration using the button bar project configuration drop down list. Open the project properties dialog window and click on the Platform category (see Figure 9). Note that for the NewPhone configuration, the Optional Package Mobile Media API check box is switched on while it is off for other configurations.

Figure 9. Switching on Optional APIs in the Project Configuration:The project configuration also allows you to designate the associated devices with having or not having various optional APIs—like MMAPI—available to the application.

In order to build and test this portion of the application that uses the MMAPI to play sound, you will have to have the MMAPI available to the IDE and your application. Download and install the Sun reference implementation of this API. In this example, MMAPI has been installed at c:\mmapi-1.0-fcs and the code downloaded with this article references the MMAPI and sound files from that location. If you change the location, be sure to also change the references to the API and associated resources in the project properties of the project configuration that uses the API. Namely, switch to the NewPhone project configuration and change the MMAPI reference listed in the Build/Libraries and Resources for the project configuration to point to wherever you have the MMAPI library installed.

Obfuscation Changes Per Device
Obfuscation modifies bytes code during builds to make it harder to decompile or reverse engineer your application (see this article). Reverse engineering might be more of a threat on some devices, like PDAs, where access to the file system is particularly easy. As the requirements table (see Table 1) suggests, the code deployed to the PDA device ought to be obfuscated in order to better protect the intellectual property within the application. Here again, NetBeans project configurations can help. Switch to the PDA project configuration using the button bar project configuration drop down list. Open the project properties dialog (right click on the project and select Properties) and click on the Build/Obfuscating category in the project properties dialog window. For the old and new phone project configurations, the obfuscation level is left off, but for the PDA project configuration, the level is set to high. Whenever the PDA project is built, the appropriate obfuscation level is applied to the class files while not affecting the class files created for the other projects.

Some Glitches/Issues
While NetBeans' use of project configurations, abilities, and preprocessor blocks to address device fragmentation is slick, these elements do add a few glitches to your programming. Namely, I noticed that references to line numbers in stack traces are thrown off by the inclusion/exclusion of the various preprocessor blocks; presumably because some lines of code are removed or added based on the preprocessing. This makes testing and debugging applications a bit more difficult. Secondly, using NetBeans' reformatting tool to clean up and align your code is also thrown off by the special tags and comments associated with the preprocessor blocks. Finally, the NetBeans Mobility Pack was established to help write MIDP/CLDC applications. Therefore, if you are building other types of J2ME applications, say a CDC application for example, you will not find NetBeans and NetBeans Mobility Pack project configurations very helpful.

Alternative Solutions and Work to Do
NetBeans is not the only tool available to address the device fragmentation issue. J2ME Polish is a an open source suite of tools to help, as their Web site states, "polish" J2ME applications. Along with tools to obfuscate and optimize your application, J2ME Polish provides several tools for wrestling with device fragmentation issues. Also,