Commands
are abstract operations that give
mobile device user the means to interact and navigate within the application.
In LCDUI, the placement of Commands
added to
a Displayable
is completely up to the device
implementation unless explicitly overridden by the application. LCDUI
features a number of different Command
types
that define how and where the implementation places them. For example,
the 'negative' (BACK
, CANCEL
, EXIT
) Command
is commonly
mapped to the left softkey.
In other words, when you design user interfaces consisting only
of high-level APIs and Commands
, the platform
handles the construction of all option menus and the collection of
user input as long as the MIDlet implements the correct requirements.
In Series 40, Commands
are mapped directly to a softkey
or placed in an expandable menu (the common Options menu) according
to Nokia user interface guidelines. It is essential to use logically
proper and correct types for Commands
. If right
types for the Commands
are used, the Command
mapping works as expected.
The placement of Commands
in the UI is decided
by assigning them a Command
type and a priority
value. The order of Commands
s of the same type
is handled with the priority value. A Command
that has been assigned the smaller priority value is placed before
the other Command
s of the same type in a menu.
When Commands
are presented in Options
menu, the Commands
mapped to the menu are shown
in the following order based on their type:
Native software
UI element operations (for example internal selection element in ChoiceGroup
)
Default Item
Command
Item Commands
STOP
OK
CANCEL
ITEM
SCREEN
HELP
BACK
EXIT
Automatically
added ‘View’ in ChoiceGroups
and Lists
which are truncated due to text wrap being off.
Automatically
added ‘am’ and ‘pm’ in time entry DateFields
when the clock is set to 12 hour mode.
In cases where the priority of similar Command
types is the same, the ordering is based on the order the Commands
were programmatically added to the Displayable
.
Command
s can be divided into four categories:
Displayable
Commands
(normal Commands
) are associated with a Displayable
object.
Item
Commands
are associated with individual Form
Items
. Item
Commands
are used to display context sensitive menus and are available only
when the corresponding Item
has focus.
Default Command
in a Form
Item
aims to make one Command
easy to access. Default Commands
are associated
with a Form
Item
object
with setDefaultCommand()
method. Default Command
is invoked directly with the Selection key.
Device-provided operations are Commands
provided by the implementation for certain type of elements without
application programmer’s intervention. The Commands
are used to provide access to device functionality otherwise not
accessible.
Commonly, every Command
is associated with
a Displayable
or a Form
Item
. Commands
can generally be applied to any screen, including Alerts
.
Since Commands
control the basic UI navigation
functions of a MIDlet, you must always add an EXIT Command
to the MIDlet, so that the user can exit the MIDlet gracefully.
If the MIDlet UI uses one or more views in addition to the main view,
consider adding an EXIT Command
to all the views.
You must also add the necessary backstepping Command
(either CANCEL or BACK) to each additional view, so that the user
can always return to the previous view in the UI.
If a CommandListener
method does not return
or is not delayed, the system may be blocked. Therefore, the CommandListener
method should return immediately.
Command
s mapped to softkeys
conform to the following rules:
Softkey 1 (left softkey)
Multiple Commands
can be mapped to the left softkey. If there are
multiple Commands
, an Options
label is presented on the left softkey and selecting it opens a
menu of commands. If there is only a single 'positive' Command
(OK, ITEM, SCREEN,
or HELP
), it is presented directly on the left softkey. If there is more
than one 'negative' Command
, they are presented
in the Options
menu that is accessed with the
left softkey.
Softkey 2 (right softkey)
There can only
be one 'negative' Command
(STOP, CANCEL,
BACK,
or EXIT)
mapped to the right
softkey, and the Command
mapped there is directly
invoked by the softkey press. If there are multiple 'negative' Commands
, the one that has the highest priority value
is mapped to the right softkey and the rest are placed in the menu
of commands under the left softkey.
Selection key (formerly middle softkey)
In Series 40, only a single context sensitive Command
(OK, ITEM
) is mapped to the selection key.
If there's only a single Command
, it is shown
directly in softkey, otherwise the Commands
are
visible in a context sensitive menu that can be opened with the Selection
key.
Note: Some UI elements override this rule and place an
element-specific operation directly to the Selection key. For example, POPUP ChoiceGroup
has Open
operation
in the Selection key.
Enter key (on QWERTY keyboard)
Has the same effect as the Selection key, unless it is bound to a displayable specific operation.
The behavior that the command activates is not encapsulated
in the specific object. This means that when the mobile device user
invokes a Command
, the actual functionality is
not executed automatically by the implementation. Instead, the action
is defined in a CommandListener
interface.
Application specified Command
labels are used:
as a label in the softkey to which the Command
was mapped (in case where only one Command
is
mapped to a specific softkey).
as a label in the Options or context sensitive menu item (in
case where more than one Command
is mapped to
a softkey).
Command Type |
Default Placement |
Default Command label |
---|---|---|
STOP |
Right softkey |
Stop |
OK |
Selection key |
Ok |
CANCEL |
Right softkey |
Cancel |
ITEM |
Selection key |
Select |
SCREEN |
Selection key |
Select |
HELP |
Selection key |
Help |
BACK |
Right softkey |
Back |
EXIT |
Right softkey |
Exit |
For information about supported new line character combinations, see section New line handling.
If a Command
is added or removed after the Command
s for
a displayable have been presented to the user, all the Command
s are mapped again based on the rules presented in the previous sections.
This may update the softkey labels and Command
labels in the Options menu even when they are visible.
On
Form, addition or removal of Command
s may be
performed by both the implementation and the MIDlet, as the user traverses
different Items, since each Item
may have its
own specific Commands
. This may result in scenarios
where sometimes a particular Command
is displayed
on the left softkey, while at other times "Options" is displayed.
If another Displayable
appears over the Options
list while it is open (by a system application
or by the MIDlet itself), then upon that Displayable
’s removal the user will not be returned to the options list.
In the full
touch UI, the header bar is displayed below the status bar and shows
the title of the current view. The header bar contains placeholders
for two action buttons to which Commands
and IconCommands
can be mapped:
Action button 1 is positioned to the right
of the view title and functions as the primary action button. It displays
the highest-priority positive command. You can define a custom icon
for the command by using an IconCommand
.
Action button 2 is positioned to the left of the view title and always shows an options icon. Selecting it opens the list of remaining commands (assuming any are available).
Figure: Action buttons in the header bar
For more information about the main elements of the full touch UI, see section Full touch devices.
The following table
lists the various scenarios of how commands are mapped to the action
buttons and the Back button. The scenarios only apply to commands
added to Canvas
or Form
elements.
Scenario |
Action button 1 |
Action button 2 (options) |
Back button |
---|---|---|---|
If there is only one positive command ( |
If an icon is specified, the positive command is mapped to action button 1. Note: Any positive |
If no icon is specified, the positive command is mapped to action button 2. Note: Only commands of type If there are no additional commands to display other than action button 1, action button 2 is displayed as dimmed and inactive. |
The Back button is not visible. |
If there is only one negative command ( |
Action button 1 is not visible. |
If the negative command is of type |
If the negative command is of type If there is a negative command
of type |
If there is one negative command and one positive command. |
If an icon is specified, the positive command is mapped to action button 1. |
If no icon is specified, the positive command is mapped to action button 2. Negative commands (with the exception of
a |
If the negative command is of type If there is a negative command
of type |
If more than two commands are present (positive or negative). |
If an icon is specified, the highest-priority positive command is mapped to action button 1. |
All other positive commands are mapped to action button 2. Negative commands (with the exception of a |
If the negative command is of type If there is a negative command
of type |
If there is a command of type |
The command is mapped to action button 1 and the default icon of a tick will be displayed. |
Action button 2 is displayed as dimmed and inactive. |
|
If there is only one action defined, the command type is
not |
Action button 1 is not visible. |
The command is mapped to action button 2. |
|
If there are no additional commands to display other than action button 1 and the Back button. |
Action button 1 is visible. |
Action button 2 is displayed as dimmed and inactive. |
The Back button is visible. |
Commands within a command list are shown in the following order:
Any STOP
commands
Any OK
commands
Any CANCEL
commands
Any FORM ITEM
commands
Any SCREEN
commands
Any HELP
commands
Any EXIT
commands
UI element operations and item-specific commands are only accessible by a long tap. If there is more than one of any type of command, within each command type group placement, the individual commands are ordered according to the general rules specified above.
In Nokia
Asha software platform devices, up to four IconCommands
can be mapped to CategoryBar
.
Note:
IconCommands
can also be added to Displayable. However,
in such cases only their text labels will be visible.Figure: IconCommands in CategoryBar and Commands in Options menu
In Nokia Asha software platform devices, Commands
are mapped to Options menu. The first Command
(by priority) is shown on the bottom of the screen as a button within
the Toolbar. All the other Commands
are listed in
the Options menu.
Note: If CategoryBar is visible, then Commands
attached to the current Displayable (not in CategoryBar
) are mapped to Options menu, as CategoryBar
covers the single command at the bottom of the screen.
The Options menu should contain functions related to the current view, and is presented as a textual list. It is initially hidden in the view, and an indicator is displayed when it is available. The Options menu is accessed by swiping up from bottom of the screen.
Commands
in Options menu are shown in the order
of their priority. Commands of the same priority are shown in the
following order:
Any ITEM
commands
Any STOP
commands
Any CANCEL
commands
Any EXIT
commands
Any BACK
commands
Any HELP
commands
Any OK
commands
Any SCREEN
commands
Item-specific Commands
should use Command.ITEM
type. If there is more than one of any type
of Command
, within each Command
type
group placement, the individual Commands
are ordered
according to the general rules specified above. The order of Commands
of the same type is done based on the Commands
’ priority numbers.
On both Series 40 and Nokia Asha software
platform devices, tapping outside the Options Menu closes the Menu.
If the Options Menu contains more Commands
than can
fit in its visible area, dragging or flicking the Menu, scrolls through
the items. On Series 40 touch and type devices, no scrollbar is shown,
regardless of whether the menu needs scrolling. On Series 40 full
touch the scrollbar is visible upon the launch of the Options Menu,
and it is hidden upon inactivity and is brought back to the foreground
when the user drags or flicks the list of available Commands
. On Nokia Asha software platform devices, the scrollbar in Options
Menu is always visible.
In Nokia Asha software platform devices, the back key is a hardware button located under the display.
The back key works as follows:
Pressing back key in home screen, toggles between two home screens (activity screen and apps screen).
Pressing back key in application view, takes back to previous UI state.
Pressing and holding back key in any view will close current view and directly go to previously visited home screen.
Pressing back key when both BACK and EXIT Commands
are added to Displayable, the BACK Command
takes
precedence.
The BACK and EXIT Commands
when implemented in a MIDlet make the back key
to work as follows:
If Displayable has EXIT Command
implemented,
but not BACK Command
, pressing back key closes the
MIDlet.
If Displayable has BACK Command
implemented,
pressing back key handles the BACK Command
.
If Displayable has BACK and EXIT Commands
implemented,
BACK Command
is mapped to the Back key and EXIT Command
is mapped to the Options menu.
If EXIT Command
is mapped to the back key,
it is normally handled by using commandAction()
method
(it is possible, for example, to show confirmation dialog before exiting).
Note: The MIDlet is closed by pressing the back key, even if the EXIT
Command
is not implemented. The MIDlets
can also be closed by swiping horizontally across the screen.This example illustrates how Commands
are mapped to the Options menu and the Toolbar on Nokia Asha software
platform devices Commands
in this example are
used to insert a short string to a TextBox
or
to exit the MIDlet. Note how the priority setting affects the order
of Commands
in the left softkey. The EXIT Command
is also placed under the right softkey, but
is covered by the default Cancel
text when the
left softkey menu is open.
Figure: An example showing Commands mapped to softkeys
Source code for the example:
import javax.microedition.midlet.*; import javax.microedition.lcdui.*; public class ExampleCommand extends MIDlet implements CommandListener { private Display display; private TextBox textbox; private Command apple; private Command orange; private Command pear; private Command lemon; private Command exit; private Command clear; public ExampleCommand() { display = Display.getDisplay(this); apple = new Command("Apple", Command.SCREEN, 1); orange = new Command("Orange", Command.SCREEN, 4); pear = new Command("Pear", Command.SCREEN, 2); lemon = new Command("Lemon", Command.SCREEN, 3); exit = new Command("Exit", Command.EXIT, 1); clear = new Command("Clear", Command.SCREEN, 5); textbox = new TextBox("Today's menu:", "The command you select will be presented here", 100, TextField.ANY); textbox.addCommand(exit); textbox.addCommand(apple); textbox.addCommand(orange); textbox.addCommand(pear); textbox.addCommand(lemon); textbox.addCommand(clear); textbox.setCommandListener(this); } public void startApp() { display.setCurrent(textbox); } public void pauseApp() { } public void destroyApp(boolean unconditional) { } public void commandAction(Command command, Displayable displayable) { if (command == apple) { textbox.setString(apple.getLabel() + " selected"); } else if (command == orange) { textbox.setString(orange.getLabel() + " selected"); } else if (command == lemon) { textbox.setString(lemon.getLabel() + " selected"); } else if (command == pear) { textbox.setString(pear.getLabel() + " selected"); } else if (command == clear) { textbox.setString(""); } else if (command == exit) { destroyApp(false); notifyDestroyed(); } } }
Command
see: