IN THIS CHAPTER
Throughout this book, we've been leaning heavily on designing games for the MIDP—the Micro Java profile designed for today's average mobile phone. But there are other types of Micro Java, too. This chapter gives those types a fair shake.
Some examples of devices that sport other Micro Java blends:
Personal Digital Assistants (PDA)s such as Palm devices will soon have their own Micro Java profile.
Many advanced hybrid organizer-phones, such as the Nokia Communicator, use Symbian's EPOC operating system, which supports the Java profile. This is often accompanied by the JavaPhone API.
More powerful palmtop computers, such as those sporting Microsoft's Windows CE operating system, can run PersonalJava. The Sharp Zaurus SL-5000 runs embedded Linux along with PersonalJava.
Many set-top digital television boxes, game consoles, and other multimedia devices will come with PersonalJava pre-installed, usually working in conjunction with the JavaTV API.
With the large number of devices supporting PersonalJava and other Java technologies, expect to start playing games in places games haven't traditionally been played before. For example:
A navigation device in an automobile can help pop out trivia, geography, wordplay, or other fun games during long family road trips.
A refrigerator can make a game out of guessing its contents. Or a special game can help you diet by forcing you to help Sergeant Heart battle the giant Cholesterol Monster before you can mindlessly reach for a snack.
Small screens in digital telephones might enable you to engage in simple multiplayer games, puzzles, or adventures with friends while you speak to them.
This chapter will discuss PersonalJava, as well as other forthcoming Micro Java profiles that might be useful for game developers.
The Connected Device Configuration (CDC) is a J2ME configuration meant for higher-end devices that are more sophisticated than standard mobile phones. For example, the CDC covers smart communicators, pagers, micro laptops, PDAs, and set-top boxes. Specifically, the CDC targets devices with the following attributes:
Just as the CLDC uses the Kilobyte virtual machine (KVM) to process bytecode, the CDC has a special C virtual machine (CVM). The CVM supports nearly all the Java 2 virtual machine features, but has a much smaller footprint. More info can be found at http://java.sun.com/products/cdc/cvm/.
The CDC uses the Foundation Profile to flesh out all user interface and network functionality. More info about the Foundation Profile can be found at http://java.sun.com/products/foundation/.
The J2ME Foundation Profile is targeted at network-enabled devices that do not necessarily have a display or otherwise require a GUI. As such, there are no user interface classes or methods.
A target device will have a minimum 1024KB of ROM and a minimum 512KB of RAM.
The next release of PersonalJava, which is still in the specification phase, is known as the Personal Profile for J2ME. This profile will be based on the Java 2 Standard Edition code and will be compatible with PersonalJava specification versions 1.1 and 1.2.
The Personal Profile will use the CDC and the Foundation Profile as a basis, but will go on to define GUI and other special features.
The Personal Profile will target micro devices with the following characteristics:
Minimum 2.5MB ROM available
Minimum 1MB RAM available
Robust connectivity to a network
A graphical user interface display
In effect, the Foundation Profile for J2ME, along with the CDC and the Personal Profile, is equivalent to the current PersonalJava environment. This means that existing PersonalJava applications will be able to run on more modern J2ME systems.
The PersonalJava platform was around before J2ME technologies were finalized. It was the first Micro Java technology. The current release of PersonalJava is basically a subset of the JDK 1.1.8 code, along with some Java 2 security and support for native interfaces. PersonalJava also has a few of its own APIs, such as the Timer API.
Just like standard Java, PersonalJava can run as either applets or applications. Various devices will include browsers than support PersonalJava applets. Other gadgets, such as the Nokia 9210 Communicator, have a separate AppletViewer program capable of running applets. Most PersonalJava devices sport the full PersonalJava Application Environment (PJAE).
Many small devices currently handle PersonalJava. There are also various runtime libraries, such as Insignia Jeode, SavaJe, and Kada VM, which you can install on top of other operating systems, allowing you to then run PersonalJava apps. More information about these packages can be found in Chapter 2, “The Mobile World.”
PersonalJava combines the pros of the Java language with a small, efficient footprint and memory model. Thousands of PersonalJava applications have already been written and deployed for set-top boxes, PDAs, and other systems.
More information about PersonalJava can be found at http://java.sun.com/products/personaljava/.
PersonalJava supports some form of the following standard Java APIs:
In addition, there are several specific omissions and additions.
Many PersonalJava devices have built-in support for double buffering. This allows for flicker-free drawing to the screen without any additional work or overhead.
To check whether your device supports double buffering, call the public boolean isDoubleBuffered() method from the java.awt.Component or java.awt.peer.ComponentPeer packages.
If the device supports double buffering, then all paint() and update() functions will automatically be drawn to an offscreen buffer. If the method returns false, however, you will need to implement double buffering yourself.
Your PersonalJava application can deal with special input methods. There are four interfaces in the com.sun.awt package that enable you to develop components that use specific means of navigation.
The interfaces include the following:
NoInputPreferred—. This component is just meant to display something. It has no navigation at all.KeyboardInputPreferred—. Keyboard support is preferred, if possible. Because many devices won't have an actual keyboard attached, a virtual keyboard might appear on the screen and a user may use that to “type” her message.ActionInputPreferred—. A user can activate this component using the standard input device. Basically, the component should be able to figure out when a user has focused on it (MOUSE_ENTER), moved away from it (MOUSE_EXIT), or selected/clicked on it (MOUSE_DOWNfollowed byMOUSE_UP). This usually involves some sort of pointer, such as a stylus, a finger on a touch screen, or rolling around an arrow cursor with a trackball.PositionalInputPreferred—. Use this interface when it is important to determine the specificxandycoordinates that a user has selected within the actual component.
If there's one thing can be generalized about the wide variety of devices that use PersonalJava, it's that there are always exceptions to every rule. Some devices just won't be able to support every PersonalJava feature.
As such, if an implementation does not support an optional package or class, then the NoClassDefFoundError will be thrown when the program attempts to access that class.
If only certain methods within a class are not valid on a particular device, the implementation will throw an exception class called com.sun.lang.UnsupportedOperationException when the method is accessed. Be sure to catch and handle these exceptions throughout your game.
PersonalJava has a built-in series of timer events. The main timer call is com.sun.util.PTimer. A PTimer object can hold specific timer events, each specified by a timer specification. When a timer goes off, it calls the timer specification's notifyListeners() method.
To schedule a timer, use the schedule(PTimerSpec pts) method and pass in a PTimerSpec object.
The com.sun.util.PTimerSpec class determines how and when a timer should be triggered. A specification can register PTimerWentOffListeners and determine how often com.sun.util.PTimerWentOffEvent should be thrown.
You can create two types of timer specifications: absolute or delayed, using the setAbsolute(boolean absolute) method. A delayed timer will go off after a set amount of time has passed. An absolute timer will go off at a specific time.
You can set the time value itself using the setTime(long time) method. For delayed timers, this is the delay in milliseconds. For absolute timers, this is the time in milliseconds since midnight, January 1, 1970 (a standard Java clock unit).
Delayed specifications can be set to repeat immediately after being activated using the setRepeat(boolean repeat) method. A repeating specification can be set to be regular or non-regular using the setRegular(boolean regular) method. A regular specification will go off at a fixed interval, no matter what the system load is or whether it takes a long time to notify listeners. A non-regular timer will only begin to count down after all listeners have been called.
The interface used to deal with a timer is com.sun.util.PtimerWentOffListener. Simply implement this interface, create your timer, and then handle the timerWentOff(PtimerWentOffEvent pte) method. This method will be called whenever the timer finally goes off.
Creating PersonalJava applications is similar to cranking out any other Java application. You write the Java source code files, compile them into bytecode classes using javac, and test.
Because PersonalJava has several special classes that aren't in the standard JDK, you can download the compatibility classes from http://java.sun.com/products/personaljava/pj-cc.html. You will need these classes to compile PersonalJava applets and applications via the standard JDK environment.
After you've built your class files, it's time to see what they actually look like on a typical PersonalJava device.
You can download the PersonalJava emulation environment from Sun's site (http://java.sun.com/products/personaljava/pj-emulation.html). There are versions available for Solaris and Windows. There are also various packages available, to simulate various devices. You can simulate using the full set of support libraries by using standard Win32 or Motif components. Or you can simulate the minimum platform using the special Touchable component set.
TIP
To ensure that your PersonalJava application runs on any supported device, use the minimal Touchable set.
You can run your applications using the pjava program. You can view applets using the pappletviewer. These two programs work just like their Java Standard Edition counterparts, java and appletviewer.
For example, enter the following line:
pjava MyTest.class
If all goes well, you'll see your application run. You are now able to thoroughly test it.
Another tool enabling you to be sure your code is valid is JavaCheck. This program, available for download at http://java.sun.com/products/personaljava/javacheck.html, analyses applications and applets and ensures that they are compatible with PersonalJava or other Java platforms. JavaCheck reads Platform Specification Files, which have a file extension of .spc. These files define the limits of a given platform. Sun has created .spc files for various Java platforms.
So, to test a PersonalJava application, you would run JavaCheck, load up the PersonalJava spc file as the basis, and then input the classes you want to test. JavaCheck will tell you whether there are any errors or warnings.
Both a command line and GUI version of JavaCheck are available.
The Nokia 9201 Communicator is one of the most popular PersonalJava devices available. The Communicator is both a mobile phone and PDA, running on the EPOC Operating System. It has a full (mini) keyboard and 12-bit color screen that is 640x200 pixels in size. Check out http://forum.nokia.com/ for more information.
Nokia and Borland have created a visual Integrated Development Environment (IDE) and Software Development Kit (SDK) to help ease application development. The SDK for the Nokia 9210 can plug into Borland's popular JBuilder product, giving the developer an integrated environment in which to write, test, emulate, and debug applications.
To create a PersonalJava file for the Symbian Platform, you must import two packages that include classes for the Crystal application environment and Symbian's standard EPOC classes:
import com.symbian.devnet.crystal.awt.*; import com.symbian.epoc.awt.*;
For example, to install your PersonalJava applet on the Communicator or other Symbian platform systems, you need to follow this process:
You must obtain a unique identifier (UID) number. You can obtain this from Symbian's Web site at http://www.symbiandevnet.com/.
Compile your Java code as usual.
Package all classes into a JAR file.
Create all graphics as bitmaps.
Use the AIF Builder tool that comes with the Nokia SDK to create support files. You will need to type in your UID, the application name, and the application's main class and working directory.
The AIF Builder tool also lets you import or edit your application's icons. You need to create two icons: One 25x20 and one 64×50.
You can also use this tool to set the application's Caption in 23 different languages!
In the end, the AIF Builder will output files to your working directory:
You can now use the emulator to test your program. Just point it to this working directory and select the main class file.
To actually deploy to a Nokia phone, you need to create a package (
.PKG) file that lists all components. This is a simple text file that lists all the files necessary to build the installer, including the JAR and any image files. This file also indicates what supported languages are, and what the UID number is. The format looks like this:&EN #{ "Test"} , (0x01010101), 1, 0, 0 "Test.aif" - "!:systemapps estTest.aif" "Test.app" - "!:systemapps estTest.app" "Test.txt" - "!:systemapps estTest.txt" "Test.mbm" - "!:systemapps estTest.mbm" "Test.jar" - "!:systemapps estTest.jar" "Test.jpg" - "!:systemapps estTest.jpg"Use the
makesiscommand-line tool (available from Nokia or Symbian's site) to package everything together. Just input the.PKGfile as a parameter.A
.SISinstallation file will be created. The.SISfile can then be copied to the device using a serial cable or infrared port, or it can be downloaded from the Internet.
It's possible to run MIDP programs on many PersonalJava devices. For example, Nokia offers a special plug-in program for the Nokia 9210 that emulates the MIDP environment. You can find it at the following URL: http://forum.nokia.com/files/disclaimer/1,14553,1423,00.html.
Because PersonalJava is almost as feature-rich as the full Java 2 Standard Edition, developers might be tempted to write big, meaty applets. However, there are many design constraints to keep in mind:
Many devices don't have typical input or output devices. Some devices might use touch-screen monitors, speech recognition, styluses, joysticks, virtual keyboards, a simple set of cursor keys on a remote control, levers, buttons, dials, and so on. As such, mouse-only events such as right-clicking, double-clicking, dragging and dropping, and so on are not appropriate. Most buttons or other commands should be available via a single “click” or selection.
There might not be enough room in memory for images. Any images displayed should be very small. Downloading images from the network as necessary and then disposing of them often makes more sense than packaging them in the application.
Use
flushanddisposeon objects as often as you can, and be sure to set all objects tonullwhen you're done with them.Watch out for hashtables—they eat memory for breakfast. Try to limit them to a few dozen elements.
For animation, use PersonalJava's built in automated double-buffering rather than copying graphics onto your screen one frame at a time.
Instead of spawning your own memory-intensive threads, use PersonalJava's Timer API.
The Java community is currently fleshing out a J2ME profile especially for PDA devices and other handheld organizers. This profile will extend and enhance the CLDC, and can be found at http://jcp.org/jsr/detail/75.jsp.
It is shaping up to be similar to the MIDP, but with better graphics and user interface features, and less support for wireless network functionality.
The PDA Profile will likely have a user interface toolkit that is a subset of Java Standard Edition's Abstract Window Toolkit (AWT). It might also support infrared beaming and persistent storage of data.
The target platform will have these characteristics:
Information on the Java Game Profile proposal can be found at http://jcp.org/jsr/detail/134.jsp. This proposal is for a J2ME profile that will cover nine areas of game development:
3D modeling and rendering, including effects such as reflection mapping, stencil buffer-based shadow volumes, and so on.
3D physics modeling.
3D character animation.
2D rendering and video buffer management, page flipping, hardware-accelerated BLT, line draw, and rectangular fill.
Game message marshalling and network communication.
Streaming media and high-quality video playback.
Sound effects and background music, including support for such formats as MP3, MIDI, streaming audio, and popular voice codecs.
Access and discovery of game controllers such as joysticks, gamepads, and steering wheels.
Hardware access. The Java Virtual Machine, under the game profile, will likely be able to access memory outside the Java heap. This will enable the program to load game data and memory more efficiently and to access video graphics memory directly for quicker rendering and special effects.
This will allow for a relatively high-end gaming platform. Development of this profile is very exciting for both Java and gaming enthusiasts. If this profile is successful and receives support from major game console manufactures, a game design studio will be able to create one amazing kick-butt game and deploy it on dozens of different systems. Currently, developers must spend millions of dollars porting their games from one console to another.
The idea is to pare down the Java 2 Standard Edition API, which is focused on database and e-business applications, and create a brand new profile geared exclusively towards games. This profile will likely be based on the CDC and Foundation Profile.
There are many existing APIs that support graphics, sound, and other gaming needs. For example, the Java Media Framework (JMF) API supports streaming of audio and video, the Java3D API handles 3D rendering, and Java2D with its VolatileImage and Graphics2D classes allow for quick-drawing rendering effects.
The gaming profile will likely leverage as many existing APIs as possible, and spawn a whole new set of Java APIs for things such as physics modeling.
The target platform is high-end consumer game devices, ranging from handsets such as the GameBoy to consoles such as the PlayStation 2 and Xbox.
The J2ME Multimedia Profile can be found at http://jcp.org/jsr/detail/135.jsp. This proposed multimedia API specification gives developers high-level access to the sound and multimedia capabilities of J2ME devices.
Although many mobile devices can only produce single monophonic sounds, others feature both sampled, synthetic audio and other rich media types. The J2ME Multimedia Profile will be able to handle, generate, and playback sound in all these formats.
Simple controls will handle the lower common denominator, and additional functions will be available for devices that support more advanced audio.
The Multimedia Profile will also allow for time-based synching of images with audio, using formats similar to SMIL.
As there are tons of different types of devices, there are different types of Java. PersonalJava cleverly brings the power of the Java Standard Edition into smaller spaces.
In the next chapter, we'll look at yet another breed of Micro Java—NTT DoCoMo's iAppli profile. This profile will allow you to develop kick-butt Java applications in Japan and beyond.