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.