Login | Register   
LinkedIn
Google+
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
 

Avoid the 9 Common Flaws of Unportable Mobile Java Apps : Page 2

Portability is a huge concern, especially in wireless development, but developers who fail to incorporate portability concerns into their app design from the outset are doomed to repeat the same dumb mistakes over and over. Find out the nine most common design flaws in J2ME applications and get your apps out of the quicksand and into the air.


advertisement
1) Hard-coding for Fixed Screen Sizes
Hard-coding for fixed screen sizes severely limits portability. When working with drawing screen elements, make sure your splashscreens, sprites, and background images are dynamically adjustable to different screen sizes instead. For example, say you want to draw a size 10 pixel rectangle at the bottom right corner of the screen. Instead of this:

graphics.drawRect(118, 118, 10, 10);

Your code should look like this:

graphics.drawRect(getWidth() - 10, getHeight() 10, 10, 10);

Both will work on a Nokia 7210 but the former will not be portable.



2) Hard-coding Sound Elements
Similar to the above mistake, hard-coding sound elements also negatively impacts portability. Sound elements must be stored in separate files in the .JAR and not hard-coded. In addition, the size of the byte array used to store the sound element must be dynamic or provisioned to have expansion room. The file size may grow significantly when converting to less efficient sound file formats.

3) Neglecting to Make Provisions for Incoming Calls or Messages
This is critical to smooth interoperability between the phone and the Java application. When an application's operation is interrupted by an incoming call, SMS, or phone-related action, the application should "pause" and "resume" appropriately. There are two mechanisms you can use to pause and resume the app, for example:

pauseApp, startApp hideNotify, showNotify

The MIDP specs indicate you should use pauseApp/startApp, however, some buggy implementations do not call these properly. Alternatively, hideNotify/showNotify is used on some devices. The best approach is to handle both cases, so no matter which is called (or if both are called), the application can pause and resume properly.

4) Hard-coding of Constants
Again, another circumstance where hard-coding limits portability. It is a much better practice to refer to a central location such as a config file or class file in the JAR. This guideline is especially true when you're considering translating the application into new languages for new markets. Applications with downloadable content such as puzzles, comics, and information programs should all keep their data and content files in separate repositories to make the download and management of content easier.

5) Ignoring the MIDP Spec and Global Operator OTA Environment
The MIDP Spec and the global Operator OTA environment have both resulted in a set of guidelines and rules about what is allowed and required in the application Manifest and JAD file. There are both required and optional entries, and the way that these entries are formatted is very important for portability. Some operator channels have very strict rules about the content and order of the JAD and Manifest entries. If you do not conform to their requirements, the application will not be considered for distribution. In addition, there are devices with very strict requirements for their JAD and Manifest files. There is a possibility that an application will not load and install on the device if it does not follow the guidelines.



Comment and Contribute

 

 

 

 

 


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

 

 

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