September 2003

Adapting your MIDlets to the

Sony Ericsson T610/T616/T618
and Z600

Sony Ericsson T610/T616/T618 Sony Ericsson Z600

1
Contents

Contents ......................................................................................................................................................2
1. Introduction.......................................................................................................................................3
2. The Sony Ericsson T610/T616/T618 & Z600.............................................................................4
2.1. The Mobile Information Device Profile 1.0................................................................................5
2.2. The Mobile Media API.....................................................................................................................6
3. Adapting Your MIDlets ...................................................................................................................8
3.1. General Considerations.................................................................................................................8
3.2. Managing Sound in the T610/T616/T618 and Z600.................................................................8
3.2.1. Reducing Playback Latency .............................................................................................................................................10
3.2.2. Using Multi ple Players ........................................................................................................................................................10

3.3. Managing The Vibrator, LEDs and Backlight........................................................................ 13

3.4. Managing the User Interface in the T610/T616/T618 and Z600 ........................................ 14
3.5. Moving Your Nokia Series 40 MIDlet to the T610/T616/T618 and Z600.......................... 14
3.5.1. Adapting The Nokia Series 40 Sound API...................................................................................................................14
3.5.2. Adapting The Nokia Series 40 UI API...........................................................................................................................16

4. Conclusion..................................................................................................................................... 18
5. Appendix 1 - Map of Nokia Frequencies to MIDI Note Numbers..................................... 19
6. Appendix 2 - Resources............................................................................................................. 22
7. Appendix 3- T610 Firmware Update ........................................................................................ 23
7.1. Availability of firmware upgade for the T610 phone ........................................................... 23

2
 1. Introduction

Sony Ericsson sells the high-end T610/T616/T618, a series of advanced wireless mobile phones with complete imaging
and messaging capabilities, including the T610 and T616 for the American market and T618 for the Chinese market. The
T610 series of phones has a large color LCD display, built-in camera, and multimedia messaging services. Sony Ericsson
has recently introduced the Z600, which offers similar capabilities as the T610/T616/T618.
This paper discusses the T610/T616/T618 and Z600 phones and how to adapt your existing MIDlets to them, with special
focus on adapting existing Nokia Series 40 MIDlets.
This article assumes that you are familiar with the J2ME Mobile Information Device Profile (MIDP) 1.0, and the Liquid
Crystal Display User Interface (LCDUI) API, which is part of the MIDP 1.0 specification.
For your convenience, below is a list of acronyms that are used in this document:

AMR - Adaptive Multi -Rate

J2ME Java 2 Micro Edition, Platform

JSR Java Specification Request

LCDUI Liquid Crystal Display User Interface, the least common denominator type o f user interface targeted by
MIDP

MMAPI Mobile Media API

MIDP Mobile Information Device Profile

MIDlet A MIDP application

MIDI - Musical Instrument Digital Interface

3
 2. The Sony Ericsson T610/T616/T618 & Z600

The Sony Ericsson T610/T616/T618 is series o f high-end devices. It supports the MIDP 1.0. Figure 1 shows the
T610/T616/T618.

Figure 1 The Sony Ericsson T610/T616/T618

Note that there is a new firmware release available for T610 that improves Java performance. See Appendix 3 for more
details.

The Sony Ericsson Z600 supports similar features as the T610/T616/T618 --such as the 65536-color display, network
connectivity, and integral camera--all packaged in an attractive clamshell design. Figure 2 shows the Z600 device.

Figure 2 The Sony Ericsson Z600

Table 1 summarizes the characteristics of the T610/T616/T618 and the Z600.

4
Table 1 T610/T616/T618 and Z600 Specifications

128 x 160 (W x H), Canvas Size 128 x 127,

Screen Size
Pixel Ratio of 1 : 1.1 (H:W)

Colors 65,536 (16 bits per pixel)

Maximum Record Management System (RMS) size 30 KB per suite

Maximum Memory for Storage Up to 500 KB

Java heap memory 256 KB

CLDC version 1.0

MIDP version 1.0

Support for HTTP Yes

On Device Debugging Yes (Supports the KVM Debug Wire Protocol)

Support for Over The Air Recommendation Proposal v 1.0 Yes

Numeric keys Yes, 0-9 * #

4 way directional key with select Yes, Joystick

8 way directional key with select (Z600 only) Yes

Other function keys No

Subset supporting audio playback. See Table

Mobile Media API (JSR 135)
3.

Wireless Messaging API (JSR-120) (T616 only) Yes

* Note: The T610/T616/T618 and Z600 phones have infrared, Bluetooth, and serial connectivity, but these are not
currently supported from Java .
In addition to the core MIDP APIs, these handsets support a subset of the standard Mobile Media API, as defined by the
Java Community Process JSR-135. This subset supports audio playback. You control synthesizers that use data sources
such as MIDI, iMelody, and stored tone sequences to play back sounds or music.
The T616 for the North American market also supports the Wireless Messaging API JSR-120.

2.1. The Mobile Information Device Profile 1.0

As summarized in Table 2, you have access to all MIDP 1.0 APIs for networking, user interface, persistence, and MIDlet
lifecycle. There are no vendor-specific APIs.

5
Table 2 Summary of MIDP 1.0 API

Package name Description

java.io MIDP subset of system input and output through data streams.

java.lang MIDP subset of the core Java programming language.

java.util A small subset of utility classes.

javax.microedition.io Networking support using the Generic Connection Framework.

javax.microedition.lcdui MIDP user interface classes.

The application (MIDlet) interface, its life-cycle classes and its interactions with
javax.microedition.midlet
the runtime environment, and the application manager.

javax.microedition.rms Persistence classes for storage and retrieval of data.

Covering the MIDP 1.0 APIs in detail is outside the scope of this article. For more information on MIDP, please refer to
the MIDP documentation that can be downloaded from Sun Microsystems MIDP page.

2.2. The Mobile Media API

The T610/T616/T618 and Z600 also support a subset of the Mobile Media API (MMAPI), as defined by the Java
Community Process JSR-135. This is a Java standard API for J2ME that provides a generic foundation for simple and
fine-grained multimedia processing for devices with sound and multimedia capabilities. The MMAPI is summarized in
Table 3.
Table 3 Mobile Media API v 1.0 Java Packages

Package Name Description

Defines the interfaces for controlling (Control) and rendering

javax.microedition.media (Player) media. It also defines the Manager class (factory for
Players)

Defines the media-specific content handling APIs the Control

javax.microedition.media.control
types (12 total) that can be used with Players

Defines interfaces an d classes that hide how data is read from a

javax.microedition.protocol
source.

The MMAPI splits media processing into two main concepts: data source and the respective handlers (media protocols
specified via a URL) and content handlers (media players and controls). A media Manager provides a factory of resources
such as players as well as methods to query for supported content types and protocols:

6
 Manager Create Player
(Player Factory)

Creates Application
Controls
Data Source Consumes Player Control(s)
(Content) (Content Handler) Controls

Generates

Digital
Tones Image Video
Audio

Figure 2 The MMAPI Manager, Player, Player Control and Data Sources
The entry point to any MMAPI-based application is the Manager, which is a factory of Players for multimedia processing.
A Player (the content handler) consumes and renders content. A Player provides basic multimedia functionality such as
start and stop multimedia playing, and the overall multimedia playing life-cycle. The Player can also expose extended
multimedia functionality through the use of Controls . Examples of controls are the ToneControl and VideoControl. The
Manager also includes a simple tone player. Not shown in Figure 2 is the PlayerListener , which can be used by the
application for fine-grained control. Using a PlayerListener an application can keep track of the Players state, for
example, when a Player has been started, stopped, or when the end of media has been reached.
The MMAPI v 1.0 s pecification defines protocols, controls and players for a number of media types, such as
MIDIControl, VideoControl, ToneControl, and VolumeControl (12 total in MMAPI v 1.0). The specification does
not mandate any particular one, allowing profiles to use a subset the MMAPI as appropriate the only requirement is
that implementations must guarantee support of at least one media type and protocol. In the case of the
T610/T616/T618 and Z600, the only supported audio-control is the ToneControl. The MMAPI subset does support
multiple audio media formats including simple tone generation, plus MIDI, AMR, and iMelody playback.
Later in this article we will see how to use the MMAPI to play various audio media formats. For more information on the
MMAPI, please refer to The Mobile Media API. For detailed information how to use the MMAPI with the T610/T616/T618
and Z600, consult the training course Making the Most of the Mobile Media API (JSR-135) with Sony Ericsson Handsets.

7
 3. Adapting Your MIDlets

