Saturday, July 08, 2006

Constructing a Mobile Game Skeleton

You will learn here how to build a very simple MIDlet called Skeleton that displays information about the mobile phone as lines of text onscreen. Understanding and building upon this sample MIDlet will allow you to code even more complex games.

Exploring the J2ME APIs

Before getting into the coding details of your first mobile phone program, you need a quick primer on the APIs that go into building MIDlets. The MIDP (Mobile Information Device Profile) specification is a set of rules that describe the capabilities and limitations of Java with respect to mobile devices. A significant aspect of these capabilities and limitations is the standard set of classes and interfaces that are available for MIDlet programming. Although the MIDP specification provides a detailed description of the API available for MIDlet development, an additional API is provided by the CLDC (Connected Limited Device Configuration). The MIDP API builds on the CLDC API to provide classes and interfaces that are more specific to mobile information devices. You can think of the CLDC as providing a general Java API for networked devices, whereas the MIDP goes a step further in providing a more detailed API that fills in the specifics left out of the CLDC API for compact wireless devices such as phones and pagers.

Why should you care about any of these specifications and APIs? The CLDC and MIDP specifications are important because they explicitly define what classes and interfaces can be used to build MIDlets. Mobile devices are nimble machines that don't have the luxury of megabytes of memory to pack full of application overhead. Knowing this, Sun had to figure out a way to provide a core set of functionality with a useful feature set but without bloating the runtime requirements of mobile devices. Their answer is the two-tier approach that consists of a configuration layered with a more detailed profile. The CLDC API describes the core classes and interfaces required by a general network device, whereas the MIDP API adds the classes and interfaces required by a mobile information device such as a mobile phone

Keep in mind that although the CLDC and MIDP APIs have been carefully thought out to trade off functionality against the memory and resource constraints of mobile devices, they will inevitably come up short in certain situations. This means that you will sometimes have to work a little harder as a MIDlet game developer because you don't have as rich an API to work with as you would if you were doing traditional game programming.


The majority of the classes in the CLDC API are directly included from the standard J2SE API. These classes and interfaces are practically identical to those that you may be familiar with from traditional Java programming. This portion of the CLDC API is located in packages with familiar J2SE names such as java.lang and java.util. In addition to the classes and interfaces that are borrowed directly from the J2SE API, a few interfaces are unique to the CLDC API. These interfaces deal primarily with networking, which is an area of the J2SE API that is particularly difficult to scale down for the needs of network devices.

The CLDC defines a set of interfaces that facilitate generic networking, and leaves the specifics of implementing these interfaces to the MIDP API. So the CLDC API is logically divided into two parts:

  • A series of packages that serve as a subset of the J2SE API

  • A set of generic networking interfaces

The bulk of the classes and interfaces in the CLDC API are inherited directly from the J2SE API. J2ME requires that any classes or interfaces inherited directly from J2SE must not be changed in any way, which means that the methods and fields are identical to the versions found in J2SE. This makes it easier to learn how to program in J2ME, and it also makes Java code more portable between J2SE and J2ME.

No comments: