Technical Manual Motorola C370, C450, and C550 Series of Handsets J2ME Developer Guide

Version 1.1

Table of Contents
TABLE OF CONTENTS.... INTRODUCTION.... 5 PURPOSE..... 5 AUDIENCE..... 5 DISCLAIMER.... 5 REFERENCES.... 6 REVISION HISTORY.... 7 DEFINITIONS, ABBREVIATIONS, ACRONYMS... 7 DOCUMENT OVERVIEW..... J2ME INTRODUCTION.... 10 THE JAVA 2 PLATFORM, MICRO EDITION (J2ME)... 10 THE MOTOROLA J2ME PLATFORM.... 11 RESOURCES AVAILABLE..... DEVELOPING AND PACKAGING J2ME APPLICATIONS... 13 GUIDE

DEVELOPMENT

J2ME.... 13
4 DOWNLOADING APPLICATIONS.... 15 OTA PROCEDURE..... 15 INSTALLATION..... 15 STARTING APPLICATIONS.... 17 EXITING APPLICATIONS..... 17 LAUNCHING WEB SESSION FOR HTTP DOWNLOAD... 18 DOWNLOADING MIDLETS.... 18 ERROR CHECKS..... 18 XML SCREEN RENDERINGS.... APPLICATION MANAGEMENT.... 22 MIDLET LIFECYCLE.... 22 MIDLET SUITE INSTALLATION.... 23 MIDLET SUITE DE-INSTALLATION.... 24 MIDLET SUITE UPDATING.... 25 STARTING, PAUSING, AND EXITING: AMS CONTROL OF MIDLET STATE TRANSITIONS. 25 MIDlet Control of MIDlet State Transitions... 29 JAVA SYSTEM..... NETWORK API..... 31 NETWORK CONNECTIONS..... 31 CLASS DESCRIPTIONS.... 32
HTTP..... 33 TCP SOCKETS.... 34 UDP SOCKETS.... 34 SERIAL PORT ACCESS.... 34 Communicating on a Port... 36 Example using StreamConnection... 36 IMPLEMENTATION NOTES..... 37 NOTES..... LCDUI...... 39 LCDUI API..... GAMING API AND SOUND..... 41 FUNCTIONAL DESCRIPTION.... 41 CLASS HIERARCHY.... 41 BACKGROUNDMUSIC CLASS.... 42 BackgroundMusic Methods... 42 Using BackgroundMusic... 42 GAMESCREEN CLASS..... 43 GameScreen Fields.... 43 GameScreen Methods.... 44 Using GameScreen.... 46 IMAGEUTIL CLASS.... 47 ImageUtil Fields.... 47 ImageUtil Methods.... 47 Using ImageUtil.... 48 PALLETEIMAGE CLASS.... 49 PalleteImage Constructor.... 49 PalleteImage Methods.... 49 Using PalleteImage.... 50 PLAYFIELD CLASS.... 51 Using Static and Animated Tiles... 51 Using Sprites.... 52 Defining View Windows... 52 PlayField Constructor... 52 PlayField Methods.... 54 Using PlayField.... 57 SOUNDEFFECT CLASS..... 58 SoundEffect Methods..... 58 Using SoundEffect.... 58 SPRITE CLASS..... 58 Animation Frames.... 59 Sprite Drawing..... 59 Sprite Constructor.... 59 Sprite Methods..... 60 Using Sprite.... 63 FILEFORMATNOTSUPPORTEDEXCEPTION.... 63 FileFormatNotSupportedException Constructors... 64 JAVA GAMING SOUND API.... 64 MAX MIDI EXTENSION SUPPORT.... VIBE AND BACKLIGHT..... 65

BACKLIGHT API..... 65

10 SMS MO.... 66 OVERVIEW..... 66 CREATING A MESSAGE.... 66 SENDING A MESSAGE..... 67 PERMISSIONS..... JAD ATTRIBUTES..... 68 JAD ATTRIBUTES..... RECORD MANAGEMENT SYSTEM.... 70 OVERVIEW..... 70 CLASS DESCRIPTION..... 70 CODE EXAMPLES..... 70 TIPS...... 71 CAVEATS..... PHONEBOOK ACCESS.... 72 PHONEBOOK ACCESS API.... 72 PHONEBOOK ACCESS API PERMISSIONS... ITAP...... 81 INTELLIGENT KEYPAD TEXT ENTRY API... 81 APPENDIX A: KEY MAPPING.... 82 KEY MAPPING

