Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

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.


advertisement
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, Tira Wireless offers a commercial product, the Tira Jump Product Suite, to address device fragmentation. In fact, Tira Wireless' CTO and co-founder is Allen Lau. Mr. Lau has dedicated a large part of his professional career on addressing the device fragmentation issue. A simple search for device fragmentation on Google or your favorite Web search engine will undoubtedly connect you to several articles he has written or statements he has made on the subject.

When I asked him via email if he was satisfied with the direction open source tools like NetBeans and J2ME Polish take in addressing the device fragmentation problem, his response was definitive. "No. Both assume that API fragmentation is the root cause of the problem while the real problem is implementation fragmentation." He explains: "the most serious problem is implementation differences—screen size, available heap memory, performance, JAR size limitations, and, most importantly, VM implementation differences" which he claims NetBeans and J2ME Polish have not gone far enough yet in their efforts to address. "Standardization through JSRs," he claims, "will not be able to solve [implementation differences]. JSRs can only resolve API fragmentation issues which is not a big problem today." Solving the big problem of implementation differences "is out of the scope of the JCP and in fact is impossible to standardize. A mobile phone is a consumer electronic. Manufacturers have to differentiate themselves and segment the market (e.g. low end vs. high end devices). As such, it is actually not desirable to standardize. Using games as an example, people in the console game business accept the fact that they will have to develop for PS2, Xbox, and GameCube. It is just part of the development cost. We, as professionals in the mobile industry should also accept the fact that the cost of device fragmentation will never reduce to zero."

Indeed, "solving" device fragmentation might be impossible. Java/J2ME provide a foundation for WORA, but complete and seamless portability in the device world is tough. Tools to help address it without having to write and manage separate code bases are emerging. Open source tools like NetBeans/NetBeans Mobility Pack and J2ME Polish offer some first steps and, as Allen Lau states, using tools like his Jump Platform help keep "the 'cost' of fragmentation down to a very reasonable and manageable level that fragmentation is no longer unbearable."



Jim White is an instructor with Intertech Training. He is also co-author of Java 2 Micro Edition, (Manning).
Comment and Contribute

 

 

 

 

 


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

 

 

Sitemap