ith an estimated 100 million Java-enabled handsets on the market today?a number projected to grow to 1 billion by 2006?it’s clear that the opportunity for wireless developers is enormous. However, since there are more than 200 different Java-enabled mobile handsets and an international market requiring multiple language support and mobile operator specific customizations, developers are finding the time commitment and total cost of deploying applications to be a huge hurdle to overcome?all but eliminating the benefits of having such a large potential market for their applications in the first place.

One of the issues that causes such a sinkhole for wireless application development is portability. With over 200 different types of devices, writing one program that works on each one seems a daunting task indeed. A common mistake is for developers to write an application for one device, and afterwards to attempt to tailor the original code to each device as needed.

In actuality, developers need to design and develop their applications with portability in mind from the very beginning. If care is not taken in the early stages of application development, exponential amounts of resources will be spent later recoding, and in an extreme case?starting from scratch.

By avoiding the common mistakes outlined below, you can produce applications that are easier to port, manage, and ultimately, market to publishers and operators.

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, startApphideNotify, 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.

6) Ignoring Localization Issues During Initial Development
Multiple languages are also important in gaining broad application distribution. Porting from one language to another has challenges if not handled correctly. The time to consider these principles is during development?not after the English version is finished:

• Avoid using custom table fonts. If an application utilizes custom font tables stored in separate PNG files, the code must be able to handle Unicode Basic Latin and Latin-1 Supplement characters. Specifically, ranges 0021-007E and 00A1-00FF (see these charts for the Basic Latin and Latin-1 supplements).
• Construct UI elements with text with at least 30 percent expansion room. This is to provision for less compact languages like German.
• Compose string resources in complete sentences or phrases. Concatenated strings should rarely be used.
• Text in help screens, about screens, or any other screens that are text intensive should be able to handle word wrapping.
• Avoid using images as text. If text is used in images then translated versions of the images should be provided.

7) Making Use of Proprietary APIs
MIDP 1.0 was a great starting point for J2ME programming and for creating applications in mobile devices. Unfortunately, it was missing a lot of functionality needed for game developers to create. Many handset manufacturers dealt with this limitation by adding proprietary APIs to handsets to enable advanced capabilities for sound and graphics. These proprietary APIs can make it difficult to put the applications on new devices because some APIs are “mappable” between devices, while others aren’t. Generally avoid using custom APIs if you wish to ensure portability.

8) Creating Applications that Are Too Big
Keep the application size below 64KB. Some of the most popular devices in the world have a hard upper limit of 64KB, and if the game is to be used by large quantities of consumers, it will need to work on these devices. If you absolutely need a larger size for a complex application, then consider making a light version for the devices with the 64KB limit as well.

9) Ignoring De-facto Industry Standards
Over the last couple of years, J2ME has emulated the Wild West when it comes to GUI rules and standardization of application look and feel. Although there are no mandated rules in place, the industry is starting to standardize on the way it wants menus and hotkeys handled. It is important to include a Main Menu within every application. In addition to all of the application specific requirements, the main menu must include an option for Help, About, and Exit.

Portable from the Very Start
With so many different devices and languages that need to be supported for commercial success, it is critical to begin factoring in portability at the beginning of development not when the application is complete. Avoid these mistakes, and you may find your effort rewarded with conserved company resources, reduced time to market, and applications that are more highly valued by publishers and operators alike