Just An Application

June 29, 2009

What’s New In MIDP 3.0 ? Part 21: LCDUI – Command Layout

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

1. The Command Layout Model

  • a MIDlet may explicitly control how a Displayable’s Commands are presented to the user when that Displayable is visible on a Display.

  • a MIDlet may choose to present a Displayable’s Commands individually or grouped into Menus.

  • a placement is a Display specific position which identifies a key, soft-key, or other interaction mechanism
    with which a Command or Menu may be associated.

  • a Display may have zero or more associated placements

  • the layout of a Displayable’s Commands requires the mapping of those Commands to a Display’s available placements, either directly or grouped into a Menu or Menus.

  • the explicit layout of a Displayable’s Commands is performed by an object which implements the CommandLayoutPolicy interface

  • any Displayable, except for instances of FileSelector, may have an associated CommandLayoutPolicy object

  • any Display may have an associated CommandLayoutPolicy object

  • the layout of a Displayable’s Commands is only performed when a Displayable is associated with a Display

  • the layout of a Displayable’s Commands is only required when the current Command layout is invalid. This can occur, for example

    • if the Displayable has not previously been visible on a given Display

    • if the orientation of a Display changes while the Displayable is visible

    • if one or more placements associated with a Display become invalid while the Displayable is visible

    • if the Command layout has been explicitly invalidated

  • when layout of a Displayable’s Commands is required then

    1. if the Displayable has an associated CommandLayoutPolicy object it will be used. If not then

    2. if the Display has an associated CommandLayoutPolicy object it will be used. If not then

    3. an implementation specific layout mechanism will be used.

  • if an Exception occurs during the use of a Displayable’s CommandLayoutPolicy object then

    1. if the Display has an associated CommandLayoutPolicy object it will be used. If not then

    2. an implementation specific layout mechanism will be used.

  • if an Exception occurs during the use of a Display’s CommandLayoutPolicy object then an
    implementation specific layout mechanism will be used.

  • a CommandLayoutPolicy object is responsible for the layout of all a Displayable’s Commands.

    • a Command will not be available to the user unless it is mapped to a placement or is a member of a Menu which itself is available to the user.

    • a Menu will not be available to the user unless it is mapped to a placement or is a sub-menu of a Menu which is itself available to the user.

  • if the Displayable is a Form then the Commands to be laid out can include those associated with Items in the Form.

  • if the Displayable is a TabbedPane then the Commands to be laid out can include those of the List or Form of the current Tab.


2. CommandLayoutPolicy

The CommandLayoutPolicy defines a single method.

    public void onCommandLayout(Displayable displayable)

A CommandLayoutPolicy object’s onCommandLayout(Displayable) method will be called with the Displayable whose Commands are to be laid out.

Notes

  1. The specification does not contain an explicit list of the circumstances under which this method will be called for a given Displayable, nor when it will be called relative to other events. For example, if an onLayout(Displayable) method is called as the result of an orienatation change, when it is called relative to the Display orientation change event.

  2. The specification does not contain an explicit definition of the state of a Display’s placements when the onLayout(Displayable) 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.

    The specification does say

    Any Command or Menu not explicitly set at a placement (via Displayable.setCommand(Command, int), Displayable.setMenu(Menu, int), or Item.setCommand(Command, int))
    in the CommandLayoutPolicy implementation will be ignored and not displayed.

    but omits to say when they have to have been explicitly set.

    On the other hand, the example code in the CommandLayoutPolicy class documentation, although somewhat broken, see below, explictly clears unused placements

        
    ...
    
        for (int i = cmd.length; i < positions.length; ++i) {
             //clear all non-used placements
             displayable.removeCommandOrMenu(border + positions[i]);
        }
    
    ...
  3. Currently the example code in the CommandLayoutPolicy class is broken and should not be used as an example of how to implement an onLayout method. See here.

3. Placements

For all Displays

  • a placement may be located on any one of the four borders

    • top,
    • bottom,
    • left,
    • right

    of the Display, or offscreen

  • each placement has an associated index
  • indices run from 1 to the maximum number of Commands possible at any location which is fifteen
  • for the horizontal borders, top and bottom, indices run from to left to right
  • for the vertical borders, left and right, indices run from top to bottom
  • the borders and directions are relative to the current orientation of the Display

For a given Display

  • there may be a set of preferred placements for a given Command type.
  • only a sub-set of the possible placements may support Menus.
  • there may be a set of preferred placements for Menus.

The set of possible placements is Display specific.

3.1 Runtime Constants

The possible locations are represented by the following constants defined in the Display class.

  • SOFTKEY_TOP
  • SOFTKEY_BOTTOM
  • SOFTKEY_LEFT
  • SOFTKEY_RIGHT
  • SOFTKEY_OFFSCREEN

3.2 Runtime Representation

At runtime a placement is represented by the integer which is the sum of the constant specifying its location and its index.


4. Layout Only Methods

The following Displayable methods can only be called during the layout of a Displayable’s Commands

In each case the method must only be called directly, or indirectly, from the onLayout(Displayable) method of a CommandLayoutPolicy object.

The Displayable the method is invoked on must either be

  • the Displayable that was passed to the onLayout(Displayable) method
  • or the Form or List of the current Tab, if the Displayable passed to the onLayout(Displayable) method is a TabbedPane

It is an error if these constraints are not met and an IllegalStateException will be thrown.

Item has a single method which can only be called during the layout of a Displayable’s Commands

The method must only be called directly, or indirectly, from the onLayout(Displayable) method of a CommandLayoutPolicy object.

The item that the method is invoked on must be contained within a Form which is either

  • the Displayable that was passed to the onLayout(Displayable) method, or
  • the current Tab of a TabbedPane that was passed to the onLayout(Displayable) method

It is an error if these constraints are not met and an IllegalStateException will be thrown.

5. Display CommandLayout Support

5.1 Getting The Current ComandLayoutPolicy

The current CommandLayoutPolicy object of a Display can be obtained by calling it’s

    public CommandLayoutPolicy getCommandLayoutPolicy()

method.

5.2 Setting The Current ComandLayoutPolicy

The current CommandLayoutPolicy object of a Display can be set by calling it’s

    public void setCommandLayoutPolicy(CommandLayoutPolicy policy)

method.

The specified CommandLayoutPolicy object will be used to perform the layout of the Commands of any Displayable which becomes current on this Display and which does not have an associated CommandLayoutPolicy object. If null was specified then a platform specific mechanism will be used.

5.3 Getting The Available Placements

The placements available on a given border of a Display, or offscreen, can be accessed using the Display’s

    public int[] getExactPlacementPositions(int border)

method.

The border argument must one of the runtime constants listed above.

The method returns the placements at the specified location, or null if there are no placements at that location.

Note

  • Despite being location specific the returned values are placements not indices.

5.4 Getting The Preferred Placements For A Command Type

The preferred placements for a given Command type can be obtained by using the Display’s

    public int[] getCommandPreferredPlacements(int commandType)

method.

It is an error if the commandType argument is not one of the runtime constants defined in the Command class which represent Command types.

The method returns null if there are no preferred placements for the given Command type.

5.5 Getting The Placements That Support Menus

The placements that support Menus can be obtained by using the Display’s

    public int[] getMenuSupportedPlacements()

method.

The method returns null if there are no placements that support Menus.

5.6 Getting The Preferred Placements For Menus

The preferred placements for Menus can be obtained by using the Display’s

    public int[] getMenuPreferredPlacements()

method.

The method returns null if there are no preferred placements for Menus.

6. Displayable Command Layout Support

6.1 Getting The Current Display

The Display, if any, with which the Displayable is currently associated can be obtained by calling the Displayable’s

    public Display getCurrentDisplay()