FOR THE

C370, C450,

C550... 82

APPENDIX B: MEMORY MANAGEMENT CALCULATION... 84 AVAILABLE MEMORY..... 84 APPENDIX C: FAQ..... 85 ONLINE FAQ..... 85 APPENDIX D: SPEC SHEETS.... 86 C370, C450,

C550 SPEC SHEETS... 86

1 Introduction

Purpose

This document describes the application program interfaces used to develop Motorola compliant Java 2 Platform, Micro Edition (J2ME) applications for the Motorola C370, C450, and C550 series of handsets.

Audience

This document is intended for developers involved with the development of J2ME applications for the C370, C450, and C550 series of handsets.

Disclaimer

Motorola reserves the right to make changes without notice to any products or services described herein. Typical parameters, which may be provided in Motorola Data sheets and/or specifications can and do vary in different applications and actual performance may vary. Customers technical experts will validate all Typicals for each customer application. Motorola makes no warranty with regard to the products or services contained herein. Implied warranties, including without limitation, the implied warranties of merchantability and fitness for a particular purpose, are given only if specifically required by applicable law. Otherwise, they are specifically excluded. No warranty is made as to coverage, availability, or grade of service provided by the products or services, whether through a service provider or otherwise. No warranty is made that the software will meet your requirements or will work in combination with any hardware or applications software products provided by third parties, that the operation of the software products will be uninterrupted or error free, or that all defects in the software products will be corrected.

Note: This image reflects a 176 x 220 display for document readability purposes only. The C370, C450, and C550 maintain a 96 x 64 display.
MIDlet Suite Installation
Installation of MIDlet suites can occur from the Java Settings menu or the Browser. A MIDlet Suite must be installed before any of its MIDlets can be executed. Installation involves extracting the classes from the JAR file and creating an image that will be placed into Program Space. The resources are then extracted from the JAR file and placed into Data Space. The JAR file is then removed from the device, thus freeing up some Data Space where it was originally downloaded. The space savings from removing the JAR file is one advantage of installation, but perhaps an even greater advantage is that class loading is not done during run time. This means that a MIDlet will not experience slow-down when a new class is accessed. Even further, the MIDlet will not have to share the heap with what has been loaded from the JAR file. The figure below shows the Java Settings screen.
Note: This image reflects a 176 x 220 display for document readability purposes only. The C370, C450, and C550 maintain a 96 x 64 display. Additionally, the items that may appear on the actual device may differ from those displayed in the image above
MIDlet Suite De-installation
An installed MIDlet can only be removed from the device by de-installing it from the Java Apps menu. De-installing a MIDlet Suite will remove the installed image from Program Space. The resources are then removed from Data Space along with the JAD file. From the Games & Apps menu, the user can highlight a MIDlet Suite, selecting the menu soft key, and bring up the Delete dialog for that MIDlet Suite.
Note: These images reflect 176 x 220 displays for document readability purposes only. The C370, C450, and C550 maintain a 96 x 64 display.

MIDlet Suite Updating

When a MIDlet Suite is de-installed, all of its resources are removed including any resources that were created by the MIDlets in the suite, such as RMS databases. If a user gets a new version of a MIDlet Suite, then the user can simply download that new version to the device that has the older version installed. Once the new version is downloaded, the user will have the option to update the MIDlet Suite, causing the old version to be deinstalled, followed by the immediate installation of the new MIDlet Suite. A newer version of the MIDlet Suite should know how to use, upgrade, or remove the data in the RMS databases created by older versions. This idea of forward compatibility should not be extended to backward compatibility, because the C370, C450, and C550 device will not allow a user to update a version of a MIDlet Suite with an older or equal version of that MIDlet Suite. If an older or equal version attempts to be installed, the C370, C450, and C550 will ignore the installation and launch the current version of the MIDlet suite.