Java is an excellent programming language and runtime environment for creating portable applications. But making
portable applications goes beyond just using Java.

3.1. General Considerations

A portable application is one that ru ns unmodified across devices. But there are a number of considerations that you must
be aware of to ensure your code can be easily moved across devices:
Avoid the use of proprietary, vendor -specific APIs. If this is not possible, define a generic interface as shown in
Figure 3, that allows you to abstract behavior and keep your application device independent.
Do not hard-code values such as screen coordinates and sizes, or storage these must be discovered at
runtime.
Write defensive code that uses memory efficiently and monitors the amount of available memory and storage, to
ensure robustness.

MyGameSounds
<<interface>>

playExplodingSound()
playFiringSound()
playBackgroundMusic()

Default
Sony Ericsson Nokia Motorola Other
(MMAPI) Behavior Behavior Behavior
Behavior
playExplodingSound() playExplodingSound() playExplodingSound() playExplodingSound()
playFiringSound() playFiringSound() playFiringSound() playFiringSound()
playBackgroundMusic() playBackgroundMusic() playBackgroundMusic() playBackgroundMusic()

Figure 3 Hiding Device Specific APIs From The Application

A design pattern such as the one above allows you to define some abstract behavior, for example, play exploding
sound, while hiding the low -level implementation details from the application (i.e. Sony Ericsson uses the MMAPI API
while a Nokia device uses com.nokia.mid.sound API). You would have the appropriate implementations for your
target devices or platforms that you would deploy as appropriate.
In some devices the sound and UI APIs may be vendor-specific, meaning that we must take special steps to adapt such
APIs to the T610/T616/T618 and Z600s MMAPI implementation. To understand this better, the following sections cover
sound and UI APIs in the T610/T616/T618 and Z600 phones and some porting considerations.

3.2. Managing Sound in the T610/T616/T618 and Z600

To manage sound generation we use Sony Ericssons implementation of MMAPI. Recall that the T610/T616/T618 and
Z600 support a subset of the MMAPI, specifically for audio control.
8
Using the MMAPI is very simple. For example, to play a predefined sequence of tones all you need is the following
snippet of code:
byte[] mySequence = ...
try {
Player mp = Manager.createPlayer(Manager.TONE_DEVICE_LOCATOR);
mp.realize();
ToneControl c =
(ToneControl) mp.getControl("javax.microedition.media.control.ToneControl");
c.setSequence(mySequence);
mp.prefetch();
mp.start();
} catch (Exception ex) {
...
}

In the above example we ask the Manager to create a tone Player to play back tone sequences stored in an array. To
control the tone player use the Players control methods realize(), prefetch(), and start(). There are many
other Player methods consult the MMAPI Javadoc . To select the tone sequence to play we use the tone control-specific
setSequence() method.
In addition to simple tone sequences, the T610/T616/T618 and Z600 also supports the following media formats:
MIDI the Musical Instrument Digital Interface player can be located by using the "audio/midi" media locator
Uniform Resource Identifiers (URI) syntax.
AMR the Adaptive Multi -Rate player can be located by using the "audio/amr " media locator URI syntax.
iMelody the iMelody player can be located by using the "audio/imelody " media locator URI syntax.

Playing any of the above media formats is as simple as playing a tone sequence. For example, the following snipp et of
code plays a file that contains iMelody commands:
try {
InputStream is = getClass().getResourceAsStream(fileName);
mp = Manager.createPlayer(is, "audio/imelody ");
mp.prefetch();
mp.start();
} catch (Exception e) {
...
}

Note how we use method getResourceAsStream() to create an input stream from a file that is stored in the MIDlet
suite. To create our Player, we pass the input stream and the media locator audio/imelody to the Manager, which
returns the iMelody Player. We then use the player control methods as previously described.
To play AMR media formats we do exactly as above, but we load an AMR file and specify audio/amr as the media
locator. You can create AMR files by converting existing Wave (.WAV) sound files into AMR media formats by using the
Sony Ericsson AMR Converter, which is downloadable from the Ericsson Mobility World site: Sony Ericsson AMR
Converter.

9
3.2.1. Reducing Playback Latency
There are times when a Player must perform a number of time-consuming tasks before it is ready to be started. This
includes allocating resources, filling buffers, or other start-up processing. This results in a long delay when calling
Player.start(). To minimize this delay or latency always pre-fetch your sounds before starting the player. This is
simply done by calling Player.prefetch().

3.2.2. Using Multiple Players

A typical multimedia application uses multiple Players. For example, a game may play background music, and then play
some audio effects such as a firing sound. With the MMAPI you can have more than one Player executing
simultaneously, and even synchronize them if needed. However, while the Sony Ericsson implementation of MMAPI
supports multiple players, only one player can be active at a time. Youll see how to deal with this in a moment.
Background music typically repeats itself for the duration of the application. We already have covered how to play tones
or iMelody and AMR media formats, but we have not covered how to restart a playback in an efficient manner. The
following code snippet uses a PlayerListener to keep track of Player events, specifically END_OF_MEDIA . When the
end of the background music is reached, we simply re-start the player:
public class DmaxMIDlet extends MIDlet implements CommandListener, Runnable
{
Player p;
String filename = /background.amr;
:
:
public void startApp() throws MIDletStateChangeException {
:
: // startup code...
:
initMIDlet();
}

:
: // pauseApp(), destroyApp(), other.
:

/** Initialize the MIDlet */

private void initMIDlet() {
:
: // Some other initialization code...
:

// Create a player for the background music. Pre-fetch and start the music!
try {
InputStream is = getClass().getResourceAsStream(fileName);
p = Manager.createPlayer(is, "audio/amr");
p.addPlayerListener(new Listener());
p.prefetch();

10
 p.start();
} catch (Exception ioe) {
...
}
}

:
: // Other MIDlet methods...
:

/**
* This inner class implements a PlayerListener. Its purpose is to continuously
* repeat the background music.
*/
class Listener implements PlayerListener {
public void playerUpdate(Player p, String event, Object eventData) {
if (event == END_OF_MEDIA) {
try {
p.start();
} catch (MediaException me) { }
break;
}
}
}
}

The PlayerListener is key to fine-grained control in general. Player events that can be tracked are:
BUFFERING_STARTED, BUFFERING_STOPPED, CLOSED, DEVICE_AVAILABLE, DEVICE_UNAVAILABLE,
DURATION_UPDATED, END_OF_MEDIA, ERROR , RECORD_ERROR, RECORD_STARTED , RECORD_STOPPED,
SIZE_CHANGED, STARTED, STOPPED, STOPPED_AT_TIME, VOLUME_CHANGED .
Playing foreground audio, such as the firing sound on a game is simply done by starting the player when the fire key is
pressed. The following code snippet shows elements of a Canvas class that creates a player, pre-fetches content, and
then, when the fire key is pressed, starts the Player to play the fire tone sequence.
public class MyCanvas extends Canvas
{
byte[] fireSequence = ...;
Player firePlayer;
:
:

private void initPlayer() {

try {

11
 firePlayer = Manager.createPlayer(Manager.TONE_DEVICE_LOCATOR);
firePlayer.realize();
ToneControl c =
(ToneControl)mp.getControl("javax.microedition.media.control.ToneControl");
firePlayer.setSequence(fireSequence);
firePlayer.prefetch();
} catch (Exception ex)
...
}
}

public void paint(Graphics g) {

:
... // Paint as appropriate
}

protected void keyPressed(int keyCode) {

int gameAction = getGameAction(keyCode);
switch(gameAction) {
case UP:
... // Do "UP" processing
break;
case DOWN:
... // Do "DOWN" processing
break;
case LEFT:
... // Do "LEFT" processing
break;
case RIGHT:
... // Do "RIGHT" processing
break;
case FIRE:
firePlayer.start(); // Play the fire sound...
break;
}
}
}

What happens when you have both of these Players active in, say, a game? Player p plays continuously, providing the
background mus ic. However, once firePlayer starts, this halts p and the background music. When firePlayer
completes the playback of its media, an END_OF_MEDIA event is sent to both Players. This has p resume the playback of
its media, since it is set to play continuously. Be aware that background music playback resumes from the start of the
media, and not at the point that p was interrupted. However, with a carefully designed soundtrack, you can minimize the
12
effect of firePlayer constantly restarting the background music. For more information, consult the training course
Making the Most of the Mobile Media API (JSR-135) with Sony Ericsson Handsets.

3.3. Managing The Vibrator, LEDs and Backlight

The iMelody format is of special interest because in addition to generating tones, it can also be used to control volume,
the devices vibrator, LEDs, and backlight. Originally created by the Infrared Data Association, iMelody is becoming the
standard format for ring-tones. Below are a number of examples on iMelody, taken from the Sony Ericsson J2ME SDK
found at the Ericsson Mobility World - Developer Zone.

Using iMelody to set off the Vibrator:

BEGIN:IMELODY
VERSION:1.2
FORMAT:CLASS1.0
NAME:Vibrate
BEAT:200
STYLE:S1
Melody:(vibeonr5vibeoff@100)
END:IMELODY

Using iMelody to manipulate the backlight:

BEGIN:IMELODY
VERSION:1.2
FORMAT:CLASS1.0
NAME:Test BackLight
BEAT:200
STYLE:S1
Melody:(backonr3backoff@100)
END:IMELODY

Using iMelody to manipulate the LEDs:

BEGIN:IMELODY
VERSION:1.2
FORMAT:CLASS1.0
NAME:Test LED
BEAT:200
STYLE:S1
Melody:(ledonr3ledoff@10)
END:IMELODY

Using iMelody for Tone generation:

BEGIN:IMELODY
VERSION:1.2
FORMAT:CLASS1.0
NAME:IndyJones
COMPOSER:
BEAT:480
STYLE:S0
VOLUME:V15
MELODY:*5c4e3r1r4d4f3r4e4g3r4c4r3.e4*6c1:r4*5c4r3.c4r3.c4r1:r4c4
d1r2e3r4c4f3.r2c4r1:r4c4r3.c4r3.c4r1:r4c4g1r2a3r4c4b3r4c4r3.a4*6
f1:r4*5c4r3.c4r3.c4r1:r4f4a0;r5;g4b3.c4*6c2:r1*5g4*6d1r2:c4e1
END:IMELODY

13
As previously explained, you would store the appropriate sequence of iMelody commands in a file within the MIDlet suite.
To load this file for later playback you use the getResourceAsStream() method.

3.4. Managing the User Interface in the T610/T616/T618 and Z600

Creating and controlling the T610/T616/T618 and Z600 user interface is accomplished by using the standard MIDP 1.0
APIs that are found in LCDUI package javax.microedition.lcdui .
The LCDUI provides both a high and a low-level API. The low-level API allows for more fine-grained control the type of
precise control that games require. At the center of the low-level API are the Canvas, Graphics and Image
classes, which allows you to handle low -level events and call graphic functions to draw onto the screen.
Covering the LCDUI in detail is outside the scope of this article. For more information on how to use the MIDP 1.0 low -
level APIs please refer to the Sun Microsystems Wireless Portal, where you can find a number of related articles.

3.5. Moving Your Nokia Series 40 MIDlet to the T610/T616/T618 and Z600
The Nokia Series 40 also supports MIDP 1.0. But in addition to the standard MIDP APIs, the Nokia Series 40 introduces
proprietary APIs for the following:
Low-level access to image pixel data
Transparency support
Full screen drawing
Sound
Vibration and device lights control

These APIs are package under the com.nokia.mid.sound and the com.nokia.mid.ui Java packages. But as
mentioned earlier, once your MIDlet uses any proprietary APIs, your code becomes non-portable.

For networking, persistence storage, and to managing the MIDlet lifecycle, the Nokia Series 40 uses the standard MIDP
1.0 APIs, so we dont have any concerns with respect to those APIs. It is the sound and user interface APIs that are of
concern. The next section will show how to adapt existing Nokia Series 40 MIDlets to the T610/T616/T618 and Z600
phones.

3.5.1. Adapting The Nokia Series 40 Sound API

Adapting the Nokia Series sound API to the T610/T616/T618 and Z600 requires converting the sections of code using
com.nokia.mid.sound to use the MMAPI. Table 4 summarizes how to map the Nokia Sound API to the
T610/T616/T618.

Table 4 Mapping the Nokia Sound API to T610 and Z600

com.nokia.mid.sound Description T610/T616/T618, Z600

The MMAPI defines the

This interface is used by applications that need to PlayerListener interface for
SoundListener receive events that indicate changes in the receiving asynchronous events
playback state of the Sound objects.
generated by Players.

The MMAPI defines a Manager , a

Provides a simple sound API for playing tones
Sound Player and various media
and digitized audio.
controls.

