Quick Java ME Primer
So you want to make wireless applications, eh? Well, I’ve written a little primer on the topic of Java ME to get you started. We’ll talk about what Java ME is, and the different configurations of Java ME which are available on cell phones and PDAs.
Simply put, Java ME (formerly J2ME) consists of a Java virtual machine and a set of core APIs specifically designed for consumer electronic devices. If you are writing games, your target devices will probably be cell phones, and PDAs, such as Blackberry and Palm. (Sadly, Java ME support on Pocket PC devices is almost non-existent.) This being said, you don’t have to specifically limit your code to only work on a particular type of device. Java ME allows you to choose an environment which meets the requirements of your application, and only devices supporting that environment will be able to run it. Since this is Java, you need not be concerned with the manufacturer, wireless carrier, or hardware of the target device. This is, of course, unless you decide to use any vendor-specific extensions (more on that later).
The Java ME environment has two important components, the configuration and the profile. The configuration defines the base functionality of the Java ME environment, such as the specifications of the virtual machine, and which set of core APIs is available. For devices such as the ones mentioned above, you will be using Connected Limited Device Configuration (CLDC).
The profile defines the higher level capabilities of the environment; for cell phones and PDAs, this will be the Mobile Information Device Profile (MIDP). Here is where you will have to make a decision. There are currently two versions of MIDP, 1.0 and 2.0. The later provides additional features for multimedia and gaming, but at a cost. If you go with MIDP 2.0, you will be excluding a large set of devices which only support MIDP 1.0 from your potential market. Note that some features which are normally only available in MIDP 2.0 can be replicated in devices with MIDP 1.0 support via vendor-specific APIs. Using any of these APIs, of course, will destroy portability, unless you want to maintain multiple builds of your application.
Additionally, some devices support an extension to Java ME called Mobile Media API (MMAPI). This API provides audio and video support, and is available on some MIDP 1.0 devices. Note that a subset of MMAPI is included in MIDP 2.0. Support for MMAPI tends to be limited to higher-end phone, so keep that in mind when exploring this option.
For example, my personal cell phone is a Sanyo PM-8200, which only supports CLDC 1.0 and MIDP 1.0. As a result, all of my current applications are built for that environment. For one of my applications, I wanted to release a version with sound, but there are no sound APIs in MIDP 1.0. For this project, I decided to release two versions of the application, one that only used the core CLDC 1.0 and MIDP 1.0 APIs, and another which also used a proprietary Sprint PCS extension for playing sounds. The two versions had the same code base, with one difference. The sound-enabled version used a subclass of my base MIDlet class that included calls to the sound APIs. In my base MIDlet class, these methods were simply stubbed out. In the NetBeans IDE, these were represented as two different deployments, one which used the base class as the MIDlet and the other which used the subclass with the calls to the Sprint PCS sound API. In addition, I made sure to remove the sound resources from the deployment without sound support.
Which option you choose will depend on the requirements of your application, and which set of devices you wish to support. Generally, you want to choose the minimum environment which fulfills your requirements, in order to maximize the potential market for your application.
Bookmark this article: del.icio.us Digg Furl Reddit blogmarks Google Spurl StumbleUpon Technorati Yahoo!