If you are engaged in game development, you might want to consider using Java 2 Micro Edition. This article will help get started; soon, you'll be well on your way to building your first game. It is excerpted from J2ME Games with MIDP2, written by Carol Hamer (Apress, 2004; ISBN 1590593820).
Getting Started with J2ME - Using KToolbar (Page 3 of 5 )
The MIDlet development environment KToolbar is easy to use, and it’s well documented. Even if you’re not planning to use KToolbar, you should definitely browse the documentation a bit so you have a good idea of what sorts of tasks KToolbar can do (you may decide you want to use it after all...).
KToolbar is a “minimal” development environment in the sense that, unlike JBuilder, it doesn’t contain a text editor. It’ll create and update your jad and manifest files and your project’s directory tree for you after you fill in the details in a set of Graphical User Interface (GUI) windows, but you have to create all the source files yourself in your own text editor. Also unlike JBuilder, it doesn’t create its own project file describing your project. This is handy because you can open a “project” in KToolbar, even if you created the directory tree for the project yourself, instead of having KToolbar create it for you. All you need to do is make sure your project’s root directory is in the right place (in the apps folder inside the WTK2.0 folder), and you can open it as a project in KToolbar.
In addition to setting up your project, KToolbar will preverify and build your project and then run it in the emulator at the click of a GUI button. It also has a whole suite of useful features for debugging and performance monitoring. Plus, it has tools for signing your MIDlet. (Chapter 7 covers more about signing.) Figure 1-3 shows what KToolbar looks like.
Figure 1-3. KToolbar
Compiling and Running from the Command Line
Running the MIDlet in the emulator from the command line is simple. All I did was go to the bin directory under the toolkit’s WTK2.0 directory. From there I typed ./bin/emulator followed by an option giving the name of the jad descriptor file corresponding to the MIDlet I wanted to run. For example, to run the “Hello, World” application on my system, I typed the following line:
Another useful option when running the emulator from the command line is the option that gives you a choice of different devices. The option is -Xdevice, and the choices are DefaultColorPhone, DefaultGrayPhone,MediaControlSkin, and QwertyDevice. The previous command including this option looks like this (note that it needs to be typed on a single line):
Figure 1-4 shows the DefaultColorPhone emulator. You’ll find other emulator options listed in the toolkit documentation’s “Running the Emulator” section.
Figure 1-4. The DefaultColorPhone emulator
As I mentioned previously, if you rebuild your project from the command line using the scripts bundled with the toolkit, you’ll need to update the MIDlet-Jar-Size property in your jad file after rebuilding. This isn’t necessary if you’re using
KToolbar, but personally I like to build my jar files myself whenever possible so I know what’s in them. If you’re planning to build your jar files using scripts, you’ll probably want to change the build script so you won’t have to update the jad file by hand in a text editor after every build. This section assumes that you’re using Linux or Unix. (I’d guess that those people who aren’t using Linux/Unix are also not building their jar files from the command line, so they probably have already skipped this section.)
The build script in Listing 1-4 requires that the MIDlet-Jar-Size property is the last line of the jad file, as it is in the examples I provided. Note that this script assumes you have a file tree configured as follows: Under your project’s main directory, you must have four subdirectories: bin (which contains this script as well as the jad and MANIFEST.MF files), a tmp classes directory (which may be empty), a classes directory (containing a subdirectory called images that contains all of your image files), and a src directory that contains the directory tree for the source code of the MIDlet you’d like to compile.
Listing 1-4. Build Script
# This script builds and preverifies the code # for the example games. # reset this variable to the path to the correct javac # command on your system: JAVA4_HOME=/usr/java/j2sdk1.4.0_01/bin # reset this variable to the corresct path to the WTK2.0 # directory of the WTK2.0 toolkit that you downloaded: WTK2_HOME=../../../WTK2.0 echo "clear directories" # it's better not to leave old class files lying # around where they may accidentally get picked up # and create errors... rm ../tmpclasses/net/frog_parrot/*/*.class rm ../classes/net/frog_parrot/*/*.class echo "Compiling source files" $JAVA4_HOME/javac -bootclasspath $WTK2_HOME/lib/midpapi.zip \ -d ../tmpclasses -classpath ../tmpclasses ../src/net/frog_parrot/*/*.java echo "Preverifying class files" $WTK2_HOME/bin/preverify \ -classpath $WTK2_HOME/lib/midpapi.zip:../tmpclasses \ -d ../classes ../tmpclasses echo "Jarring preverified class files" $JAVA4_HOME/jar cmf MANIFEST.MF hello.jar -C ../classes . echo "Updating JAR size info in JAD file..." NB=`wc -l hello.jad | awk '{print $1}'` head --lines=$(($NB-1)) hello.jad > hello.jad1 echo "MIDlet-Jar-Size:" `stat -c '%s' hello.jar`>> hello.jad1 cp hello.jad1 hello.jad
Java 
/ 45 
Introduction to WAP using WML, ASP and PHP
