Addison wesley programming wireless devices with the java 2 platform micro edition 2nd edition jun 2003 ISBN 0321197984

[ Team LiB ] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] K Virtual Machine KVM: [See K Virtual Machine] key events keys [ Team LiB ] Brought to You by Like the book? Buy it! [ Team LiB ] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] Abstract Windowing Toolkit addCommand addTicker Alert 2nd Screen:Alert Ticker on Alert AlertType alpha-channel AMS animated Gauge ANY API documentation MIDP application development environment management management software application launch event-driven usage scenarios application management software application management software (AMS) application manager Application provided operations application push sample application application startup application:descriptor MIDP:application:descriptor application:Java Java application Arabic Arabic-Indic digit input automatic casing automatic launching MIDlet AWT [ Team LiB ] [ Team LiB ] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] BACK 2nd 3rd background background color backlight backward navigation battery life business applications button 2nd BUTTON byte arrays converting record data to and from [ Team LiB ] [ Team LiB ] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] CANCEL 2nd Canvas 2nd [See also canvas]3rd [See also canvas]4th [See also canvas] adaptation to device user interface style class:Canvas: [See also Canvas]2nd [See also Canvas]3rd [See also Canvas] canvas events action key pointer canvas:coordinate system coordinate system canvas:redrawing mechanism redrawing repainting 2nd 3rd 4th 5th 6th 7th 8th 9th canvas:visibility visibility CDC Connected Device Configuration: [See CDC] certificate root CA certificate expiration and revocation Certificate processing for Over-The-Air (OTA) delivery Choice ChoiceGroup 2nd Item:types:ChoiceGroup class file format loaders user-defined Screen SeeScreen types collection data 2nd input/output class:Calendar class:Time Calendar;Time class:CLDC-specific CLDC:classes:-specific class:CLDC:derived from J2SE CLDC:classes:derived from J2SE class:Date Date class:file:format:supported format:class file:supported class:file:lookup order file:class:lookup order class:file:lookup order:restrictions file:class:lookup order:restrictions class:loading loading:classes class:system system:classes class:types:exception class:types:error error classes;exception classes class:types:utility utility classes CLDC architecture chapter configuration:CLDC Java 2 Micro Edition:configuration:CLDC Connected, Limited Device Configuration: [See CLDC] expert group 2nd goals 2nd specification virtual machine differences user-defined class loaders CLDC:API documentation API documentation:CLDC CLDC:application model application:model:CLDC CLDC:libraries:chapter libraries:CLDC: [See CLDC, libraries] CLDC:requirements:hardware requirements:CLDC:hardware CLDC:requirements:software requirements:CLDC:software CLDC:system properties system:properties clipping graphics:clipping 2nd collection classes color color capabilities 2nd 3rd color model graphics:color model color scheme of a device COLOR_BORDER COLOR_FOREGROUND Command 2nd command abstract listeners Command long label short label Command label Command priorities Command priority Command type Command types 2nd commandAction system screens CommandListener 2nd 3rd 4th Commands communication ports Generic Connection framework example compatibility concurrency configuration Java 2 Micro Edition:configuration 2nd configuration:requirements Java 2 Micro Edition:configuration:requirements connection establishing Connection security properties of connection states closed connected setup 2nd Connection interface connection:HTTP:using HTTP:using a connection container content area content size context-sensitive menu CONTINUOUS_RUNNING Control interface Current Alignment current Displayable 2nd 3rd 4th current screen custom components CustomItem 2nd 3rd 4th adaptation to device user interface style [ Team LiB ] [ Team LiB ] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] data type classes datagrams Generic Connection framework example DataSource class and protocol handling DateField 2nd Item:types:DateField DECIMAL default Command 2nd device fonts device properties device vibrator device-provided operations devices consumer specialized nature of target characteristics Display 2nd 3rd Displayable 2nd 3rd 4th 5th actually visible automatically changing drawing images mutable drawing:arcs arcs:drawing and filling filling:arcs drawing:lines lines:drawing drawing:rectangles filling:rectangles rectangles:drawing and filling drawing:rectangles:rounded filling:rectangles:rounded rectangles:rounded:drawing and filling 2nd drawing:text text:drawing 2nd 3rd 4th [ Team LiB ] [ Team LiB ] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] editing modes EMAILADDR embedded systems encoding:character character encoding error handling:CLDC CLDC:error handling errors CLDC:virtual machine differences:errors events action key pointer example NetClientMIDlet example:timers timers:example EXCLUSIVE EXIT 2nd [ Team LiB ] [ Team LiB ] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] failure:non-transient non-transient failure failure:transient transient failure file:application resource application:resource files MIDP:application:resources files file:application-specific resource application: resource files, specific finalization CLDC:finalization CLDC:virtual machine differences:finalization flashBacklight Focus focus focus traversal font Font 2nd FONT_INPUT_TEXT FONT_STATIC_TEXT fonts graphics:fonts foreground 2nd foreground color Form 2nd 3rd Screen>Default Para Font>:Form Form layout format class file [ Team LiB ] 18.4 APIs That Are Not Security Sensitive APIs and functions that are not security sensitive are accessible by all MIDlet suites These APIs are listed in Table 18.3 Table 18.3 APIs freely permitted for all MIDlet suites API Description javax.microedition.rms RMS APIs javax.microedition.midlet MIDlet Life-cycle APIs javax.microedition.lcdui User Interface APIs javax.microedition.lcdui.game The Game APIs javax.microedition.media javax.microedition.media.control The multimedia APIs for playback of sound 2.4 Evolution of the J2ME Platform After the successful completion of the CLDC and MIDP standardization efforts, a number of additional J2ME standardization efforts have been launched to complement the functionality provided by the core standards Most of these additional efforts define optional packages that can be deployed on top of MIDP These efforts are summarized in Section 2.4.2, "Optional Packages for the Wireless Market" below In addition, there are a number of more fundamental, core standardization efforts that are summarized in Section 2.4.1, "Core J2ME Standardization Efforts." 2.4.1 Core J2ME Standardization Efforts There are a number of standardization activities that have an important role in defining the overall J2ME architecture These efforts can be viewed as "umbrella" activities that specify the ground rules for a number of standardization activities or provide additional instructions, recommendations, and clarifications for binding together the existing J2ME standards: JSR 68: J2ME™ Platform Specification JSR 185: Java™ Technology for Wireless Industry JSR 68: J2ME™ Platform Specification This specification defines the "ground rules" for the J2ME platform architecture and J2ME standardization activities It formalizes the fundamental concepts behind J2ME, such as the notions of a configuration and profile, and defines how new J2ME APIs can be formed by subsetting existing APIs from the Java 2 Platform, Standard Edition (J2SE) JSR 185: Java™ Technology for the Wireless Industry (JTWI) This specification defines how various technologies associated with MIDP work together to form a complete handset solution for the wireless services industry The specification provides an exposition of the overall architecture of the wireless client software stack, including a description of the following aspects: Which optional packages fit with which profiles? How does an end-to-end solution for interoperable Java applications work? How does the migration of applications occur, and to which profiles, as the devices become more capable? A key goal of the JTWI Specification is to minimize the fragmentation of the Java APIs in the mobile handset market by creating a community that coordinates the API evolution and deployment as the industry continues to expand the capabilities of mobile devices To accomplish this, the JSR 185 expert group coordinates the creation of new J2ME-related JSRs and provides recommendations for new optional packages that could take place within the context of the wireless development community as a whole 2.4.2 Optional Packages for the Wireless Market The following standardization efforts define optional packages that can reside on top of MIDP: JSR 120: Wireless Messaging API JSR 135: Mobile Media API JSR 172: J2ME™ Web Services Specification JSR 177: Security and Trust Services for J2ME™ JSR 179: Location API for J2ME™ JSR 180: Session Initiation Protocol (SIP) for J2ME™ JSR 184: Mobile 3D Graphics for J2ME™ JSR 190: Event Tracking API for J2ME™ Each of these efforts is summarized briefly below JSR 120: Wireless Messaging API This JSR defines a set of optional APIs that provide standardized access to wireless communication resources, allowing thirdparty developers to build intelligent connected Java applications The specification addresses the following wireless technologies: Short Message Service (SMS), and Cell Broadcast Service (CBS) JSR 135: Mobile Media API (MMAPI) This JSR specifies a multimedia API for J2ME, providing straightforward access and control of basic audio and multimedia resources and files The MIDP 2.0 Sound API (introduced in Chapter 13 of this book) is a subset of the Mobile Media API defined by JSR 135 JSR 172: J2ME™ Web Services Specification This specification defines an optional package that provides standard access from J2ME devices to Web services The JSR is designed to provide an infrastructure to provide basic XML processing capabilities, enable reuse of Web service concepts when designing J2ME clients to enterprise services, provide APIs and conventions for programming J2ME clients of enterprise services, adhere to Web service standards and conventions around which the Web services and Java developer community is consolidating, enable interoperability of J2ME clients with Web services, and provide a programming model for J2ME client communication with Web services, consistent with that for other Java clients such as J2SE JSR 177: Security and Trust Services API for J2ME™ The purpose of this JSR is to define a collection of APIs that provide security services to J2ME devices These APIs are a necessary step for a device to become trusted, that is, to provide security mechanisms to support a wide variety of application-based services, such as access to corporate network, mobile commerce, and digital rights management Many of these services rely on the interaction with a "security element" (such as a smart card) in the device for secure storage and execution, as described below: Secure storage to protect sensitive data, such as the user's private keys, public key (root) certificates, service credentials, personal information, and so on Secure execution, such as cryptographic operations to support payment protocols, data integrity, and data confidentiality Custom and enabling security features that J2ME applications can rely on to handle many valued-added services, such as user identification and authentication, banking, payment, ticketing, loyalty applications, and digital media playing The JSR 177 specification defines an access model and a set of APIs that enable applications running on a J2ME device to communicate with a smart card inserted in the device, providing a flexible mechanism to allow service and equipment providers to define secure operations JSR 179: Location API for J2ME™ This specification defines an optional package that enables developers to write mobile, location-based applications for J2ME devices The purpose of the specification is to provide a compact and generic API that produces information about the device's present physical location to Java applications This specification defines a generic interface that works with most positioning methods, such as GPS and E-OTD JSR 180: Session Initiation Protocol (SIP) for J2ME™ The Session Initiation Protocol (SIP) is used to establish and manage multimedia IP sessions This same mechanism can also be used to provide instant messaging, presence, and gaming services This specification defines a general SIP API for J2ME devices based on the SIP protocol defined by IETF and 3GPP, and targeting resource constrained platforms JSR 184: Mobile 3D Graphics API for J2ME™ This specification defines a lightweight, interactive 3D graphics API, which sits alongside J2ME and MIDP as an optional package The API is targeted at devices that typically have very little processing power and memory, and no hardware support for 3D graphics or floating point math However, the API also scales up to higher-end devices that have a color display, a DSP, a floating point unit, or even specialized 3D graphics hardware The API is designed to make rapid development of compelling 3D applications feasible and is intended to be flexible enough for a wide range of applications, including games, animated messages, screen savers, custom user interfaces, product visualization, and so on JSR 190: Event Tracking API for J2ME™ This specification defines an optional package that standardizes the tracking of application events in a mobile device and the submission of these event records to an event-tracking server via a standard protocol The events can be used for purposes such as billing, usage tracking, application revocation, update notification, reviews and ratings, and so on The Event Tracking API is intended to work with devices supporting CLDC 1.0 and later The API is designed as an optional package that can be used with many J2ME profiles, in particular MIDP 1.0 and MIDP 2.0 For More Information For additional information on each effort mentioned above, refer to corresponding pages on the Java Community Process web site (http://jcp.org) Chapter 19 MIDlet Deployment Deploying MIDlets involves more than simply writing Java code using the CLDC and MIDP APIs To transfer the MIDlet to a wireless device, it has to be packaged with the resources it requires, configured for the locale in which it will be used, and placed on a server that supports the over-the-air (OTA) protocol specification so that it can be downloaded by mobile devices The first thing to understand is the concept of a MIDlet suite Chapter 3 Goals, Requirements, and Scope The CLDC and MIDP standards intend to bring the benefits of Java technology to resource-constrained wireless devices with limited Internet connectivity This chapter reviews the goals, requirements, and scope of these standards 15.8 CommConnection The CommConnection interface defines an API for a logical serial port connection The CommConnection extends the StreamConnection interface, through which bytes are transferred using input and output streams The underlying operating system defines the logical serial ports that can be used Such a port does not need to correspond to a physical RS-232 serial port For instance, IrDA IRCOMM ports are commonly configured as logical serial ports within the device An application opens a serial port by calling the Connector.open method The application must provide a URI string that begins with "comm:" followed by a port identifier, followed optionally by a semicolon and a semicolon-separated list of parameter-value pairs The name of a parameter is separated from its value with an equals sign (=) Spaces are not allowed in the string For example, "comm:COM0;baudrate=19200" is a valid string The port identifier is a logical device name defined by the device Port identifiers will probably be device-specific, so applications should use them with care (See Section 15.8.3, "Recommended Convention for Naming Ports.") Applications can get a comma-separated list of valid port identifiers for a particular device and operating system by calling the System.getProperty method with the key microedition.commports Any additional parameters must be separated by a semicolon If a particular optional parameter is not applicable to a particular port, the device is permitted to ignore it Legal parameters are listed in Table 15.3 If the application supplies an illegal or unrecognized parameter, the Connector.open method throws an IllegalArgumentException If the device supports a parameter value, it must be honored If the device does not support a parameter value, the Connector.open method throws a java.io.IOException If an option duplicates a previous option, the last value overrides the previous value Table 15.3 CommConnection parameters for opening serial connections Parameter baudrate Default Description platform Speed of the port in bits per second (such as 9600 or 19200) dependent bitsperchar Number of bits per character (7 or 8) stopbits Number of stop bits per char (1 or 2) parity none Parity (even, odd, or none) blocking on Whether to wait for a full buffer (on, which means wait, or off, which means do not wait) autocts on Whether to wait for the CTS line to be on before writing (on, which means wait, or off, which means do not wait) autorts on Whether to turn on the RTS line when the input buffer is not full (on, which means turn on the RTS line when the input buffer is not full, or off, which means the RTS line is always on) Only one application may be connected to a particular serial port at a given time The Connector.open method throws a java.io.IOException if an application tries to open the serial port when the connection is already open 15.8.1 Getting and Setting the Serial Port Speed The application may need to know or set the baud rate (speed) of the serial port to communicate with an external device There are two ways to set the baud rate The application can set it in the Connector.open method by putting the optional parameter baudrate into the method's URI string argument The application can also set the baud rate after the connection is open with the setBaudRate method If the application does not set a value, the baud rate defaults to a device-specific default value If the application requests a baud rate that the device does not support, the system may substitute a valid baud rate The application determines the actual baud rate of the connection by calling the getBaudRate method 15.8.2 Security for CommConnection Access to serial ports is restricted to prevent unauthorized transmission or reception of data MIDlet suites needing to use serial ports must request the javax.microedition.io.Connector.comm permission for Trusted MIDlet suites as described in Section 18.3, "Trusted MIDlet Suite Security Model." The device may try to authorize the MIDlet when the MIDlet calls the Connector.open method with a valid serial port connection string If the authorization fails and the MIDlet is not allowed to use the serial port connection API, the Connector.open method throws a java.lang.SecurityException The device might also check the MIDlet's permission when the MIDlet calls the methods openInputStream, openDataInputStream, openOutputStream, or openDataOutputStream methods 15.8.3 Recommended Convention for Naming Ports A logical port name can use any combination of alphanumeric characters except a semicolon Although logical port names can be defined to match a platform's naming conventions, implementations of the virtual machine should use the following convention: port names should contain a text abbreviation indicating port capabilities followed by a sequential number for the port The following device name types should be used: COM#: where COM is for RS-232 ports and # is a number assigned to the port IR#: where IR is for IrDA IRCOMM ports and # is a number assigned to the port This naming scheme allows the API users to generally determine the type of port that they would like to use For instance, if an application wants to beam a piece of data, the application could look for IR# ports for opening the connection The alternative is a trial-and-error approach with all available ports 15.8.4 Examples This section provides two examples of serial port access using the CommConnection interface The first example shows how a CommConnection would be used to access a simple program that echoes the characters it receives The second example shows how to discover the serial ports available on the device and select the first available serial port The following example shows a program that echoes characters through a CommConnection // Open the CommConnection and its streams CommConnection cc = (CommConnection)Connector.open("comm:com0;baudrate=19200"); int baudrate = cc.getBaudRate(); InputStream is = cc.openInputStream(); OutputStream os = cc.openOutputStream(); // Write characters and read them back in int ch = 0; while (ch != 'Z') { os.write(ch); ch = is.read(); ch++; } // Close the connection and its streams is.close(); os.close(); cc.close(); The following example shows how to discover the available serial ports on the device and select the first available serial port // Get the comma-separated list of ports String port1; String ports = System.getProperty("microedition.commports"); int comma = ports.indexOf(','); if (comma > 0) { // Parse the first port from the available ports list port1 = ports.substring(0, comma); } else { // Only one serial port available port1 = ports; } ... [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] J2ME [See Java 2 Micro Edition] Japanese language Java 2 Micro Edition architecture chapter Java 2 Micro Edition: configuration configuration Java 2 Micro Edition: optional package... class:preloading preverifier 2nd profile Java 2 Micro Edition: profile 2nd profile:definition Java 2 Micro Edition: profile:definition profile:MIDP Java 2 Micro Edition: profile:MIDP progress animation... optional package Java 2 Micro Edition: profile profile Java Application Manager JAM: [See Java Application Manager] Java Archive files JAR: [See Java Archive files] Java Community Process JCP: [See Java Community Process]