J2ME mobile game developer - Beginers

[DevelopmentTeam]

Configurations
A configuration specifies a JVM and some set of core APIs for a specific family of devices. Currently there are two: the Connected Device Configuration (CDC) and the Connected, Limited Device Configuration (CLDC).

Connected Device Configuration
A connected device has, at a minimum, 512KB of read-only memory (ROM), 256KB of random access memory (RAM), and some kind of network connection. The CDC is designed for devices like television set-top boxes, car navigation systems, and high end PDAs. The CDC specifies that a full JVM (as defined in the Java Virtual Machine Specification, 2nd edition) must be supported.

The configurations and profiles of J2ME are generally described in terms of their memory capacity. Usually a minimum amount of ROM and RAM is specified. For small devices, it makes sense to think in terms of volatile and non-volatile memory. The non-volatile memory is capable of keeping its contents intact as the device is turned on and off. ROM is one type, but non-volatile memory could also be flash memory or battery-backed RAM. Volatile memory is essentially workspace and does not maintain its contents when the device is turned off.

The CDC is being developed under the Java Community Process. For more information on the CDC, see http://java.sun.com/products/cdc/. A Linux reference implementation is available.

The CDC is the basis of the Personal Profile stack. The Personal Profile is the next generation of PersonalJava, a Java application environment that is similar to JDK 1.1.8.

Connected, Limited Device Configuration
CLDC is the configuration that interests us, because it encompasses mobile phones, pagers, PDAs, and other devices of similar size. CLDC is aimed at smaller devices than the CDC. The name is a little misleading; really, the CLDC is designed for a small device with a limited network connection

[DevelopmentTeam]

A profile is layered on top of a configuration (and someday, perhaps, on Building Blocks), adding the APIs and specifications necessary to develop applications for a specific family of devices.

Current Profiles
Several different profiles are being developed under the Java Community Process. The Foundation Profile is a specification for devices that can support a rich networked J2ME environment. It does not support a user interface; other profiles can be layered on top of the Foundation Profile to add user interface support and other functionality.