14
Similar to the MMAPI, the Nokia sound API provides methods that include setting the sound to play, start, and stop
playing. This makes the mapping of com.nokia.mid.sound to the MMAPI pretty direct. Table 5 shows how simple
generation can be done in the Nokia Series 40 and the T610/T616/T618 and Z600 using the MMAPI.

Table 5 Comparing Simple Tone Generation

Using the Nokia com.nokia.mid.sound Using the MMAPI

API
import com.nokia.mid.sound.*; import javax.microedition.media.*;
... import javax.microedition.media.control.*;
...

Sound sound = new Sound(262, 150); Manager.playTone(ToneControl.C4, 150, 100);

... ...

sound.play(1);
...

In the example above, frequency 262 maps to the Mobile Media note value of ToneControl.C4. This corresponds to
the MIDI note C4, at 261.63 Hz. The constant value for ToneControl.C4 is 60, which maps to the MIDI note number for
this same frequency. All of the ToneControl values repres ent MIDI note numbers, so its easy to map Nokia Sound API
frequencies to Mobile Media API MIDI note numbers. For your convenience refer to Appendix 1 , which shows this
relationship between the Nokia Sound API frequencies and the Mobile Media API MIDI numbers. For clarity, the Table
omits the scale's sharp and flat notes.

The Nokia API can also play a sequence of tones, including digitized sound based on the WAV encoding if supported by
the particular device. Note that the T610/T616/T618 and Z600 do not support WAV encoding, so you must use any of the
alternate audio formats described shortly.
To play a sequence of bytes using the Nokia API you must use a Sound object using the following Constructor:
public Sound(byte[] data, int type)

Then play the sequence using the sound.play(int loop) method. You can also play a sequence of tones by first
initializing the Sound object by using the method Sound.init(byte[] data, int type) then calling
sound.play(int loop) to play it.
Playing sequence of tones using the MMAPI is more involved, as the ToneControl provides more tone control
capabilities, as shown in the following snippet of code taken from the Sony Ericsson J2ME SDK.
byte C4 = ToneControl.C4;
byte D4 = C4 + 2; // a whole step
byte E4 = C4 + 4; // a major third
byte G4 = C4 + 7; // a fifth
byte rest = ToneControl.SILENCE; // eighth-note rest
byte d = 8;
byte[] mySequence = new byte[] {
ToneControl.VERSION, 1,
ToneControl.TEMPO, 30,
ToneControl.BLOCK_START, 0,
E4,d,D4,d,C4,d,D4,d,E4,d,E4,d,E4,d,rest,d,
ToneControl.BLOCK_END,0,
ToneControl.PLAY_BLOCK,0,
D4,d,D4,d,D4,d,rest,d,E4,d,G4,d,G4,d,rest,d,//play "B" section
ToneControl.PLAY_BLOCK,0, // content of "A" section
D4,d,D4,d,E4,d,D4,d,C4,d,rest,d// play "C" section
};
15
 ...
mp = Manager.createPlayer(Manager.TONE_DEVICE_LOCATOR);
mp.realize();
ToneControl c = (ToneControl)mp.getControl("ToneControl");
c.setSequence(mySequence);
mp.prefetch();
mp.start();

In addition to simple tone generation, the T610/T616/T618 and Z600 supports other audio media formats including the
iMelody, AMR, and MIDI. To play iMelody, AMR and MIDI content, the content is stored o utside the MIDlet itself as a
resource, and loaded and played at run time as shown in the following example:
try {
String my_imelody_file = "/my_imelody_file";
String mediaType = "audio/imelody";
int loopCount = 1;
InputStream is = getClass().getResourceAsStream(my_imelody_file);
mp = Manager.createPlayer(is, mediaType);
mp.setLoopCount(loopCount);
mp.prefetch();
mp.start();
} catch (Exception ex) {
...
}

The source code to play an AMR or MIDI files look exactly the same, except the media type and resource location strings
need to be adjusted as appropriate.

3.5.2. Adapting The Nokia Series 40 UI API

Adapting the Nokia Series 40 UI API to the T610/T616/T618 and Z600 MMAPI requires converting the code sections that
depend on com.nokia.mid.ui to use the standard MIDP 1.0 javax.microedition.lcdui LCDUI package. Table 6
summarizes how to map the Nokia UI API to the T610/T616/T618 and Z600 phones.

Table 7 Mapping the Nokia UI API to the T610 and Z600

com. nokia.mid.ui Description T610/T616/T618, Z600

There is no similar class in MMAPI.
Developers must create their own polygons
DirectGraphics contains some graphics
and triangles drawing methods, and other
extensions for MIDP Graphics, with which
features found in DirectGraphics . Use
polygons and triangles can be drawn and
DirectGraphics filled, images can be rotated or flipped, the standard LCDUI Graphics class
instead.
alpha channel color supported and raw
pixel data can be directly obtained from the
graphics context or drawn to it. Note that the T610/T616/T618 is a dual
processor device, making parallel
processing possible when doing graphics.
DeviceControl provides a collection of
There is no device control class in MMAPI.
methods to control some of the special
DeviceControl Instead, use iMelody sequences to control
features available i n mobile devices, e.g.,
the vibrator, and LCD backlight.
vibration and screen (LCD) backlight
This class is a placeholder for utility There is no similar class in MMAPI. Use the
DirectUtils methods. standard LCDUI Image class instead.
There is no similar class to the
FullCanvas FullCanvas a Canvas that provides a full FullCanvas. Use the standard LCDUI
screen painting area.
Canvas class instead.

16
Adapting th e DirectGraphics and DirectUtils classes to the T610/T616/T618 and Z600 (or any other standards
based device) is more complicated than adapting DeviceControl or FullCanvas . As described in Table 6, we can
implement similar capabilities found in the DeviceControl class by using iMelody sequences. Recall that the iMelody
sequences support ways to turn on/off the vibrator, LEDs and backlight. In the case of FullCanvas, we would use the
standard LCDUI Canvas instead. Because the screen sizes of the Nokia Series 40 versus those T610/T616/T618 and
Z600 are very similar, your Nokia Series 40 MIDlet should map very easily to these phones. Also note that by not using
FullCanvas we dont have to worry about the detail that FullCanvas doesnt support LCDUI Command or
CommandListener. Put another way, using FullCanvas forces us to implement an alternate way to capture user
interface commands. Because the LCDUI Canvas class does support Command and CommandListener, our code
becomes simpler.
To keep your code portable, you must never hardcode values such as coordinates or screen sizes you must always
discover these through the appropriate API methods. Recall that the Canvas provides methods to discover the actual
size of the drawing area, as shown next:
int imageWidth = image.getWidth();
int imageHeight = image.getHeight();
int canvasWidth = getWidth();
int canvasHeight = getHeight();