method.

The method will return null if the Displayable is not currently associated with a Display.

6.2 Getting The Current CommandLayoutPolicy

The current CommandLayoutPolicy object of a Displayable can be obtained by calling its

    public CommandLayoutPolicy getCommandLayoutPolicy()

method.

6.3 Setting The Current CommandLayoutPolicy

The CommandLayoutPolicy object responsible for laying out a Displayable’s Commands can be specified using it’s

    public void setCommandLayoutPolicy(CommandLayoutPolicy policy))

method.

6.4 Invalidating The Current Command Layout

The current Command layout of a Displayable can be invalidated by calling the Displayable’s

    public void invalidateCommandLayout()

method.

Note

  • The specification is not very forthcoming on what this method actually does.

    The full method documentation reads

    Request an update of the layout policy. If this displayable is not current on its display, or doesn’t have focus the request will be ignored.

    Presumably if the Displayable is current on its Display and the Display is in the Foreground state and the Displayable or the Display has an associated CommandLayoutPolicy object then, at some point the onLayout(Displayable) method of that object will be called.


6.5 Getting The Displayable’s Commands

The set of Commands that have been added to a Displayable can be obtained by calling it’s

    public Command[] getCommands()

method.

Note

  • See here for a discussion on what the return value of this method might actually contain.

6.6 Getting The Command At A Specific Placement

The Command associated with a specific placement of the Displayble’s current Display can be obtained by calling the Displayable’s

    public Command getCommand(int placement)

method.

It is an error if the placement argument is not valid and an IllegalArgumentException will be thrown.

Note

  • It is not clear when a placement is valid in this context, nor what will happen if this method is called when the Displayable is not associated with a Display. An answer to the first issue may resolve the second.

    There are two possible ways in which a placement may not be valid.

    1. It may not be well-formed, that is the location is not one of the runtime constants listed above, or the index is not between one and fifteen inclusive.

    2. It may be well-formed but not correspond to an actual placement on a given Display at a given time.

    If being valid means being well-formed then the method could simply return null when the Displayable has no current Display.

    If being valid means being well-formed and corresponding to an actual placement on a given Display then the method should throw an IllegalArgumentException if the Displayable does not have a current Display.

6.7 Placing A Command

During Command layout a Command can be associated with a specific placement using the Displayable’s

    public void setCommand(Command cmd, int placement)

This is a layout only method.

It is an error if the current Display of the Displayable does not support Commands and a DisplayCapabilityException will be thrown.

It is an error if the specified placement is not valid and an IllegalArgumentException will be thrown.

If the specified Command is currently associated with another placement of the Display it will be removed from that placement.

If there is a Command or Menu associated with the specified placement will be removed from the Displayable or Item which owns it.

Notes

  1. See here for a discussion of the issues surrounding some aspects of the semantics of this method.

  2. It is difficult to see under what circumstances a DisplayCapabilityException could be thrown by this method.

    If the current Display does not support Commands then

    1. if the Displayable had Commands when it was passed to the Display’s setCurrent(Displayable) method a DisplayCapabilityException would heve been thrown.

    2. if an attempt was made to add a Command to the Displayable once it was current on Display that did not support Commands then a DisplayCapabilityException would heve been thrown.

    To get to the point where it could happen the implementation would have had to deliberately call the onLayout(Displayable) method of the CommandLayoutPolicy object responsible for the Displayable knowing that

    1. the Display did not support Commands

    2. the Displayable did not have any associated Commands

    but this may actually be an implicit requirement

  3. The specification states that an IllegalArgumentException will be thrown if the placement argument

    is associated with a placement that does not support commands

    This and the documentation for Item.setCommand(Command, int) are the only places in the specification where it is suggested that a placement may not support Commands.

  4. The specification does not explicitly forbid the use of a Command which is also in a Menu.

6.8 Getting The Menu At A Specific Placement