Starting, Pausing, and Exiting: AMS Control of MIDlet State Transitions
A MIDlet has three different states: Destroyed, Active, and Paused. A MIDlets natural state is destroyed. The AMS typically controls the transition through these states. When a user decides to launch a MIDlet, the device puts up a screen indicating that the MIDlet is transitioning through these states. The AMS notifies MIDlets about state transitions by calling the MIDlets methods, startApp(), pauseApp(), and destroyApp(). The figure below shows the MIDlet starting screen.
The constructor of the MIDlets class that extends MIDlet is first invoked. Then its startApp() method is called to indicate that its being started. The MIDlet will have focus when its startApp() method finishes execution. If a MIDlet takes too long
initializing state variables and preparing to be run in its constructor or startApp() methods, it may appear to be stalled to users. The flow below depicts MIDlet State Transitions.

Starting Application

Constructor
startApp() Running Application pauseApp() Paused Application
destroyApp() notifyDestroyed() Exit Application
The following table shows MIDlet State Transition methods. Method Constructor startApp() Caller AMS AMS Purpose Initializes the MIDlet should return quickly The startApp() method is called to start the application either from a newly constructed state or from a paused state. If the startApp() is called from a paused state, the MIDlet should not re-initialize the instance variables(unless it is the desired behavior). The startApp() method may be called multiple times during the lifespan of the MIDlet. The MIDlet may set the current display to its own Displayable from the startApp() method, but is shown only after the startApp() returns. When exiting a paused application, the KVM calls startApp() first followed by a call to destroyApp()

pauseApp()

AMS, MIDlet
The pauseApp() method is called from either AMS or from within the MIDlet. The pauseApp() should pause active threads, and prepare for startApp() to be called. If the application is to be resumed with a screen other than the present, then the Displayable should be set current in the startApp() or the pauseApp().

destroyApp()

The destroyApp() method is called from AMS and signals the MIDlet to clean up any resources to prepare for termination. For example, open RMS records should be closed, threads should be stopped, and any other housekeeping chores should be performed. The MIDlet should not call destroyApp(). The notifyDestroyed() method is called by the MIDlet to exit and terminate itself. All housekeeping such as stopping active threads and closing RMS records should be performed before calling notifyDestroyed(). notifyDestroyed() notifies AMS to terminate the calling MIDlet.

6 Network API

Network Connections
The J2ME platform on the Motorola C370, C450, and C550 series of handsets provides a variety of networking functionalities beyond those specified in MIDP. The additional networking protocols are added through the Generic Connection Interface in order to simplify the interface to the application as well as to reduce the need for additional classes. Most of the additional network connections are invoked using a runtime parameter similar to HTTP, reducing the learning curve for developers as well as the reducing potential application porting efforts. The following is a list of networking features for the Motorola C370, C450, and C550 series of handsets: HTTP TCP Sockets UDP Sockets Serial Port Access
The standard networking protocol specified in MIDP 1.0 is HTTP. Although HTTP is useful and flexible for most data exchanges, many of the applications fall outside the standard request/response models of most browsers. Applications such as games and stock tickers require networking protocols with different characteristics. In order to accommodate these types of applications with reasonable efficiency, additional protocol stacks including UDP and TCP Sockets, have been added. These added networking functionalities not only provide the application developer with more communication options, it alleviates the need to perform inefficient workarounds for a strict HTTP environment. Other applications may also choose to take advantage of the bottom connector on the devices. The bottom connector is a serial port enabling communication with a variety of other devices. The Motorola C370, C450, and C550 series of handsets also provides serial port access through the Generic Connection Framework in order to provide applications a means to communicate to external devices such as GPS, OBD, PCs, etc.

Class Descriptions

<<Interface>> StreamConnectionNotifier <<Interface>> DatagramConnection

<<Interface>> Connection
<<Interface>> InputConnection
<<Interface>> OutputConnection
<<Interface>> StreamConnection
<<Interface>> Content Connection
<<Interface>> HttpConnection
Since all the additional communication protocols have been added to the Generic Connection Framework, the access methods and parameters are very similar. The main calls are to the Connector class, which provides three static methods that accept different compile time parameters. The commonality between the three static methods is the first parameter in their signatures. This particular runtime parameter accepts Strings formatted in the standard Uniform Resource Locator format. The following is the list of method signatures:
Connector.open(String URL) - default READ_WRITE, no timeout. Connector.open(String URL, int mode) - defaults to no timeout. Connector.open(String URL, int mode, Boolean timeout) - String URL parameter string describing the target conforms to the URL format
as described in RFC 2396 for all networking protocols except for Serial Port.
- int mode READ/WRITE/READ_WRITE

- boolean timeout

An optional third parameter, protocol may throw an IOException when it detects a time-out condition.
The time-out period for the TCP implementation on the Motorola C370, C450, and C550 series of handsets is 20 seconds on read operation and about 45 seconds on write operation if the time-out flag is set to true. If the time-out flag is set to false, the time-out time is indefinite. The lingering time for closing sockets is 0 second (if the socket closed by the server the lingering time will be less than 100 ms). If a new socket is requested within this time frame and the maximum number of sockets opened has been reached (5 sockets), then an IOException is thrown. Applications requesting a network resource for any protocol must use one of the three methods above. The URL is the distinguishing argument that determines the difference between HTTP, Serial, etc. The following chart details the prefixes that should be used for the supported protocols.
Protocol HTTP TCP Sockets UDP Sockets Serial Port
URL Format http:// socket:// datagram:// comm:<Port_Name>; <Port_Name> - should be derived from the return string of System.get Property("serialport.name").
The HTTP implementation follows the MIDP 1.0 standard. The Connector.open() methods return a HttpConnection object that is then used to open streams for reading and writing. The following is a code example to show implementation of HTTP:

StreamConnection sc = (StreamConnection)Connector.open( comm: + port_name + ;baudrate= + baudrate + ;parity=n;databits=8;stopbits=1;flowcontrol=n/n);
Although serial port access is integrated into the Generic Connection Framework, the URL parameters passed in deviates from the other networking protocols. The optional parameters, such as baud rate, parity, etc are appended to the base parameter of comm:0. Optional parameters are listed below along with the default values when not explicitly specified: Parameter baudrate Syntax

baudrate = x

Options
[300, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200] [8,7] 1, 1,5 and 2 [n,o,e,s,m] n=none, o=odd, e=even, s=space, m=mark [n, s, h] / [n, s, h] n=none, s=software,h=hardware on or off on or off x on or off

Default

192000
databits stopbits parity with mapping Flow control
databits = x stopbits = x parity = x
flowcontrol = outflow/inflow autocts= autorts= x x

autocts autorts blocking

off off off

blocking =

Note - The following combinations of properties are not supported. 7 databits with none parity 8 databits with mark parity 8 databits with space parity 8 databits with odd parity 8 databits with even parity
IOException will be thrown while trying to use any of the unsupported combinations in Connector.open(). All properties must be semicolon separated. If not all properties are passed; the remaining properties will be taken as default values. The order of properties in the argument does not matter.
name = "comm:0;baudrate=38400;"
Here, the flow control, parity, data bits and stop bits will use the default values. For mode and timeout refer to the CLDC API specification for the Connector class.

Communicating on a Port

The open method of the Connector class returns a StreamConnection object for the serial port. StreamConnection has methods for obtaining input and output streams from a port. The base interface, Connection, has a method to close the port. (Refer to the class hierarchy from StreamConnection from J2ME CLDC API specification). There are five basic steps to communicating with a port:
Open the port using the open() method of Connector. If the port is available, this returns a StreamConnection object for Comm port. Otherwise, an IOException is thrown. Get the output stream using the openOutputStream() method of OutputConnection. Get the input stream using the openInputStream() method of InputConnection. Read and write data onto those streams. Close the port using the close() method of both the Connection and open Streams.

