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

    MIDlet-<n>

attribute can be specified using a corresponding

    MIDlet-<n>-<locale> 

attribute.

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.

Example

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

Issues

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.

What’s New In MIDP 3.0 ? Part 14: Localizable Attributes

MIDP 3 adds support for localizable attributes, that is, attributes which can have locale specific values in addition to the value specified by the attribute itself.

A locale specific value for a localizable attribute can be specified at installation time using a localized attribute, which is an attribute whose name is formed from the name of the localizable attribute with the suffix

    "-"<locale>

appended, where the value of <locale> is of the form

    <language> ["-" <country> ["-" <variant>]]

The value of <language> must be a lower-case ISO-639-1 two-letter language code.

The value of <country> if present must be an upper-case ISO-3166-1 two-letter country code.

For example, the existing attribute

    MIDlet-Description 

is now localizable. so it is now possible to define locale specific versions of the MIDlet Suite description using attributes such as

• MIDlet-Description-de
• MIDlet-Description-de-DE
• MIDlet-Description-fr
• MIDlet-Description-tr

Multiple locale specific values of a localizable attribute can be specified at installation time. For example, all the MIDlet-Description localized attributes above can appear in the JAD and/or manifest of the MIDlet Suite Jar.

At installation time the specification permits an implementation to discard all those localized attributes whose specified language is not supported by the device.

The value of a localizable attribute to be used is selected on the basis of the current locale. If there is a locale specific variant of the localizable attribute whose locale matches the current locale then the specified value is used. If there is no matching locale specific variant the value of the localizable attribute itself is used.

The algorithm used to do locale matching is similar to the one used to select locale specific resources in JSE. In pseudo-code it might be expressed as follows

    current = current locale
    if attribute with locale equal to current found then
        return matching attribute
    else
    if current has variant then
        current = current with variant removed
        if attribute with locale equal to current found then
            return matching attribute
        else
            current = current with country removed
            if attribute with locale equal to current found then
                return matching attribute
            else
                return no match
            endif
       endif
   else
   if current has country then
       current = current with country removed
       if attribute with locale equal to current found then
          return matching attribute
       else
           return no match  
       endif
   else
       return no match
   endif

Note

As has been mentioned, the specification permits an implementation to discard at installation time any localized attributes for languages not supported on the device. It is not clear whether the discarded localized attributes are subsequently accessible via the variants of the MIDlet.getAppProperty() methods. If they are not then it would be useful if the specification made this clear. Alternatively, if they are accessible it is not clear what discard might actually mean in this context.

---

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