The Menu associated with a specific placement can be obtained by calling a Displayable’s

    public Menu getMenu(int placement)

method.

It is an error if the specified placement is not valid and an IllegalArgumentException will be thrown.

If there is no Menu associated with the placement null will be returned.

Note

See the Note for the getCommand(int) method above


6.9 Placing A Menu

During the layout of a Displayable’s Commands a Menu can be associated with a specific placement using the Displayable’s

    public void setMenu(Menu menu, int placement)

method.

This is a layout only method.

It is an error if the current Display of the Displayable does not support Menus and a DisplayCapabilityException will be thrown.

It is an error if the specified placement is not valid or it does not support Menus and an IllegalArgumentException will be thrown.

The Command or Menu, if any, currently associated with the specified placement will be removed.

If the specified Menu is currently associated with another placement it will be removed from that placement.

Notes

  1. See here for a discussion of the issues surrounding some aspects of the semantics of this method.

  2. Presumably in the case of a Display which does not support Menus the DisplayCapabilityException will be thrown in preference to the IllegalArgumentException.

  3. The specification does not explictly preclude the use of a Menu which is a sub-Menu.


6.10 Removing A Command Or Menu From A Placement

During the layout of a Displayable’s Commands, a Command or Menu can be removed from a specific placement by calling the Displayable’s

    public void removeCommandOrMenu(int placement)

method.

This is a layout only method.

It is an error if the specified placement is not valid and an IllegalArgumentException will be thrown.

Note

  1. It is not clear from the specification what it means for a placement to be valid in this context. I would assume that it means that it must be an actual placement associated with the Displayable’s current Display.

  2. The behaviour if there is neither a Command or a Menu associated with the placement is not specified, but presumably it is a no-op, and this is certainly what the CommandLayoutPolicy example assumes.

7. Item Command Layout Support

7.1 Getting An Item’s Commands

The Commands currently associated with a Item can be obtained by calling the Item’s

    public Command[] getCommands()

method.

Note

  • The method documentation states that this method returns

    An array containing all commands added to the item via addCommand()

    If this is literally true then this method is going to return all the Commands ever added to the Item which is novel but pointless.

    Item also has a removeCommand(Command) method so we might hope that the effects of that might be taken into account as well.

    However, Item also has a setCommand(Command, int) method (see below) which

    Adds or sets a Command to the Item at the given placement.

    [emphasis added].

    In addition the documentation for both this method and the equivalent Displayable method
    states

    any Menu or Command already occupying the given placement will be removed from the associated Item or Displayable.

    If the set of Commands returned from the getCommands() method really is just the Commands added via addCommand(Command) and not subsequently removed via removeCommand(Command), then it still does not actually reflect the current state of the Item’s commands and it is effectively useless.

    This is especially true if we assume that one possible client of this method is a CommandLayoutPolicy object which wishes to obtain a list of the Item’s Commands that is is responsible for laying out. If it cannot obtain an accurate list using this method then it is going to have keep track of each Item’s Commands itself.

    In short, the getCommands() method is either not very useful or seriously underspecified.

7.2 Placing A Command

During the layout of a Displayable’s Commands an Item’s Command can be associated with a specific placement using the
Item’s

    public void setCommand(Command cmd, int placement)

method.

This is a layout only method.

A DisplayCapabilityException is throw in the current Display does not support Commands.

It is an error if the placement is not valid or it does not support Commands and an IllegalArgumentException will be thrown.

If the specified Command is currently associated with another placement it will be removed from that placement.

The Command or Menu, if any, currently associated with the specified placement will be removed from the Displayable or Item that owns it.

Notes

  1. As noted in the setCommand(Command,int) case these are the only two places in the specification where it is suggested that a placement might not support Commands

  2. As also noted in the setCommand(Command,int) case the possibility of a
    DisplayableCapabilityException is difficult to explain. In this case how does the Form containing the item can end up on a Displayable that does not support Commands if it contains Items that have Commands ?

8. Command Layout Issues

8.1 Lack Of An Explicit Model

Arguably the basic issue and the one from which the others follow is that there is no explict model of Command Layout and how it should work. Instead information is scattered through class and method documentation. This constitutes an implicit model of Command Layout but it is not an adequate substitute for a systematic definition of the concepts and functionality involved.

8.2 Adding And Removing Commands From A Displayable, Or What Exactly Does Displayable.getCommands() Return And Why ?

The single largest issue with the implicit model is the lack of a clear definition of what now constitutes the addition of a Command to, or the removal of a Command from, a Displayable.

Originally, pre MIDP 3, it was reasonably simple.

The Displayable.addCommand(Command) method documentation begins

Adds a command to the Displayable.

The Displayable.removeCommand(Command) method documentation begins

Removes a command from the Displayable.

That was it, ignoring the idiosyncracies of Alert. That was all it was possible to do. It wasn’t event possible to query the Displayable for it’s Commands.

In MIDP 3 there are new Displayable methods which also seem to add and remove Commands.

The Displayable.setCommand(Command, int) method

Adds or sets a Command to the Displayable at the given placement.

[Emphasis added]

and in doing so

any Menu or Command already occupying the given placement will be removed from the associated Item or Displayable.

[Emphasis added]

Then there is the Displayable.setMenu(Menu, int) method which

Adds or sets a menu to the Displayable at the given placement.

[Emphasis added].

and, just like the setCommand(Command, int) method

any Menu or Command already occupying the given placement will be removed from the associated Item or Displayable.

[Emphasis added].

There is also a new Item method setCommand(Command, int) which does not add a Command to a Displayable but like, Dispayable.setCommand(Command, int), and
Displayable.setMenu(Menu, int) it seems that it gets to remove them

any Menu or Command already occupying the given placement will be removed from the associated Item or Displayable.

[Emphasis added]

On that basis of the method documentation cited it is possible to construct reasonably plausible models of Displayables and Commands, and Displayables and Menus.

7.2.1 Displayables And Commands: A Model

  • a Displayable has a set of Commands, which may be empty

  • membership of a Displayable’s set of Commands is object identity based

  • a Command will be added to a Displayable’s set of Commands if it is not already a member, and it is either

    • passed as an argument to the Displayable’s addCommand(Command) method, or

    • passed as an argument to a valid call to the Displayable’s setCommand(Command, int) method with a valid placement

  • a Command will be removed from a Displayable’s set of Commands if it is currently a member, and it is either

    • passed as as an argument to the Displayable’s removeCommand(Command) method, or

    • currently associated with a placement, and that placement passed as an argument to a valid call to either

      • the Displayable’s setCommand(Command, int) method with a different Command

      • the Displayable’s setMenu(Menu, int) method

      or,

    • if the Displayable is a Form, and the Command is currently associated with a placement, and that placement is passed as
      an argument to a valid call to the setCommand(Command, int) method of an Item contained in the Form, or

    • if the Displayable is a TabbedPane, and the Command is currently associated with a placement, and that placement is either

      • passed to the current Tab’s setCommand(Command, int) method with a different Command, or

      • passed to the current Tab’s setMenu(Menu, int) method, or

      • passed to setCommand(Command, int) of an Item contained in the Form which is the current Tab, with a different Command
  • a Command cannot be added to a Displayable’s set of Commands if the Displayable’s current Display does not support Commands

  • a Displayable with a non-empty set of Commands cannot become current on a Display that does not support Commands

  • the Displayable.getCommands() method will return the Dispayable’s set of Commands

Note

  • the model does not include the special case behaviour for Alerts and FileSelectors