Layered on top of the Foundation Profile are the Personal Basis Profile and the Personal Profile. The combination of CDC + Foundation Profile + Personal Basis Profile + Personal Profile is designed as the next generation of the PersonalJava application runtime environment (see http://java.sun.com/products/personaljava/). As such, the Personal Profile has the specific goal of backward compatibility with previous versions of PersonalJava.

The PDA Profile (PDAP), which is built on CLDC, is designed for palmtop devices with a minimum of 512KB combined ROM and RAM (and a maximum of 16MB). It sits midway between the Mobile Information Device Profile (MIDP) and the Personal Profile. It includes an application model based on MIDlets but uses a subset of the J2SE Abstract Windowing Toolkit (AWT) for graphic user interface. Although the PDAP specification is nearly finished, to my knowledge no hardware manufacturer has announced that it will be implementing PDAP. The J2ME world currently is covered by MIDP on the small end and Personal Profile on the higher end.

Mobile Information Device Profile
The focus of this book is the Mobile Information Device Profile (MIDP). According to the specification, a Mobile Information Device has the following characteristics:

128KB of non-volatile memory for the MIDP implementation

32KB of volatile memory for the runtime heap

8KB of non-volatile memory for persistent data

A screen of at least 96

[DevelopmentTeam]

Advantages of MIDP
Given the spectrum of configurations and profiles, why is this book about MIDP? First, MIDP comes at a critical time, a time when MIDP devices, like mobile phones, are an exploding market. Simultaneously, MIDP devices are achieving the kind of processing power, memory consumption, and Internet connectivity that makes them an attractive platform for distributed applications. MIDP 1.0 is already deployed on millions of handsets all over the world, and MIDP 2.0 holds much promise for the future.

Second, of course, MIDP is the first J2ME profile that is ready for prime time. If you read into the next chapter, you can write MIDP applications today.

Portability
The advantage of using Java over using other tools for small device application development is portability. You could write device applications with C or C++, but the result would be specific to a single platform. An application written using the MIDP APIs will be directly portable to any MIDP device.

If you've been following Java's development for any time, this should sound familiar. It's the same "Write Once, Run Anywhere" (WORA) mantra that Sun's been repeating since 1995. Unfortunately, WORA is a bit of a four-letter word for developers who struggled with cross-platform issues in JDK 1.0 and JDK 1.1 (particularly the browser implementations). While Java's cross-platform capabilities in Java 2 are generally successful, WORA still has the taint of an unfulfilled promise.

Does MIDP deliver painless cross-platform functionality? Yes. There will always be platform-specific bugs in MIDP implementations, but I believe MIDP works as advertised because it is so much smaller than desktop Java. Less code means fewer bugs when porting to multiple platforms. Most of the cross-platform incompatibilities of JDK 1.0 and JDK 1.1 were caused by the nightmare of trying to fit disparate windowing systems into the AWT's peer-based component architecture. MIDP has nothing approaching the complexity of AWT, which means there's an excellent possibility that MIDP applications will seamlessly run on multiple platforms right out of the starting gate. Furthermore, while the JDK 1.0 test suite only included a few dozen tests, the MIDP compatibility test suite includes several thousand tests.

Security
A second compelling reason for using Java for small device development is security. Java is well known for its ability to safely run downloaded code like applets. This is a perfect fit

[DevelopmentTeam]

Tooling Up
MIDlets are developed on regular desktop computers, although the MIDlet itself is designed to run on a small device. To develop MIDlets, you'll need some kind of development kit, either from Sun or another vendor. Remember, MIDP is only a specification; vendors are free to develop their own implementations.

The world is full of MIDlet development tools if you know where to look. Furthermore, many of these tools are freely available.

The bare bones set of tools is Sun's MIDP reference implementation. This includes the preverify tool (more on this later), a MIDP device emulator, source code, and documentation. You can download the MIDP reference implementation by following the links from http://java.sun.com/products/midp/. However, I don't recommend using the reference implementation unless you really enjoy being in the middle of the gritty details of building and packaging MIDlets. (You should also investigate the reference implementation if you are interested in porting the MIDP runtime to a new device or platform.)

A much better tool for beginners is Sun's J2ME Wireless Toolkit, available from http://java.sun.com/products/j2mewtoolkit/. The J2ME Wireless Toolkit (or J2MEWTK, as it's affectionately known) includes a GUI tool that automates some of the tedious details of building and packaging MIDlets, providing a simple path from source code to running MIDlets. At the same time, the J2ME Wireless Toolkit is a relatively lightweight solution, almost a miniature IDE, not something that will choke your machine.

Larger IDEs are available in abundance, from device manufacturers, wireless carriers, and IDE vendors, including the following:

Borland JBuilder MobileSet: http://www.borland.com/jbuilder/mobileset/

IBM WebSphere Studio Device Developer: http://www-3.ibm.com/software/pervasive/products/wsdd/

Metrowerks CodeWarrior Wireless Studio: http://www.metrowerks.com/MW/Develop/Wi ... efault.htm

Research In Motion BlackBerry Java Development Environment: http://www.blackberry.net/developers/na ... load.shtml

Sun ONE Studio, Mobile Edition: http://wwws.sun.com/software/sundev/jde ... tures.html

Zucotto Wireless WHITEboard SDK: http://www.zucotto.com/products/wb/whiteboard.html

You can use whatever development kit you wish. I suggest you start with the J2ME Wireless Toolkit, which is easy to use and authoritative. I'll be using the J2ME Wireless Toolkit throughout the rest of the book. Other development environments generally use the J2ME Wireless Toolkit as a plugin anyhow, so your experiences are likely to be similar no matter what tool you use. You'll notice details about the development environment most in this chapter, where I'll go into detail about the build tools and the emulators. For much of the remainder of this book, I'll be describing the MIDP APIs, so it won't really matter which development kit you use.