MIDPIn the previous section, you looked at the functionality of the CLDC, although most of what you reviewed was more about the limitations of the configuration in comparison to J2SE. Also, you might have noticed the omission of some of the things you really need to build an application, such as any form of user interface. These components are device-specific, so it's up to a device category's profile to implement them. This typifies the role of the profile: to add category-specific components on top of a configuration. The most popular profileand the only one really useful for your purposesis MIDP, which targets MIDs (Micro Information Devices). Since MIDP is all about MIDs, take a look at what the profile defines them to be. Target DevicesMIDs aren't the most capable of computers, and I'm probably using the term computer a little loosely here. MIDs are highly portable, uncoupled devices that always compromise functionality for form. The MIDP specifications reflect this by setting a lowest-common-denominator target platform that can be met by a broad range of handheld devices, especially mobile phones. The MIDP sets target characteristics that MIDs should (and generally do) meet. There are both hardware and software specifics, both of which I will discuss in more detail in just a moment. Target Hardware EnvironmentAs you can see in the following list, the characteristics of the target devices are extremely limited. The screens are tiny, the memory is forgettable, and the CPUs move about as fast as I do on a Monday morning. However, it's important to remember that these characteristics are the minimum target. Many devices dramatically exceed these specifications. Much larger, color screens; more RAM; better input; and next-generation networking are becoming common on an ever-increasing range of devices. Games on the higher-end devices can be downright sexy. Even on low-end hardware, you can still make some great games; it's just a bit more of a challenge. In later sections, I'll also cover how to develop a game that can adapt itself to take advantage of additional hardware functionality, if available. The recommended minimum MIDP device characteristics are
NOTE
Note In addition to the listed characteristics, all MIDs are also capable of displaying 2048 x 1536 FSAA 3D graphics and real-time Dolby Digital surround sound. No reallythey are! You just have to find the right combination of keys to unlock the secret hardware Easter egg in every phoneand make sure you send me an e-mail if you ever find it. Target Software EnvironmentAs with the target hardware environment, the software that controls MIDs can vary significantly in both functionality and power. At the higher end of the market, MIDs are not dissimilar to small PCs. At the low end, however, some components you would consider fundamental to the concept of a computer aren't available, such as a file system. Due to this variety, the MIDP specifications mandate some basic systems software capabilities. The following list shows the most relevant of these capabilities.
NOTE
Note Volatile memory (also known as dynamic memory, heap memory, or just plain RAM) stores data only as long the device retains power. Non-volatile memory (also known as persistent or static memory, typically using ROM, flash, or battery-backed SDRAM) stores information even after the device has been powered down. NOTE
MIDP's Pedigree Like the CLDC, the MID profile development was part of the Java Community Process expert group (JSR-37). The companies involved were
MIDP ApplicationsA Java program written to be executed on a MID is called a MIDlet. (Who comes up with these names? I would prefer to call it something cooler, like a microde or a nanogram hmm, no, that sounds like a really tiny telegram.) The MIDlet is subject to some rules regarding its run-time environment and packaging. I'll cover each of these rules in a bit more detail in the next few sections. Run-Time EnvironmentIt is the role of the device's built-in application manager to start the MIDlet. It's important to know that your application has access to only the following resources:
From this list, you can start to see the structure of a typical MIDlet game package. Most importantly, the JAR file should contain all the classes required to run the application, along with all the resources, such as image files and level data. You can also set application execution options as properties within the plain text MIDlet descriptor file. NOTE
Tip You can bundle multiple MIDlet applications within one JAR file; these applications can then share resources. That's where the term MIDlet suite comes fromit's a suite of MIDlets. Suite PackagingAs I just mentioned, a MIDlet application typically takes the form of a JAR file. This archive should contain all of the class and resource files required for your application. It should also contain a manifest file with the name manifest.mf. The manifest, stored inside the JAR file, is simply a text file containing attribute value pairs (separated by a colon). Table 2.3 lists all of the types of required and optional attributes included in a manifest file.
In the case where your manifest file contains information on multiple MIDlets (a MIDlet suite), you should use the MIDlet-<N> attributes to specify information on each of the individual MIDlets within the package. Typically, though, your package will only have one application so this isn't too much of a concern. Of course, you can add your own attributes to the manifest file. The only rule is that they cannot begin with the MIDlet- prefix. Also keep in mind that attribute names must match exactly, including case. You might also wonder what the point of the MIDlet-Jar-URL attribute is. Given that the manifest file has to be included within a JAR, you might rightly ask, why bother having a URL to go and download a JAR when you obviously must have the JAR to know the URL in the first place? The answer is, you don't need to bother having this attribute in your manifest fileit's intended for use in the application descriptor (JAD) file reviewed later in this section. The attribute is in the list because the manifest file also serves as the default for any attributes not contained within the JAD. The creators of the specifications for MIDP elected to create a single set of attributes for both the manifest and JAD files. A reasonable thing to do, but it still left me confused the first time I read the specifications. NOTE
Tip MIDlet version numbers should follow the standard Java versioning specifications, which essentially specify a format of Major.Minor[.Micro], such as 1.2.34. I generally use the major version to indicate a significant functional variation, the minor version for minor features and major bug fixes, and the micro for relatively minor bug fixes. The following is an example of a manifest file:
Application Descriptors (JADs)Transferring large amounts of data around mobile networks is a bit like trying to send an encyclopedia via carrier pigeon (otherwise known as CPIP). For this reason, a descriptor file is available to allow users to view the details of a MIDlet JAR without actually having to download the whole thing. The application descriptor file, or JAD, serves this purpose. It contains essentially the same attributes as those in the manifest, and it naturally exists independent of the JAR file. Figure 2.6 shows the relationship between all the components of a MIDlet suite and a JAD file. Figure 2.6. A single JAR file contains multiple MIDlet applications, along with their resources. A manifest and JAD are included to describe the details of the contents.
There is a close link between the JAD and the manifest files. You should think of the JAD as a mini-version of the manifest. The following attribute values must be the same in both files, or else the MIDP application manager will reject the MIDlet suite:
For all other attributes, the values in the JAD file take precedence. NOTE
Caution At some point in the distant future, a small man wearing a white safari suit and carrying a large briefcase bearing the word "Reviewer" will suddenly appear next to your desk. He will undoubtedly demandin an upper-class English accentto know why you have included MIDlet-<n> attributes within your JAD files when, upon review of the specification (he will hold it in front of your nose), it clearly says they aren't supposed to be there! Well, tell him to "nick off"; without the MIDlet-<n> attributes, the current Sun MIDP emulator won't display your MIDlets. Assume they're required for now, and argue with the Specinator later. The following is an example of a JAD file:
As you can see, the primary difference between the JAD and the manifest examples is the inclusion of the two MIDlet-Jar attributes. Using these attributes, the application manager can determine the download and device storage requirements for your game. NOTE
Tip The MIDlet-Jar-Size attribute is rather cumbersome because it requires updating every time your code or resources change. Constantly updating this value by hand is a pain, so I'll show you a great way to automate the process using a build script in Chapter 14, "The Device Ports." MIDP 1.0 LibrariesThe MIDP specification does a good job of locking down the hardware characteristics of MIDs for you, but there's more to developing applications than just describing the hardware. The MIDP also delivers the real guts of the J2ME mobile software solutionthe libraries. The MIDP libraries provide tools designed specifically for the idiosyncrasies of development on MIDs. This includes access to:
I'll review the details of all of these API parts in Chapter 5, "J2ME API." For now, you can review the following list of available classes.
| ||||||||||||||||||||||||||||