7.2.2 A Displayable Menus Model

  • a Displayable has a set of Menus, which may be empty

  • membership of a Displayable’s set of Menus is object identity based

  • a Menu will be added to a Displayable’s set of Menus if it is not already a member, and it passed as an argument to the
    Displayable’s setMenu(Menu, int) method with a valid placement

  • a Menu will be removed from a Displayable’s set of Menus is it is a member, and it is currently associated with a placement,
    and that placement is either

    • currently associated with a placement, and that placement passed as an argument to a valid call to either

      • the Displayable’s setCommand(Command, int) method with a different Command

      • the Displayable’s setMenu(Menu, int) method

      or,

    • if the Displayable is a Form, and the Menu is currently associated with a placement, and that placement is passed as
      an argument to a valid call to the setCommand(Command, int) method of an Item contained in the Form, or

    • if the Displayable is a TabbedPane, and the Menu is currently associated with a placement, and that placement is either

      • passed to the current Tab’s setCommand(Command, int) method with a different Command, or

      • passed to the current Tab’s setMenu(Menu, int) method, or

      • passed to setCommand(Command, int) of an Item contained in the Form which is the current Tab, with a different Command
  • a Menu cannot be added to a Displayable’s set of Menus if the Displayable’s current Display does not support Menus

  • a Displayable with a non-empty set of Menus cannot become current on a Display that does not support Menus

  • there is no way to programatically obtain the Dispayable’s set of Menus

Note

  • the model does not include the special case behaviour for FileSelectors

7.3 Other Issues

  • under what circumstances can a CommandLayoutPolicy object’s onLayout(Displayable) method get called for a given Displayable ?

  • when does Command layout occur relative to other Displayable and Display events ?

  • what state are a Display’s placements in when an onLayout(Displayable) method is called ?</p

  • are there any circumstances when an implememntation does not have to layout the Command’s of a Displayable that is current or about to become current on a Display

  • can a placement only support Menus ?

Appendix: Issues With The CommandLayoutPolicy Example

The following example (line numbers added) appears in the CommandLayoutPolicy class documentation.

1  class MyCanvas extends Canvas implements CommandLayoutPolicy {
2     MyCanvas() {
3       setCommandLayoutPolicy(this);
4     }
5
6     void sort(Command[] commands, int[] positions) {
7       // sort the commands in the correct order depending on the positions available.
8       // Implementation can use Display's getCommandPlacements to get the recommended 
9       // placement for each Command.
10    }
11 
12    public boolean onCommandLayout(Displayable displayable) {
13      Display display = displayable.getCurrentDisplay();
14      
15      final int border = Display.SOFTKEY_BOTTOM;
16     
17      int[] positions = display.getExactPlacementPositions(border);
18     
19      Command[] cmd = displayable.getCommands();
20     
21      sort(cmd, positions);
22     
23      if (cmd.length <= positions.length) {
24       
25        for (int i = 0; i < cmd.length; ++i) {
26          displayable.setCommand(cmd[i], border + positions[i]);
27        }
28        for (int i = cmd.length; i < positions.length; ++i) {
29          //clear all non-used placements
30          displayable.removeCommandOrMenu(border + positions[i]);
31        }
32      } else {
33       
34        for (int i = 0; i < positions.length - 1; ++i) {
35          displayable.setCommand(cmd[i], border + positions[i]);
36        }
37       
38        Menu options = new Menu("More", null, null);
39        for (int i = positions.length; i < cmd.length; ++i) {
40          options.append(cmd[i]);
41        }
42        displayable.setMenu(options, positions[positions.length-1]);
43      }    
44    }
45  }

At line 17 the return value of a call to the method Display.getExactPlacementPositions() is assigned to the variable positions. The method may return null. This is not tested for. If non-null then the return value is an array of placements, not indices. At lines 26, 30, and 35, the value of an element in positions is added to the value of border which is actually the constant Display.SOFTKEY_BOTTOM, and the result is then passed as a placement. In each case the placement will be invalid but only the first use at line 26 will be reached as an exception will then be thrown.

At line 42 an element of positions is passed directly as a placement to the method Display.setMenu(Menu,int) which is correct. However, calling the method without first checking whether the placement supports Menus is not.