Once you have the above information, you can scale and draw your user interface as appropriate. For example, the
following code snippet implements the paint() method of a Canvas:
public void paint(Graphics g) {

int imageWidth = image.getWidth();

int imageHeight = image.getHeight();
int canvasWidth = getWidth();
int canvasHeight = getHeight();

g. fillRect(0, 0, canvasWidth, canvasHeight);

...

int anchor = (Graphics.TOP | Graphics.HCENTER);

...

g.drawImage(image, (canvasWidth/2), y, anchor);

...

17
 4. Conclusion

This paper has covered the new Sony Ericsson T610/T616/T618 and Z600, which are high-end wireless communicators
with support for MIDP 1.0 and the Mobile Media API. It also covered details that developers must be aware of when
creating new MIDP applications, or migrating existing applications to the T610/T616/T618 and Z600.

The T610/T616/T618 and Z600 are completely standards based no proprietary APIs are exposed, ensuring that MIDlets
created for these phones are truly portable.

Adapting applications to the T610/T616/T618 and Z600 is also simple. First, as a truly standards based platform, any
MIDP application can be ported to these phones with minimal or no changes. Adapting MIDlets from devices that uses
proprietary extensions such as the Nokia Series 40 is more involved but not difficult to do, as this paper shows.

18
 5. Appendix 1 - Map of Nokia Frequencies to
MIDI Note Numbers

Nokia ring MIDI note

MIDI Note name Nokia ring note Frequency
frequency number

A0 - 27.5 28 21

B0 - 30.868 31 23

C1 - 32.703 33 24

D1 - 36.708 37 26

E1 - 41.203 41 28

F1 - 43.654 44 29

G1 - 48.999 49 31

A1 - 55 55 33

B1 - 61.735 62 35

C2 - 65.406 65 36

D2 - 73.416 73 38

E2 - 82.407 82 40

F2 - 87.307 87 41

G2 - 97.999 98 43

A2 - 110 110 45

B2 - 123.47 123 47

C3 - 130.81 131 48

19
D3 - 146.83 147 50

E3 - 164.81 165 52

F3 - 174.61 175 53

G3 - 196 196 55

A3 A0 220 220 57

B3 B0 246.9 4 247 59

C4 C0 261.63 262 60

D4 D0 293.67 294 62

E4 E0 329.63 330 64

F4 F0 349.23 349 65

G4 G0 392 392 67

A4 A1 440 440 69

B4 B1 493.88 494 71

C5 C1 523.25 523 72

D5 D1 587.33 587 74

E5 E1 659.26 659 76

F5 F1 698.46 698 77

G5 G1 783.99 784 79

A5 A2 880 880 81

B5 B2 987.77 988 83

C6 C2 1046.5 1047 84

D6 D2 1174.7 1175 86

E6 E2 1318.5 1319 88

F6 F2 1396.9 1397 89

G6 G2 1568 1568 91

A6 A3 1760 1760 93

B6 B3 1975.5 1976 95

C7 C3 2093 2093 96

20
 D7 D3 2349.3 2349 98

E7 E3 2637 2637 100

F7 F3 2793 2793 101

G7 G3 3136 3136 103

A7 A4 3520 3520 105

B7 B4 3951.1 3951 107

C8 C4 4186 4186 108

For the proper mapping of Tone values, please refer to the Nokia and the MMAPI documentation.

21
 6. Appendix 2 - Resources

For your convenience, below are some links of interest:

Sony Ericsson Developer World (http://www.sonyericsson.com/developer)

Sony Erics son J2ME SDK (http://www.ericsson.com/mobilityworld/sub/open/devices/t610/docs/j2me_sdk_t610)
Sony Ericsson AMR Converter
(http://www.ericsson.com/mobilityworld/sub/open/technologies/messaging/tools/amr_converter)
Ericsson Mobility World - Developer Zone (http://www.ericsson.com/mobilityworld/sub/open/index.html)
Sun Microsystems Wireless Portal (http://wireless.java.sun.com/)
Sun Microsystems MIDP page (http://java.sun.com/products/midp/)
MIDP 1.0 Specification (http://www.jcp.org/en/jsr/detail?id=37)
The Mobile Media API (http://java.sun.com/products/mmapi/)
Java Community Process JSR-135 (http://www.jcp.org/en/jsr/detail?id=135)
iMelody Specification (http://www.irda.org/standards/pubs/iMelody.pdf)

22
 7. Appendix 3- T610 Firmware Update

7.1. Availability of firmware upgade for the T610 phone

Sony Ericsson has improved Java's performance on the T610 since its initial release. If you have experienced problems
in running demanding graphics applications on the T610, you should obtain this latest firmware release.
This firmware release is to be rolled out in the new T610's sold in stores starting after September 2003.
To determine the current version of firmware on your T610, perform the following key sequence on your phone:
Move the joystick once to the right, and press *
Move the joystick twice to the left, and press *
Move the joystick once to the left, and press *

In the menu that appears, select "Service information" and then "SW information" (note that the menu names may differ in
other languages). The information about which SW revision (R followed by a number) your handset has will now be
displayed.
If your software number says "R3B" , it incorporates all performance fixes and is also TCK-compliant. If your handset has
a lower software revision number on (such as "R3A"), you should contact your nearest Sony Ericsson service point to get
your T610 updated with the latest software. The nearest service point can be found in the documentation in the phone
box or on the Sony Ericsson Global support web site (http://www.sonyericsson.com/support).
If you were provided a handset through the Sony Ericsson Developer Program or a local Ericsson Mobility World center
with which Sony Ericsson collaborates, you should consult that contact as how to get the handset updated.
There is no easy way to detect directly from a Java application the firmware version that phone uses. However, your
download server can detect if the phone has the new or the old software version through the User Agent field in the HTTP
protocol during a download. The SW version in the useragent field for the new software is: "SonyEricssonT610/R301
Profile/MIDP-1.0 Configuration/CLDC-1.0". If the "R301" is replaced by a lower value ("R201" for example)
it is the old firmware version. If instead the "R301" is replaced by a higher value ("R401" for example) it is a newer
version that includes the performance improvements.

23