A superclass for components that can be added to a {@link Form
Form}. All Item objects have a label field,
which is a string that is
attached to the item. The label is typically displayed near the component
when it is displayed within a screen. The label should be positioned on
the same horizontal row as the item or
directly above the item. The implementation should attempt to distinguish
label strings from other textual content, possibly by displaying the label
in a different font, aligning it to a different margin, or appending a
colon to it if it is placed on the same line as other string content.
If the screen is scrolling, the implementation should try
to keep the label visible at the same time as the Item.
In some cases,
when the user attempts to interact with an Item,
the system will switch to
a system-generated screen where the actual interaction takes place. If
this occurs, the label will generally be carried along and displayed within
this new screen in order to provide the user with some context for the
operation. For this reason it is recommended that applications supply a
label to all interactive Item objects. However, this is not required, and
a null value for a label is legal and specifies
the absence of a label.
Item Layout
An Item's layout within its container is
influenced through layout directives:
-
LAYOUT_DEFAULT
-
LAYOUT_LEFT
-
LAYOUT_RIGHT
-
LAYOUT_CENTER
-
LAYOUT_TOP
-
LAYOUT_BOTTOM
-
LAYOUT_VCENTER
-
LAYOUT_NEWLINE_BEFORE
-
LAYOUT_NEWLINE_AFTER
-
LAYOUT_SHRINK
-
LAYOUT_VSHRINK
-
LAYOUT_EXPAND
-
LAYOUT_VEXPAND
-
LAYOUT_2
The LAYOUT_DEFAULT directive indicates
that the container's default
layout policy is to be used for this item.
LAYOUT_DEFAULT has the value
zero and has no effect when combined with other layout directives. It is
useful within programs in order to document the programmer's intent.
The LAYOUT_LEFT, LAYOUT_RIGHT, and
LAYOUT_CENTER directives indicate
horizontal alignment and are mutually exclusive. Similarly, the
LAYOUT_TOP, LAYOUT_BOTTOM, and
LAYOUT_VCENTER directives indicate vertical
alignment and are mutually exclusive.
A horizontal alignment directive, a vertical alignment directive, and
any combination of other layout directives may be combined using the
bit-wise OR operator (|) to compose a
layout directive value. Such a value
is used as the parameter to the {@link #setLayout} method and is the return
value from the {@link #getLayout} method.
Some directives have no defined behavior in some contexts. A layout
directive is ignored if its behavior is not defined for the particular
context within which the Item resides.
A complete specification of the layout of Items
within a Form is given
here.
Item Sizes
Items have two explicit size concepts: the minimum
size and the
preferred size. Both the minimum and the preferred sizes refer to
the total area of the Item, which includes space for the
Item's contents,
the Item's label, as well as other space that is
significant to the layout
policy. These sizes do not include space that is not significant for
layout purposes. For example, if the addition of a label to an
Item would
cause other Items to move in order to make room,
then the space occupied by
this label is significant to layout and is counted as part of
the Item's
minimum and preferred sizes. However, if an implementation were to place
the label in a margin area reserved exclusively for labels, this would not
affect the layout of neighboring Items.
In this case, the space occupied
by the label would not be considered part of the minimum and preferred
sizes.
The minimum size is the smallest size at which the
Item can function and
display its contents, though perhaps not optimally. The minimum size
may be recomputed whenever the Item's contents changes.
The preferred size is generally a size based on the
Item's contents and
is the smallest size at which no information is clipped and text wrapping
(if any) is kept to a tolerable minimum. The preferred size may be
recomputed whenever the Item's contents changes.
The application can
lock the preferred width or preferred height (or both) by
supplying specific values for parameters to the {@link #setPreferredSize
setPreferredSize} method. The manner in which an
Item fits its contents
within an application-specified preferred size is implementation-specific.
However, it is recommended that textual content be word-wrapped to fit the
preferred size set by the application. The application can unlock
either or both dimensions by supplying the value -1
for parameters to the setPreferredSize method.
When an Item is created, both the preferred width
and height are
unlocked. In this state, the implementation computes the preferred width
and height based on the Item's contents, possibly
including other relevant
factors such as the Item's graphic design and the
screen dimensions.
After having locked either the preferred width or height, the application
can restore the initial, unlocked state by calling
setPreferredSize(-1, -1).
The application can lock one dimension of the preferred size and leave
the other unlocked. This causes the system to compute an appropriate value
for the unlocked dimension based on arranging the contents to fit the
locked dimension. If the contents changes, the size on the unlocked
dimension is recomputed to reflect the new contents, but the size on the
locked dimension remains unchanged. For example, if the application called
setPreferredSize(50, -1), the preferred width would be
locked at 50 pixels and the preferred height would
be computed based on the
Item's contents. Similarly, if the application called
setPreferredSize(-1, 60), the preferred height would be
locked at 60 pixels and the preferred width would be
computed based on the
Item's contents. This feature is particularly useful
for Items with
textual content that can be line wrapped.
The application can also lock both the preferred width and height to
specific values. The Item's contents are truncated or padded
as necessary to honor this request. For Items containing
text, the text should be wrapped to the specified width, and any truncation
should occur at the end of the text.
Items also have an implicit maximum size provided by the
implementation. The maximum width is typically based on the width of the
screen space available to a Form. Since Forms
can scroll vertically, the maximum height should typically not be based on
the height of the available screen space.
If the application attempts to lock a preferred size dimension to a
value smaller than the minimum or larger than the maximum, the
implementation may disregard the requested value and instead use either the
minimum or maximum as appropriate. If this occurs, the actual values used
must be visible to the application via the values returned from the
{@link #getPreferredWidth getPreferredWidth} and
{@link #getPreferredHeight getPreferredHeight} methods.
Commands
A Command is said to be present on an Item
if the Command has been
added to this Item with a prior call to {@link #addCommand}
or {@link #setDefaultCommand} and if
the Command has not been removed with a subsequent call to
{@link #removeCommand}. Commands present on an
item should have a command
type of ITEM. However, it is not an error for a
command whose type is
other than ITEM to be added to an item.
For purposes of presentation and
placement within its user interface, the implementation is allowed to
treat a command's items as if they were of type ITEM.
Items may have a default Command.
This state is
controlled by the {@link #setDefaultCommand} method. The default
Command is eligible to be bound to a special
platform-dependent user
gesture. The implementation chooses which gesture is the most
appropriate to initiate the default command on that particular
Item.
For example, on a device that has a dedicated selection key, pressing
this key might invoke the item's default command. Or, on a
stylus-based device, tapping on the Item might
invoke its default
command. Even if it can be invoked through a special gesture, the
default command should also be invokable in the same fashion as
other item commands.
It is possible that on some devices there is no special gesture
suitable for invoking the default command on an item. In this case
the default command must be accessible to the user in the same
fashion as other item commands. The implementation may use the state
of a command being the default in deciding where to place the command
in its user interface.
It is possible for an Item not to have a default command.
In this
case, the implementation may bind its special user gesture (if any)
for another purpose, such as for displaying a menu of commands. The
default state of an Item is not to have a default command.
An Item
may be set to have no default Command by removing it from
the Item or
by passing null to the setDefaultCommand()
method.
The same command may occur on more than one
Item and also on more than
one Displayable. If this situation occurs, the user
must be provided with
distinct gestures to invoke that command on each Item or
Displayable on
which it occurs, while those Items or Displayables
are visible on the
display. When the user invokes the command, the listener
(CommandListener
or ItemCommandListener as appropriate) of just the
object on which the
command was invoked will be called.
Adding commands to an Item may affect its appearance, the
way it is laid out, and the traversal behavior. For example, the presence
of commands on an Item may cause row breaks to occur, or it
may cause additional graphical elements (such as a menu icon) to appear.
In particular, if a StringItem whose appearance mode is
PLAIN (see below) is given one or more Commands,
the implementation is allowed to treat it as if it had a different
appearance mode.
Appearance Modes
The StringItem and ImageItem classes have an
appearance mode attribute that can be set in their constructors.
This attribute can have one of the values {@link #PLAIN PLAIN},
{@link #HYPERLINK HYPERLINK}, or {@link #BUTTON BUTTON}.
An appearance mode of PLAIN is typically used
for non-interactive
display of textual or graphical material. The appearance
mode values do not have any side effects on the interactivity of the item.
In order to be interactive, the item must have one or more
Commands
(preferably with a default command assigned), and it must have a
CommandListener that receives notification of
Command invocations. The
appearance mode values also do not have any effect on the semantics of
Command invocation on the item. For example,
setting the appearance mode
of a StringItem to be HYPERLINK
requests that the implementation display
the string contents as if they were a hyperlink in a browser. It is the
application's responsibility to attach a Command
and a listener to the
StringItem that provide behaviors that the user
would expect from invoking
an operation on a hyperlink, such as loading the referent of the link or
adding the link to the user's set of bookmarks.
Setting the appearance mode of an Item to be other than
PLAIN may affect its minimum, preferred, and maximum sizes, as
well as the way it is laid out. For example, a StringItem
with an appearance mode of BUTTON should not be wrapped across
rows. (However, a StringItem with an appearance mode of
HYPERLINK should be wrapped the same way as if its appearance
mode is PLAIN.)
A StringItem or ImageItem
in BUTTON mode can be used to create a
button-based user interface. This can easily lead to applications that are
inconvenient to use. For example, in a traversal-based system, users must
navigate to a button before they can invoke any commands on it. If buttons
are spread across a long Form, users may be required
to perform a
considerable amount of navigation in order to discover all the available
commands. Furthermore, invoking a command from a button at the
other end of the Form can be quite cumbersome.
Traversal-based systems
often provide a means of invoking commands from anywhere (such as from a
menu), without the need to traverse to a particular item. Instead of
adding a command to a button and placing that button into a
Form, it would
often be more appropriate and convenient for users if that command were
added directly to the Form. Buttons should be used
only in cases where
direct user interaction with the item's string or image contents is
essential to the user's understanding of the commands that can be invoked
from that item.
Default State
Unless otherwise specified by a subclass, the default state of newly
created Items is as follows:
- the
Item is not contained within
("owned by") any container;
- there are no
Commands present;
- the default
Command is null;
- the
ItemCommandListener is null;
- the layout directive value is
LAYOUT_DEFAULT; and
- both the preferred width and preferred height are unlocked.
| 