And pedantically, at line 8 the comment mentions Display’s getCommandPlacements [method]. This should be Display’s getCommandPreferredPlacements method. And even more pedantically if the method is going to call a method on the current Display it will need to be passed either the Display or the Displayable.

Appendix: Working With Placements At Runtime

Obtaining the location or index of a placement requires the use of bit-wise AND and the constant SOFTKEY_INDEX_MASK
which is defined in the Display class.

Example

import javax.microedition.lcdui.Display;

...

    int placement = ...;
    int location  = placement & ~Display.SOFTKEY_INDEX_MASK;
    int index     = placement &  Display.SOFTKEY_INDEX_MASK;
	
...

Appendix: Placements And Display Orientation

Placements are relative to the current orientation of the Display which means that Command layout following an orientation change could be quite an interesting challenge.

Example

Assume a Display, initially in Portrait orientation, with two placements A and B on the left border and two placements, C and D, on the bottom border.

Example Placements: Portrait Orientation

In this orientation the available placements are

ID Border Index Placement
A Left 1 821
B Left 2 822
C Bottom 1 801
D Bottom 2 802

and Display.getExactPlacementPositions(int) returns

Border Return Value
SOFTKEY_TOP null
SOFTKEY_BOTTOM int[] { 801, 802 }
SOFTKEY_LEFT int[] { 821, 822 }
SOFTKEY_RIGHT null

Example Placements: Landscape Orientation

In this orientation the available placements are

ID Border Index Placement
A Top 2 842
B Top 1 841
C Left 1 821
D Left 2 822

and Display.getExactPlacementPositions(int) returns

Border Return Value
SOFTKEY_TOP int[] { 841, 842 }
SOFTKEY_BOTTOM null
SOFTKEY_LEFT int[] { 821, 822 }
SOFTKEY_RIGHT null

Example Placements: Portrait 180 Orientation

In this orientation the available placements are

ID Border Index Placement
A Right 2 862
B Right 1 861
C Top 2 842
D Top 1 841

and Display.getExactPlacementPositions(int) returns

Border Return Value
SOFTKEY_TOP int[] { 841, 842 }
SOFTKEY_BOTTOM null
SOFTKEY_LEFT null
SOFTKEY_RIGHT int[] { 861, 862 }

Example Placements: Landscape 180 Orientation

In this orientation the available placements are

<td2

ID Border Index Placement
A Bottom 1 801
B Bottom 2 802
C Right 2 862
D Right 1 861

and Display.getExactPlacementPositions(int) returns

Border Return Value
SOFTKEY_TOP null
SOFTKEY_BOTTOM int[] { 801, 802 }
SOFTKEY_LEFT null
SOFTKEY_RIGHT int[] { 861, 862 }

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

Advertisements

3 Comments »

  1. […] do not support Command layout and the following methods are all explicitly over-ridden and defined to throw an […]

    Pingback by What’s New In MIDP 3.0 ? Part 23; LCDUI – FileSelector « Just An Application — July 7, 2009 @ 10:49 am

  2. […] support Command layout. When a TabbedPane is displayed both Commands belonging to it, and to the Form or List in the […]

    Pingback by What’s New In MIDP 3.0 ? Part 24: LCDUI – TabbedPane « Just An Application — July 9, 2009 @ 11:04 am

  3. […] What’s New In MIDP 3.0: Redux – LCDUI – Command Layout Filed under: JME, Java, LCDUI, MIDP, MIDP3, MIDP3Issues, MIDP3LCDUI — Tags: Java, JME, JSR271, MIDP, MIDP3, MIDP3LCDUI, MIDP3SpecIssues — Simon Lewis @ 10:49 am Original Post […]

    Pingback by What’s New In MIDP 3.0: Redux – LCDUI – Command Layout « Just An Application — December 16, 2009 @ 10:49 am


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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: