Just An Application

December 16, 2009

What’s New In MIDP 3.0: Redux – LCDUI – Command Layout

Filed under: Java, JME, LCDUI, MIDP, MIDP3, MIDP3Issues, MIDP3LCDUI — Tags: , , , , , , — Simon Lewis @ 10:49 am

Original Post

Changes Since Proposed Final Draft


The following has been added to the end of the Exact Placement of Commands section
of the Display class documentation.

On each callback of CommandLayoutPolicy.onCommandLayout(Displayable), implementation MUST first disassociate Command and Menu
with their respective previous placements. At the beginning of each callback of CommandLayoutPolicy.onCommandLayout(Displayable) method,
Displayable.getCommand(int) or Displayable.getMenu(int) will return null for every placement.

As I said in my original post

  1. The specification does not contain an explicit definition of the state of a Display’s placements when the onLayout(Displayable)[sic] method is called, that is, whether Commands and/or Menus previously placed on the current Display by the Displayable are still present or whether all Commands and/or Menus must be explicitly placed each time the method is called. This makes implementing the method perhaps more interesting than it ought to be.

Well now it does. Every time you layout a Displayable’s Commands you start with a clean slate.


The setCommand(Command,int) method no longer throws an IllegalArgumentException when the placement

is associated with a placement that does not support commands

possibly because it is actually not possible for a placement not to support Commands.

It is hard to be sure because the Item.setCommand(Command,int) method will apparently still throw an IllegalArgumentException when the placement

is associated with a placement that does not support commands

The CommandLayoutPolicy Example

The CommandLayoutPolicy now looks like this. Actually it doesn’t because I have re-formatted it. In Chrome, Firefox and Safari the formatting is all over the place, as it is in the PDF version.

class MyCanvas extends Canvas implements CommandLayoutPolicy {
    MyCanvas() {

    void sort(Command[] commands, int[] positions) {
        // sort the commands in the correct order depending on the positions available.
        // Implementation can use Display's getCommandPreferredPlacements to get the recommended 
        // placement for each Command.
    public void onCommandLayout(Displayable displayable) {
        Display display = displayable.getCurrentDisplay();
        final int border = Display.SOFTKEY_BOTTOM;
        int[] positions = display.getExactPlacementPositions(border);
        int numOfPositions = positions.length;
        Command[] cmd = displayable.getCommands();
        sort(cmd, positions);
        if (cmd.length <= numOfPositions) {
            for (int i = 0; i < cmd.length; ++i) {
                displayable.setCommand(cmd[i], positions[i]);
        } else {
            for (int i = 0; i < numOfPositions ; ++i) {
                displayable.setCommand(cmd[i], positions[i]);
            int[] menuSupportedPlmts = display.getMenuSupportedPlacements();
            if( menuSupportedPlmts != null ) {
                Menu options = new Menu("More", null, null);
                // first add the remaining commands in the Menu
                for (int i = numOfPositions; i < cmd.length; ++i) {
                // Get the first preferred placement of Menu
                int menuPlmt = menuSupportedPlmts[0];
                // check if this placement already occupied by Command
                if( displayable.getCommand(menuPlmt) != null ) {
                    //add the existing Command in Menu, otherwise the existing
                    // Command will be removed from the Displayable according to
                    //setMenu() method
                displayable.setMenu(options, menuPlmt);                    

This is an improvement on the previous version which was flat-out broken. Note that it still doesn’t check the return value of the call to Display.getExactPlacementPositions(int).


The changes above are the only ones that I have found. Of the original issues I raised they address two if you are being charitable.

  1. What is the state of the Displayable with respect to Command layout when the CommandLayoutPolicy.onCommandLayout(Displayable) method is invoked ? It is a clean slate

  2. Can there be placements which do not support Commands ? Probably not.

Everything else is still up for grabs. Developers, assuming there are going to be any, are going to have to try it and see what happens, and then hope it happens the same way everywhere, which is the past has not been a guaranteed recipe for success.

Possibly if somebody had attempted to write a real-world example for the specification the Command layout feature itself would have been better specified. The example provided effectively does no more than provide the existing default behaviour.

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

Blog at WordPress.com.

%d bloggers like this: