Programming Wireless Devices with the Java2 Platform
| [ directory ] |
|
19.1 MIDlet SuitesOne of the central goals for the MIDP application model is to provide support for the controlled sharing of data and resources between multiple, possibly simultaneously running MIDlets. To accomplish this goal while retaining a secure environment, the MIDP Specification requires that any MIDlets needing to interact and share data beyond what is enabled with the RMS record sharing in MIDP 2.0 (refer to Section 14.2.2, "Shared Record Stores"), the MIDlets must be placed into a single JAR. This collection of MIDlets encapsulated in a JAR is referred to as a MIDlet suite. The MIDlets within a MIDlet suite share a common name space (for persistent storage), runtime object heap, and static fields in classes. In order to preserve the security and the original intent of the MIDlet suite provider, the MIDlets, classes, and individual files within the MIDlet suite cannot be installed, updated, or removed individually梩hey must be manipulated as a whole. In other words, the basic unit of application installation, updating, and removal in MIDP is a MIDlet suite. A MIDlet suite can be characterized more precisely by its packaging and its runtime environment. These characteristics are discussed in more detail next. 19.1.1 MIDlet Suite PackagingA MIDlet suite is encapsulated within a JAR.[1] A MIDlet suite provider is responsible for creating a JAR that includes the appropriate components for the target user, device, network, and locale. For example, since the CLDC Specification does not include the full internationalization and localization support provided by Java 2 Standard Edition, a MIDlet suite provider must tailor the JAR components to include the necessary additional resources (strings, images, and so forth) for a particular locale.
The contents of the MIDlet suite's JAR include the following components:
All the files needed by the MIDlet(s) are placed in the JAR using the standard structure based on mapping the fully qualified class names to directory and file names within the JAR. Each period is converted to a forward slash, '/'. For class files, the .class extension is appended. 19.1.2 Application DescriptorEach JAR may be accompanied by an optional[2] application descriptor (JAD file.) The application descriptor allows the application management software on the device to verify that the associated MIDlet suite is suitable for the device before loading the full JAR. It also allows MIDlet attributes to be supplied to the MIDlet suite without modifying the JAR.
The application descriptor that has the MIME type 'text/vnd.sun.j2me.app-descriptor' and the file name extension '.jad'. The contents of the application descriptor are described by the following BNF syntax:
appldesc: *attrline
attrline: attrname ":" WSP attrvalue WSP newlines
attrname: 1*<any Unicode char except CTLs or separators>
attrvalue: *valuechar | valuechar *(valuechar | WSP) valuechar
valuechar: <any valid Unicode character, excluding CTLs and WSP>
newlines = 1*newline ; allow blank lines to be ignored
newline: CR LF | LF
CR = <Unicode carriage return (0x000D)>
LF = <Unicode linefeed (0x000a)>
WSP: 1*( SP | HT )
SP = <Unicode space (0x0020)>
HT = <Unicode horizontal-tab (0x0009)>
CTL = <Unicode characters 0x0000 - 0x001F and 0x007F>
separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "'" | <">
| "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT
19.1.3 MIDlet AttributesThe JAR manifest and application descriptor provide a means to encode information about the contents of the JAR. In particular, the JAR manifest specification provides for name-value pairs that MIDP uses in the manifest and application descriptor to encode MIDlet attributes. MIDlet attribute names are case-sensitive. A predefined set of attributes is specified to allow the application management software to identify, retrieve, and install the MIDlet(s). Attribute names that start with "MIDlet-" or "MicroEdition-" are reserved for use by the MIDP expert group to define MIDP-specific MIDlet attributes. MIDlet suite developers can define their own MIDlet attributes provided that the new attributes do not start with the reserved "MIDlet-" or "MicroEdition-" prefixes. The MIDP Specification currently defines the MIDlet attributes shown in Table 19.1 on page 328. All attributes appearing in the application descriptor are made available to the MIDlet(s) through the MIDlet.getAppProperty method. In general, attributes can be located in either the application descriptor or the JAR manifest; however, some attributes must be located in specific places, as described next. Of the predefined attributes in Table 19.1 on page 328, the following must be in the JAR manifest:
The following attributes must be in the application descriptor, if present:
The manifest or the application descriptor must contain the following attributes:
The manifest or the application descriptor can additionally contain the following attributes:
A rudimentary form of version control between the JAR and the application descriptor is ensured by requiring that the attribute values for MIDlet-Name, MIDlet-Version, and MIDlet-Vendor be identical in the JAR manifest and the application descriptor. If they are not, then the system will assume a version mismatch, and the MIDlet suite will not be installed. All other MIDlet attributes names may also be duplicated. In the case of untrusted MIDlets, the values from the application descriptor will override the values from the JAR manifest. In the case of trusted MIDlets the values must be identical. See Section 18.3, "Trusted MIDlet Suite Security Model," for an expanded description of the trusted MIDlet security model. As an example, the following shows a JAR manifest for a hypothetical MIDlet suite of card games provided by Motorola. The suite contains two MIDlets: Solitaire and JacksWild: MIDlet-Name: CardGames MIDlet-Version: 1.1.9 MIDlet-Vendor: Motorola MIDlet-1: Solitaire, /Solitaire.png, com.motorola.Solitaire MIDlet-2: JacksWild, /JacksWild.png, com.motorola.JacksWild MicroEdition-Profile: MIDP-2.0 MicroEdition-Configuration: CLDC-1.1 The corresponding application descriptor for this MIDlet suite would look like this: MIDlet-Name: CardGames MIDlet-Version: 1.1.9 MIDlet-Vendor: Motorola MIDlet-1: Solitaire, /Solitare.png, com.motorola.Solitare MIDlet-2: JacksWild, /JacksWild.png, com.motorola.JacksWild MicroEdition-Profile: MIDP-2.0 MicroEdition-Configuration: CLDC-1.1 MIDlet-Description: Really cool card games MIDlet-Jar-URL: http://www.cardsrus.com/games/cardgames.jar MIDlet-Jar-Size: 7378 MIDlet-Data-Size: 256
19.1.4 MIDlet Suite Execution EnvironmentThe MIDP Specification defines the environment in which MIDlets within a suite execute. This environment is shared by all MIDlets within a MIDlet suite, and any MIDlet can interact with other MIDlets packaged in a suite. The runtime environment is logically composed of name spaces, as depicted in Figure 19.1. These name spaces determine how a MIDlet accesses an entity within that name space. Figure 19.1. MIDlet suite name spaces
The logical name spaces in a MIDlet's runtime environment are as follows:
All the classes needed by a MIDlet within a suite must be in the JAR or in the system libraries (system libraries typically include the CLDC and MIDP libraries as well as optional packages and manufacturer-specific libraries.) A MIDlet may load and invoke methods from any class in the JAR or in the system libraries. All of the classes within these scopes are shared in the execution environment, along with a single heap containing the objects created by MIDlets, MIDP libraries, and CLDC libraries. The usual locking and synchronization primitives of the Java programming language can be used where necessary to avoid concurrency problems. The class files of the MIDlet are only available for execution and can neither be read as resources nor extracted for reuse, since the underlying CLDC implementation may store and interpret the contents of the JAR in any manner suitable for the device. The non-class files within the JAR, including the JAR manifest, can be accessed using the method java.lang.Class.getResourceAsStream. The parameter to this method, a String object, represents a path that is interpreted in the following manner: If it begins with a '/', the search for the resource begins at the "root" of the JAR; however, if it does not begin with a '/', the resource is searched for along a path relative to the class instance retrieving the resource. For example, if a JAR has the following contents as shown in this JAR manifest: META-INF/ META-INF/MANIFEST.MF examples/ examples/HelloWorld.class then, in the following code fragment, both getResourceAsStream calls will open an InputStream to the manifest.
Class C = Class.forName("examples.HelloWorld");
InputStream s1 = C.getResourceAsStream("/META-INF/MANIFEST.MF");
InputStream s2 = C.getResourceAsStream("../META-INF/MANIFEST.MF");
|
MIDlet-Permissions
| [ directory ] |
|