Once the connection has been established, simply use the normal methods of any input or output stream to read and write data. The openInputStream and openOutputStream methods of StreamConnection are similar to the methods of the socket StreamConnection.
Example using StreamConnection
Connector.open is used to open the serial port and a StreamConnection is returned. From the StreamConnection the InputStream and OutputStream are opened. It is used to read and write every character until the connection is closed(-1). If an exception is thrown the connection and stream are closed.
StreamConnection sc = null; InputStream is = null; OutputStream os = null; /* * Create the parameter String with options specified */ String parameter = "comm:0;baudrate=19200;parity=n;databits=8;stopbits=1; flowcontrol=n/n; try{ sc = (StreamConnection)Connector.open(parameter, Connector.READ_WRITE, false);
os = sc.openOutputStream(); is = sc.openInputStream(); int ch; while ((ch = is.read() ) != -1) { os.write(ch); } } finally { if (sc != null) sc.close(); if(is != null) is.close(); if(os != null) os.close(); }

Implementation Notes

As stated in the previous sections, the Motorola C370, C450, and C550 series of handsets supports some networking options. The networking options however are limited by both memory and bandwidth, which place hard restrictions on the applications. These limitations manifest themselves mainly in the number of simultaneous connections that can be opened. Maximum number of sockets is 5 of any combinations of HTTP and UDP. Due to memory constraints, the C370, C450, and C550 can support only one secure session (i.e. if other application like Browser already opened a secure socket, a KJava midlet will get an IOException when it tries to open only one connection which is HTTP connection). If the maximum number of sockets is concurrently opened by the application and a sixth socket is requested, an exception is thrown to the calling application.
It is important to take into consideration the blocking nature of many javax.microedition.io and java.io object methods with regards to networking applications. It is advisable to spawn another thread specifically dedicated to retrieving data in order to keep the user interface interactive. If a single thread is used to retrieve data on a blocking call, the user interface becomes inactive with the end-user perceiving the application as dead. Reading from an InputStream using an array is faster then reading byte by byte, when the length of the data is known. For example, if the content length is provided in the header of the HttpConnection, then an array of the specified size can be used to read the data.

Gauge Graphics Image ImageItem Item List Screen Spacer StringItem TextBox TextField Ticker

8 Gaming API and Sound

Functional Description
The Gaming API provides gaming related functionality to J2ME MIDlet writers. This functionality includes the ability and support for transparent images, the ability to play simple sounds and sound effects during a game, the ability to detect simultaneous key presses, support for sprites, and support for dynamically changing the palette color associated with an image.

Class Hierarchy

The following diagram shows the Gaming API hierarchy.

javax.microedition.lcdui

Graphics
(from javax.microedition.lcdui)

com.motorola.game

GameScreen SoundEffect

Canvas

ImageUtil

BackGroundMusic

PaletteImage Image
FileFormatNotSupported Exception

PlayField

Sprite

BackgroundMusic Class

The BackgroundMusic class encapsulates the data for a game's background music. A game may create several BackgroundMusic objects, but only one can be playing at any one time. The sound data can be stored on the device as a named resource in the application JAR file, or it can be stored on a server and retrieved via the network. BackgroundMusic is played by a GameScreen.

BackgroundMusic Methods

The BackgroundMusic class defines the following methods:
public static BackgroundMusic createBackgroundMusic(java.lang.String name) throws
FileFormatNotSupportedException Creates a BackgroundMusic for the sound data stored in the specified named resource or URL. This method currently supports the use of MIDI format 0 and format 1 only.

Using BackgroundMusic

The following code sample shows implementation of BackgroundMusic:
Using BackgroundMusic BackgroundMusic bgm1 = BackgroundMusic.createBackgroundMusic("/FunkyTunes.mid"); BackgroundMusic bgm2 = BackgroundMusic.createBackgroundMusic("http://www.motorola.com/sounds/Ja zzyTunes.mid");
The following code sample shows implementation of the Gaming API that contains a sound API: Gaming API containing a sound API
import com.motorola.game.*; public class GS extends GameScreen { public BackgroundMusic bgm; public GS() { bgm = BackgroundMusic.createBackgroundMusic("vinovata.mid"); playBackgroundMusic(bgm, true); } }

24-bit color format (0xRRGGBB). The method parameters are the following: dest The mutable destination Image whose pixels will be set; x - The horizontal location of left edge of the region; y - The vertical location of the top edge of the region; width - The width of the region; height - The height of the region; and rgbData - The array of RGB pixel values. public static void setPixels(javax.microedition.lcdui.Image dest, int[] rgbData) throws ArrayIndexOutOfBoundsException, IllegalArgumentException Sets RGB pixel data in the entirety of the destination image. The data must be stored in the int array in row-major order using the standard 24-bit color format (0xRRGGBB). The method parameters are dest - The mutable destination Image whose pixels will be set, and rgbData - The array of RGB pixel values. public static Image getScaleImage(javax.microedition.lcdui.Image src, int width, int height, int method) throws IllegalArgumentException Creates a scaled version of the source image using the desired scaling method. All platforms must implement the SCALE_REPLICATE scaling method; other scaling methods may be optionally supported. SCALE_REPLICATE is used if the requested scaling method is not supported by the device. The method parameters are the following: src - the source Image; width - the width, in pixels, of the new Image, height - the height, in pixels, of the new Image, and method - The desired method to be used to scale the image data (see the item 0).

Using ImageUtil

The following code sample uses an image (tank.png) to create a data structure (rgbData) to stores the RGB pixel data. The rgbData is used to draw the same image. The following is a code sample to show implementation of rgbData: rgbData
try { Image tank = Image.createImage("tank.png"); } catch(Exception e) { // The image can't be loaded } // creates a data structure to stores the RGB pixel data from Image int rgbData[] = new int[tank.getHeight()*tank.getWidth()]; // Stores the RGB pixel data from Image ImageUtil.getPixels(tank,rgbData); // Draws the image pixel by pixel with the respective RGB pixel data for (i=0;i<tank.getHeight();i++) { for (j=0;j<tank.getWidth();j++) { g.setColor(rgbData[i*tank.getWidth() + j]); g.fillRect(j,i,1,1);

PalleteImage Class

PaletteImage provides methods for manipulating the color palette data of an image. PaletteImages can only be created with palette-based image data (PNG color type 3,
or other palette image formats that a particular device may support).

Using Static and Animated Tiles
Static tiles are called static because their image does not often change, i.e., any cell that contains the static Tile 1 will always be drawn as the unchanging image of Tile 1. Tile 0 is a special static tile. It represents an empty cell. Any cell containing tile 0 will be transparent, it will not have a tile image drawn in it. Animated tiles are called animated because their appearance changes easily over time. At any given time, each animated tile is associated with a particular static tile. When a cell containing an animated tile is drawn, the image of the static tile currently referenced by that animated tile will be drawn in that cell. In effect, the animated tiles provide indirect references to the set of static tiles, and therefore allow many cells to be animated simultaneously. For example, cells (0,0) and (0,1) both contain animated Tile -2. Animated Tile -2 currently references static Tile 1. Cells (0,0) and (0,1) will then be drawn with the image of static Tile 1. If animated Tile -2 is subsequently set to reference static Tile 2 by
calling setAnimatedTileImage(-2, 2);, cells (0,0) and (0,1) will then be drawn with the image of static Tile 2.

Using Sprites

In addition to being a grid of cells, a Playfield can have a set of associated Sprites (see 0 item). When the PlayField is drawn, the grid is considered to have depth 0. Therefore, Sprites below the grid (Sprites with Sprite.getDepth() < 0) are drawn first. Then all cells in the grid are drawn. Then all the Sprites above the grid (Sprite.getDepth() >= 0) are drawn. The Sprites are drawn according to their location and visibility status as defined in the Sprite class. The location of Sprites is relative to the top-left corner of the PlayField.

Defining View Windows

A view window onto the PlayField can be defined using the method setViewWindow(). This defines the area of the PlayField that will be drawn by the draw() method. The default viewing window onto a PlayField (at construction time) is the entire area of the PlayField.

PlayField Constructor

The PlayField class defines the following constructors: PlayField (int columns, int rows, Image img, int tWidth, int tHeight) throws NullPointerException, IllegalArgumentException - Creates a new PlayField with a tile set. The parameter are the following: columns - width of the PlayField in number of cells;
rows - height of the PlayField in number of cells; img - Image to use for creating tiles; tWidth - width, in pixels, of the individual tiles; tHeight - height, in pixels, of the individual tiles.
It creates a new PlayField, rows cells high and columns cells wide. The static tile set for the PlayField will be created from subsections of the image passed in. The PlayField grid is initially filled with empty cells (tile 0 - a reserved tile and represents an empty square) and laying out tiles must be accomplished through the use of other methods in the class. The creation of the static tile set follows these standards: Tiles must be equally sized, all being of the tile width (tWidth) and height (tHeight) defined in the constructor parameters. They may be laid out in the image horizontally, vertically, or as a grid. The width of the source image must be an integer

The creation of the raw frames follows these standards: Frames must be equally sized, all being of the frame width (fWidth) and height (fHeight) defined in the constructor parameters. They may be laid out in the image horizontally, vertically, or as a grid. The width of the source image must be an integer multiple of the frame width. The height of the source image must be an integer multiple of the frame height. The frames are numbered like words are read on a page; left-to-right, then topto-bottom. The top-left frame is numbered 0. If there is a frame to its right, this frame is numbered 1, and so on, across the first row of frames. If there is a second row of frames, the number of the left-most frame in this row is one greater than the right-most frame in the preceding row. The table below is a diagrammatic depiction:
The frames in the source image will have raw frame numbers as follows:

0 N 2N. (M 1) * N

1 N + 1 2N + 1. ((M-1)* N ) + 1

N 1 2N 1

. (M * N ) 1
So the total number of frames is M * N, where: N = (image width) / (frame width) M = (image height) / (frame height)
At the time of creation, all Sprites have a default frame sequence corresponding to the raw frame numbers. This can be modified with setFrameSequence(). At construction time, the Sprite's position will be set to (0,0), the depth will be set to 0, and the Sprite will be visible. The Sprite shall behave as if the image used in creation were cached. If a mutable image is used to create the Sprite, the Sprite's appearance should not reflect changes to mutable source image. public Sprite(Sprite s) Creates a new Sprite from another Sprite. Create a copy of a Sprite. All attributes (raw frames, position, frame sequence, current frame, visibility) of the source Sprite should be reflected in the new Sprite. Any subsequent updates to the source Sprite after the creation of the second Sprite should not be reflected in the second Sprite.

Sprite Methods

The Sprite class implements the following methods: public void setPosition(int x, int y) Set Sprite's x,y position. The x, y position is relative to whatever object the sprite is associated with or drawn on.

int[] returnArray = PhoneBookRecord.getMailingListMembers(mlspeedNo); Sample of code for calling of isMailingListMember(int mlSpeedNo, int mbSpeedNo) method: boolean returnValue = false; int mlspeedNo = 3, mbspeedNo = 4; returnValue = PhoneBookRecord.isMailingListMember(mlspeedNo, mbspeedNo); Sample of code for calling of getNumberMailingListMembers(int speedNo) method: int numberMembers, mlspeedNo = 3; numberMembers = PhoneBookRecord.getNumberMailingListMembers(mlspeedNo); Sample of code for calling of addCategory(String name) method: String categoryName = CatName; int categoryId = PhoneBookRecord.addCategory(categoryName); Sample of code for calling of deleteCategory(int categoryId) method: PhoneBookRecord.deleteCategory(categoryId); Sample of code for calling of getCategoryName(int categoryId) method: String categoryName = PhoneBookRecord.getCategoryName(categoryId); Sample of code for calling of getCategoryMembers(int categoryId) method: int SpeedNumbersArray[] = null; SpeedNumbersArray = PhoneBookRecord.getCategoryMembers(categoryId); Sample of code for calling of getNumberCategoryMembers (int categoryId) method: int numberMembers = PhoneBookRecord.getNumberCategoryMembers(categoryId); Sample of code for calling of getNumberCategories() method: int numberCategories = PhoneBookRecord.getNumberCategories(); Sample of code for calling of getCategoryIdByIndex(int index) method: int index = 1; int categoryId = PhoneBookRecord.getCategoryIdByIndex(index); Sample of code for calling of getMaxCategoryNameLength() method: int maxCategoryNameLength = PhoneBookRecord.getMaxCategoryNameLength(); Sample of code for calling of getCurrentCategoryView() method: int categoryView = PhoneBookRecord.getCurrentCategoryView(); Sample of code for calling of setCategoryView() method:
int oldCategoryView = PhoneBookRecord.setCategoryView(categoryId); Sample of code to create object of RecentCallDialed class: String name = Name; String telNo = 9999999; int type = RecentCallRecord.VOICE; int attribute = RecentCallRecord.CALL_CONNECTED; long time = 10000; int duration = 3000; boolean show_id = true; RecentCallDialed dialedRecentCall = new RecentCallDialed(name, telNo, type, attribute, time, duration, show_id); Sample of code for calling of add() method: String name = Name; String telNo = 9999999; int type = RecentCallRecord.VOICE; int attribute = RecentCallRecord.CALL_CONNECTED; long time = 10000; int duration = 3000; boolean show_id = true; RecentCallDialed dialedRecord = new RecentCallDialed(name, telNo, type, attribute, time, duration, show_id); dialedRecord.add(); Sample of code for calling of delete(int index) method: int index = 1; RecentCallDialed.delete(1); Sample of code for calling of deleteAll() method: RecentCallDialed.deleteAll(); Sample of code for calling of getRecord(int index) method: int index = 1; dialedRecord.getRecord(1); Sample of code for calling of getUsedRecords() method: int usedRecs = RecentCallDialed.getUsedRecords(); Sample of code for calling of getNumberRecords() method: int numberRecs = RecentCallDialed.getNumberRecords(); Sample of code for calling of getMaxNameLength() method:

javax.microedition.lcdui.TextBox
The TextBox class is a Screen that allows the user to edit and enter text.
javax.microedition.lcdui.TextField
A TextField is an editable text component that will be placed into a Form. It is given a piece of text that is used as the initial value.

Appendix A: Key Mapping

Key Mapping for the C370, C450, and C550
The table below identifies key names and corresponding Java assignments. All other keys are not processed by Java. Key STAR (*) POUND (#) JOYSTICK LEFT JOYSTICK RIGHT JOYSTICK UP JOYSTICK DOWN SCROLL UP SCROLL DOWN SOFTKEY 1 SOFTKEY 2 MENU SEND Assignment NUM0 NUM1 NUM2 NUM3 NUM4 SELECT, followed by NUM5 NUM6 NUM7 NUM8 NUM9 ASTERISK POUND LEFT RIGHT UP DOWN UP DOWN SOFT1 SOFT2 SOFT3 (MENU) SELECT Also, handled according to VSCL specification: incoming call accepted, if Java has high priority Also, call placed if pressed on lcdui.TextField or lcdui.TextBox with PHONENUMBER constraint set.

CENTER SELECT END

SELECT Handled according to VSCL specification: Pause/End/Resume/Background menu invoked.
Appendix B: Memory Management Calculation

Available Memory

The available memory on the Motorola C370, C450, and C550 series of handsets is the following: 1M shared memory for MIDlet storage 512 Kb Heap size Recommended maximum MIDlet size is 100K

Appendix C: FAQ

Online FAQ
The MOTOCODER developer program is online and able to provide access to Frequently Asked Questions around enabling technologies on Motorola products. Access to dynamic content based on questions from the Motorola J2ME developer community is available at the URL listed below. http://www.motocoder.com

Appendix D: Spec Sheets

C370, C450, and C550 Spec Sheets
Listed below are the spec sheets for the Motorola C370, C450, and C550 handsets. The spec sheets contain information regarding the following areas: Technical Specifications Key Features J2ME Information Motorola Developer Information Tools Other Related Information

Motorola C370/C450

Developer Reference Sheet
Band Frequency Region Technology Connectivity Dimensions Weight Display Operating System Chipset GSM 900/1800 GPRS GSM 850/1900 GPRS Global WAP 2.0, J2ME, SMS, EMS, MMS, AOL/OICQ IM USB 99.5x44x20.g 96 x 65 Motorola i250S1