MIDP the API
What's here, what's not?
As you start developing for MIDP you will soon see that the API is relatively small and compact. The API consists of 7 nicely Class packages:
- java.io - Provides data stream classes that among other things are useful for reading from resources (level files, images, sounds..)
- java.lang - Includes the basic Java Classes derived from the J2SE API. All important classes like Thread, primitive wrapper classes ( Byte, Short, Integer..) and a cut down Math class.
- java.util - A subset of the J2SE java.util package that holds a set of helpful utility classes like Random, Vector, Hashtable and the TimerTask class.
- javax.microedition.io - This package contains all the networking related classes and interfaces. Be aware that HTTP is the only mandatory network protocol in MIDP implementations.
- javax.microedition.lcdui - The mightiest package of them all! Includes classes both for low and high level UI operations. The high level components include Forms, Lists, TextFields and Commands all-important to handle user input and navigation. Most commonly used in games for menus and instruction screens. Among the low level objects are Canvas, Graphics and Image which provide you with typical game actions like drawing to the screen and catching user input.
- javax.microedition.midlet - the midlet package defines the entry and exit point for MIDP applications (MIDlets). It contains a single Class (yes, the MIDlet class) which is used by the AMS (Application management software) to control the lifecycle or state of your MIDlet. All MIDP applications you make must have a class that extends the MIDlet class to allow the AMS to (most importantly) start and stop your application.
- javax.microedition.rms - the rms package provides you with mechanisms to store data persistently. Nice to use for storing high scores, save games and the likes! The basic storage elements are referred to as records which you can read and write via the RecordStore class. (you might be used to store data in a local file, but in MIDP you would write it to a RecordStore, as you have no access to the file system as such)
If you have previous experience from Java programming, maybe even made an Applet or two you will see quite a few similarities with the J2SE counterpart. And the basics of MIDlet development will be quicker to pick up. If you are new to Java all these packages and classes might sound quite daunting, but once you have your MIDlet running you will soon enough grasp what is needed to complete your game project!
The MIDlet
MIDP applications are called MIDlets (similar to the well known Applet), the files you can consider the MIDP executable are the Jad and Jar files.
The Jar file is archive (zip file) including most importantly your games Class files and resources. It also includes a Java Manifest file which along with the Jad (Java Application Descriptor) file contains vital information about your MIDlet.
We will find out exactly what is included in these files alittle later!
The building blocks
As mentioned the basic building block and entry point of your application (ok lets call it your game), game, is the MIDlet class. Also mentioned earlier was the AMS which is the piece of software on the device that manages your games lifecycle. When the user opens his list of games and decide to start your game the AMS will create a new instance of your main class, the one that extends MIDlet. The AMS will use the default (no argument) constructor of your MIDlet class to do this. If no error / Exception occurs when doing so, it will call the startApp() method on the new MIDlet instance. Your MIDlet is now in "active" state, this is where you gain control and can start performing your magic!
Another important building block for your game is the Canvas, which defines the all imporant methods to draw to the screen and capture user input. The Canvas class itself extends a class called Displayable, the Displayable class is an base for all objects that can be "placed onto" the devices display, such as Lists and Forms.
The Canvas class defines several important methods that we should take at now so you will be mentally prepared for what is to come later! The methods are commonly referred to as event delivery methods, they deliver events that you can handle as needed in your game:
- keyPressed( int keyCode ) - Indicates that a key has been pressed. Which key that has been pressed can be identified through the single int parameter of the method.
- paint( Graphics g ) - this is called by the Virtual Machine when a scheduled repaint is performed. The Graphics parameter is the object used to render to the Canvas. NOTE: you should never call paint manually, if you want the Canvas to be repainted you can call repaint() on the Canvas!
- keyReleased( int keyCode ) - works the same way as keyPressed() but is triggered by the release of a key.
Important limitations and pitfalls
The last thing to do before we make your first MIDlet is to identify some all important limitations and pitfalls. (don't let these scare you!)
- Do not believe the myth that there is no transparency support in MIDP. Most devices and emulators support transparent images. (Some require the pngs to be saved as 24bit as opposed to indexed mode). Some devices (Nokia) even support alpha transparency!
- MIDP has no floating point support. (no double or float) But this should not limit your possibilities as fixed point math will come to your rescue!
- No trigonometry functions. So once again its time to dig out those lookup tables!
- No direct access to image data (pixels) through generic MIDP. So for example common tasks like get()'ing and set()'ing of pixels are not possible.(not quite true for set()'ing as you can draw a 1 pixel line or rectangle to do this) But there are some devices (Nokia) that provide you with device specific methods to access the pixels and image data.
- No generic support for rotation / scaling of images. Although some devices provide (Nokia) you device specific methods for this. Commonly rotation in 90 degrees increments and flipping both horizontally and vertically are implemented in device specific libraries.
- Graphic modes are not palette based. 4096 is the most common colour count.
- Most phones do not support multiple simultaneous key presses.
- Watch your application size. Most devices have a defined maximum application size ranging from 30kb on the low end b&w phones to the more generous 180kb limits on the high end colour phones. For colour games a good target when it comes to application size is 64kb which is the lowest limit around for colour MIDP devices. (Remember to always check the application size limit for each phone you target!)
- Try to keep the amount of classes in your game to a minimum, as each class will add size overhead and heap memory overhead to your game. Sometimes you will even have to break common design rules to get around the size and speed limitations. (For example using accessor methods like getX(), setX() are considered an unnecessary overhead)
- If you are planning to support a wide range of devices, don't put game related logic in the class that extends Canvas. As on some devices (Nokia for example ;) ) where you night want to extend a device specific Canvas class called FullCanvas. So the less game logic you have in your Canvas class the less unique code you need for different device versions of your game!
- Remember to obfuscate your Class files! Not only does this reduce the size of your files, it makes it harder for others to decompile your game. (http://proguard.sourceforge.net/ , http://www.retrologic.com/retroguard-main.html)
Ok, enough already! lets go!
First MIDlet
|
|
Unite 2010
