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
 

Automate Your J2ME Application Porting with Preprocessing

Got porting nightmares? If you're considering automating the porting your J2ME applications, you may want to think about using a preprocessor. Find out why it's the only technique open-ended enough to handle porting to multiple device models.


advertisement
ecause Java is theoretically portable, people assume that when you develop a Java mobile application, it should run correctly on all Java-enabled devices. Like most things theoretical, this just doesn't work in the real world. During the short life of J2ME mobile applications, many developers have expressed concerns that interoperability problems are not going to be solved so easily by new initiatives like MIDP 2.0 or JTWI.

The reality is that J2ME may be globally portable but J2ME applications are not. This means that byte-code runs correctly on all Java handsets but the behavior of an application must be adapted for almost each handset. There are 1200 mobile devices, all of which have different capabilities, support various Java platforms—including MIDP, and support optional APIs and optional parts of APIs. Not to mention that each of these implementations has its own unique set of bugs (click here to see a demonstration of this fragmentation of device characteristics and features).

The result of this is that, in a typical development cycle, porting and testing can consume from 40 to 80 percent of your time, depending on your level of experience and on the number of devices you need to support.



Testing your ported mobile applications on real mobile phones isn't always easy. A good emulator should reproduce all the bugs of the real device, but emulators don't always exist and when they do, they're far from reliable.

Bugs are another difficulty—you either need resolve bugs in your source code or deactivate the problem features, all of which can be different depending on the firmware version. Manufacturers face difficulties when there are bugs in their virtual machines. This causes problems with the integration of the VM in the handset at the hardware level.

Mobile operators need to control the quality of the distributed midlets, because low-quality midlets affect operator service. Operators also need to transpose older, more successful midlets for newer device models and for wider availability. This is why developers have to be able to port their applications to these new devices quickly.

Do You Need Automatic Porting?
The number of devices your application is able to support is the main question—and the one that most effects your return on investment. Automating your porting has many benefits:

  • It reduces the time to market and enables J2ME prototypes.
  • It automates tedious tasks.
  • It allows you to focus on your application logic instead of various device specs.
  • It allows you to produce optimized applications to each device.
First, you'll need take into account the specificities of each device model. Your application should use optional features whenever available. Table 1 shows some examples of what functionalities your application should support depending on the device.

If the device …

… Your application should

supports sounds

play sounds

supports alpha-blending

display the menu by varying opacity

has strong .jar file size limitations

remove not mandatory images

supports fullscreen

use fullscreen

has enough heap memory and supports large .jar file sizes

use optional features like bitmap fonts

supports camera control

be able to customize games using snapshots taken with the camera

supports Bluetooth

use the SMS or HTTP connections to communicate with others users (ie. chat, etc.)

supports SMS

use it to pay to activate the current application

supports PDAP

use it to access images in an internal gallery

can initiate a phone call

make phone calls

supports running applications in background

run applications in the background


Table 1: Examples of the specificities of device models



Comment and Contribute

 

 

 

 

 


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

 

 

Sitemap