Just An Application

June 19, 2009

What’s New In MIDP 3.0 ? Part 15: Localized MIDlet Attributes

The MIDlet-<n> attribute is now a localizable attribute. It is possible for a MIDlet to have a locale specific name and icon, and also, apparently, class.

A locale specific variant of a given


attribute can be specified using a corresponding



The value of the attribute must be of the form

    [<name>] "," [<icon>] "," [<class>]

where, as for a MIDlet-<n> attribute, <name> is the name of the MIDlet, <icon> the icon with which to represent the MIDlet, and <class> the MIDlet class, and the same constraints apply.

The name, icon, and class that are used for the n‘th MIDlet are defined to be the values specified by the MIDlet-<n>-<locale> attribute whose <locale> matches the current locale. In each case if there is no locale specific version, then the value specified by the corresponding MIDlet-<n> attribute is used instead.

If there is no matching MIDlet-<n>-<locale> attribute then the values default to those specified by the MIDlet-<n> attribute.


Assuming the following MIDlet-<n> and MIDlet-<n>-<locale> attributes are specified

    MIDlet-1:       SwatchMIDlet, SwatchMIDlet.png, example.midlet.SwatchMIDlet
    MIDlet-1-en-UK: ColourSwatchMIDlet
    MIDlet-1-en-US: ColorSwatchMIDlet, ColorSwatchMIDlet.png

then the possible values for the MIDlet name, icon and class are as follows

Locale MIDlet Name MIDlet Icon MIDlet Class
en-UK ColourSwatchMIDlet SwatchMIDlet.png example.midlet.SwatchMIDlet
en-US ColorSwatchMIDlet ColorSwatchMIDlet.png example.midlet.SwatchMIDlet
Any other locale SwatchMIDlet SwatchMIDlet.png example.midlet.SwatchMIDlet


On the basis of the documentation for the MIDlet-<n>-<locale> attribute it would appear that a MIDlet class can be locale specific.
It is certainly not explicitly forbidden. If this is true then it has implications for other supported features.

For example, push connections. The MIDlet-Push-<n> attribute specifies the class of the MIDlet to launch. The documentation states

The named MIDlet MUST be registered in the application descriptor or the JAR manifest with a MIDlet-<n> record.

The same constraint applies to the dynamic registration of alarms

The named MIDlet MUST be registered in the application descriptor or the JAR manifest with a MIDlet-<n> record. This parameter has the same semantics as the MIDletClassName in the Push registration attribute defined above in the class description.

using the PushRegistry.registerAlarm() method, and push connections

The named midlet MUST be registered in the application descriptor or the JAR manifest with a MIDlet-<n> record. This parameter has the same semantics as the MIDletClassName in the Push registration attribute defined in the class description.

using the PushRegistry.registerConnection() method.

The use of a MIDlet class to identify a MIDlet is not unique to alarm and push connection registration. Event Handler registration also requires the use of a class name.

For static registration the MIDlet-Event-Launch-<n> does not explicitly require that the class has been registered via a MIDlet-<n> attribute, which is in itself an issue, but dynamic registration does. Documentation for all variants of the EventHandler.registerApplication() method states

For MIDP, the named application class MUST be registered in the JAD or JAR Manifest for the MIDlet suite of the calling MIDlet with a MIDlet-<n> application attribute, and MUST extend javax.microedition.midlet.MIDlet.

Outside MIDP there is the Content Handler API (JSR211) which also uses class names for static and dynamic registration of content handlers as well as for generating Application IDs.

If a MIDlet class can be locale specific then the specification really needs to explain what the semantics of MIDlet classes now are and how the features mentioned above should work in this case.

If a MIDlet class cannot be locale specific then this needs to be made explicit.

There is one possible further complication. In discussing whether localized attributes should be
discarded at installation time the specification states

Usually one or more localized attribute versions end up being retained …

It is not clear why any localized attributes other than those matching the current locale actually
need to be retained. One possibility is that is is expected that if the current locale changes
subsequently then the appropriate localized attributes should be used. For most attributes this
is fairly innocuous, the MIDlet Suite description, for example, would simply be in language A
rather than language B. If MIDlet classes can be locale specific however things get very
complicated indeed: push connections, event handlers and content handlers could all end up
registered to the wrong MIDlet class. I assume that this is not what is intended.

Copyright (c) 2009 By Simon Lewis. All Rights Reserved.


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Blog at WordPress.com.

%d bloggers like this: