A Quick Java ME Primer

Have you ever wanted to write your own videofrom your potential market. Note that some
games or other applications for mobile phones andfeatures which are normally only available in MIDP
PDAs? Then perhaps you should take a look at2.0 can be replicated in devices with MIDP 1.0
Java ME, a popular platform for developingsupport via vendor-specific APIs. Using any of
applications for mobile devices. This article will getthese APIs, of course, will destroy portability,
you started with a quick introduction to Java ME.unless you want to maintain multiple builds of your
We'll talk about what Java ME is, and the differentapplication.
configurations of Java ME that are available onAdditionally, some devices support an extension
mobile phones and PDAs.to Java ME called Mobile Media API (MMAPI). This
Simply put, Java ME (formerly J2ME) consists of aAPI provides audio and video support, and is
Java virtual machine and a set of core APIsavailable on some MIDP 1.0 devices. Note that a
specifically designed for consumer electronicsubset of MMAPI is included in MIDP 2.0. Support
devices. If you are interested in writing videofor MMAPI tends to be limited to higher-end
games, your target devices will probably bephone, so keep that in mind when exploring this
mobile phones, and PDAs, such as Blackberry andoption.
Palm. (Sadly, Java ME support on Pocket PCFor example, my personal mobile phone is a
devices is almost non-existent.) This being said,Sanyo PM-8200, which only supports CLDC 1.0
you don't have to limit your code to only work onand MIDP 1.0. As a result, all of my current
one particular type of device. Java ME allows youapplications are built for that environment. For one
to choose an environment which meets theof my applications, I wanted to release a version
requirements of your application, and only deviceswith sound, but there are no sound APIs in MIDP
supporting that environment will be able to run it.1.0. For this project, I decided to release two
Since this is Java, you need not be concernedversions of the application, one that only used the
with the manufacturer, wireless carrier, orcore CLDC 1.0 and MIDP 1.0 APIs, and another
hardware of the target device. This is, of course,which also used a proprietary Sprint PCS
unless you decide to use any vendor-specificextension for playing sounds. The two versions
extensions (more on that later).had the same code base, with one difference.
The Java ME environment has two importantThe sound-enabled version used a subclass of my
components, the configuration and the profile. Thebase MIDlet class that included calls to the sound
configuration defines the base functionality of theAPIs. In my base MIDlet class, these methods
Java ME environment, such as the specificationswere simply stubbed out. In the NetBeans IDE,
of the virtual machine, and which set of corethese were represented as two different
APIs is available. For devices such as the onesdeployments, one which used the base class as
mentioned above, you will be using Connectedthe MIDlet and the other which used the subclass
Limited Device Configuration (CLDC).with the calls to the Sprint PCS sound API. In
The profile defines the higher level capabilities ofaddition, I made sure to remove the sound
the environment; for mobile phones and PDAs,resources from the deployment without sound
this will be the Mobile Information Device Profilesupport.
(MIDP). Here is where you will have to make aWhich option you choose will depend on the
decision. There are currently two versions ofrequirements of your application, and which set of
MIDP, 1.0 and 2.0. The later provides additionaldevices you wish to support. Generally, you want
features for multimedia and gaming, but at a cost.to choose the minimum environment which fulfills
If you go with MIDP 2.0, you will be excluding ayour requirements, in order to maximize the
large set of devices which only support MIDP 1.0potential market for your application.