The core set of tools and APIs used to construct
normal Java applications is known as J2SE, which stands for Java 2
Standard Edition. J2SE is used to construct both web-based applets and
standalone applications. J2EE (Java 2 Enterprise Edition) is another
version of Java designed solely for building enterprise applications.
J2EE is different from J2SE because it adds significant functionality to
support enterprise applications. Think about big networked applications
such as the engine that runs eBay or Amazon.com, and you’ll have an
idea of what J2EE is designed for.
Given that wireless
mobile devices have less computing power and smaller screens than their
desktop counterparts, it stands to reason that J2ME represents a
simplified version of J2SE with a reduced feature set. J2ME is in fact a
subset of J2SE that supports a minimal set of features that are
applicable to mobile devices, both wireless and wired.
J2ME
also throws in some features that are entirely unique to mobile
devices. Together, these three Java development suites (J2ME, J2SE, and
J2EE) compose the Java 2 technology.
If you’re concerned
about why I’m going into so much detail about J2ME when this is a game
programming book, it’s because there are some bare minimums you need to
understand in regard to J2ME. Don’t worry—after you get a little more
J2ME knowledge under your belt, we’ll take off with the mobile game
stuff!
Configurations and the Connected Limited Device Configuration (CLDC)
If you use J2ME,
you will encounter some new terms and acronyms that you might as well go
ahead and get behind you. The first one is a configuration,
which is a minimum set of APIs used for developing applications to run
on a certain range of devices. A standard configuration for wireless
devices is known as the Connected Limited Device Configuration, or CLDC.
The CLDC describes a minimum level of functionality required for all
wireless mobile devices. The CLDC takes into consideration factors such
as the amount of memory available to such devices, along with their
processing power.
To be a little more
specific, the CLDC clearly outlines the following pieces of information
with respect to wireless mobile devices:
The subset of Java programming language features
The subset of functionality of the Java virtual machine
The core APIs required for wireless mobile application development
The hardware requirements of the wireless mobile devices targeted by the CLDC
You might assume that the
entire Java programming language is available for use in mobile
devices, but in fact some features are disabled under the CLDC because
of the limited processing power of mobile devices. In addition to
spelling out API details, the CLDC also specifies minimum hardware
requirements for Java-powered devices:
160KB of total memory available for Java
16-bit processor
Low power consumption (often battery power)
Network connectivity (often wireless with a 9,600bps or less bandwidth)
As
this list reveals, CLDC devices include, but are not limited to, mobile
phones, pagers, PDAs, pocket computers, and home appliances. Of course,
our interest is in the CLDC as it applies to mobile phones.
Gamer’s Garage
In
addition to the CLDC, J2ME defines another configuration known as the
CDC (Connected Device Configuration), which is geared toward devices
that are larger and more powerful than CLDC devices. Consequently, the
CDC has more features than the CLDC. |
Profiles and the MIDP
On top of a configuration sits a profile,
which is a more specific set of APIs that further targets a particular
type of device. A configuration describes in general terms a family of
devices, whereas a profile gets more specific and isolates a particular
type of device within that family. The Mobile Information Device
Profile, or MIDP, is a profile built on top of the CLDC that describes a
wireless mobile device such as a mobile phone or pager.
In addition to specifying
APIs for use in MIDP application development, the MIDP also describes
minimum hardware and software requirements for an MIDP device. The next
two sections outline these hardware and software requirements, which are
very important because they let you know the worst case scenario your
games will face when it comes to mobile phone hardware and software.
Gamer’s Garage
There
are actually two versions of the MIDP profile: 1.0 and 2.0. Although
MIDP 1.0 phones have a wide installed base, MIDP 2.0 is where J2ME
offers serious features for mobile game developers. This book focuses
solely on the newer MIDP 2.0 standard. MIDP 2.0 phones are rapidly
replacing the first generation 1.0 phones, if they haven’t already as
you read this. |
Assessing the MIDP Hardware Requirements
The hardware
requirements for MIDP 2.0 devices are an important part of the MIDP
standard. These requirements are broken down into the following device
properties:
Memory
Input
Display
Networking
The memory requirements for MIDP devices are as follows:
256KB of nonvolatile memory for the MIDP API libraries
128KB of volatile memory for the Java runtime system
8KB of nonvolatile memory for persistent application data
The input requirements of
MIDP devices stipulate that an MIDP device must have a keyboard or
touch screen. The keyboard can be either one-handed or two-handed, and
it is possible that a device might have both a keyboard and a touch
screen. Notice that a mouse isn’t an input requirement because it is
unlikely that a mobile device would be capable of using a mouse.
However, it is quite possible for a device to use a stylus with a touch
screen.
Gamer’s Garage
In
case you’re wondering, joysticks are starting to enter the MIDP
equation. Sony/Ericsson and Samsung offer mobile phones with a tiny
little joystick embedded in the keypad. Because the MIDP doesn’t
specifically support joysticks, the four basic directions (up, down,
left, and right) allow a joystick to be supported if joystick directions
were mapped to keys. |
The display requirements
for MIDP devices are a little more interesting because the screens for
mobile devices represent one of the most constrained hardware
properties. MIDP device displays must have a screen size of 96 pixels by
54 pixels with a 1-bit color depth. This means that the screen must be
at least 96 pixels wide and 54 pixels high, and must be at least black
and white. Furthermore, the aspect ratio of the display must be 1:1,
which simply means that pixels must be square. Believe it or not, many
computer monitors don’t have a 1:1 aspect ratio, which means that pixels
are actually rectangular in shape. Not so with MIDP device screens!
Gamer’s Garage
 | In
reality, the vast majority of mobile phones blow out the MIDP 2.0
screen minimum by supporting color, and in most cases also have screens
larger than the 96×54 minimum. |
The last hardware area targeted by the MIDP specification is networking,
which dictates the minimum networking support required of an MIDP
device. An MIDP device must have a two-way, wireless network connection
of some sort. It is expected that such a connection may be intermittent,
such as a dial-up connection, and that it also may have limited
bandwidth (9,600bps). This is important because it informs you that you
must be very conscious of bandwidth issues when designing network games,
especially games that rely on lots of time-critical updating such as
action games.
Examining the MIDP Software Requirements
The
cross-platform nature of Java helps alleviate concerns over the wide
range of mobile device operating systems. Even so, the MIDP
specification lays some ground rules about what is expected of the
operating system in an MIDP device. Following are the major software
requirements for MIDP devices:
A minimal kernel to manage low-level hardware features such as interrupts, exceptions, and scheduling
A mechanism to read from and write to nonvolatile (persistent) memory
A timing mechanism for establishing timers and adding time stamps to persistent data
Read/write access to the device’s wireless network connection
A mechanism to capture user input from a keyboard or touch screen
Minimal support for bitmapped graphics
A mechanism for managing the life cycle of an application
These requirements,
although somewhat minimal, still provide a reasonably rich set of
features that are available for use by an MIDP game.
