MIDlet API 2.0学习之：javax.microedition.lcdui （二）
Device-Provided Operations

在许多高级UI类中都会有一些在用户界面可用的附加的操作。这些附加操作对于应用程序来说是不可见的，只对最终用户开发。这个操作集的可用性完全依赖于特定设备的UI设计。例如：在有ITU-T小键盘的设备需要一个允许让用户改变在字母和数字间文本输入模式的操作。更复杂的输入系统需要额外的操作。最终用户不需要明白哪个操作是由系统提供哪个是由应用程序提供。不是所有操作在每个具体实现的应用程序里都是可用的。例如：一个有字联想文本输入模式的系统通常会提供在TextBox类中的附件操作。没有这种文本输入的系统就不会有类似的操作。

一些操作在所受设备上都是可用的，但是这些操作的实现方式在不同设备上会有很大差别。这种操作的例子是：List元素和Form项之间的导航机制、List元素的选择方式、一个文本编辑器中移动输入位置等等。一些设备不允许对Item的值的直接修改，但是可以让用户切换到画面以外的编辑器来实现这种修改操作。List元素的选择可以像这个例子：用专用的“Go”或“Select”或一些其它的键来实现。有些设备没有专用的选择键，当需要选择时需要用其它方式。

在使用一个专用选择键来完成选择操作的设备上，这个键不会经常需要一个lable来显示它。在任何键意义明显的情况下，这种程序实现都能准确的使用这个键。例如：如果用户使用一个相互独立的选项集合，这个选择键会明显地选择这些选项中的一项。如果一个设备内没有一个专用的键，那么它可能会用一个需要lable的软按键来完成这个选择操作。系统提供为IMPLICIT类型的List设置一个select-command的能力和为一个Item设置default Command的能力因此应用程序可以为这个操作设置lable，从而应用可以在操作触发时受到通知。

High-Level API for Events

高级API的事件处理是基于一个监听模型的。Screens和Canvases会拥有Command的监听器。一个监听器对象必须实现一个CommandListener接口，该接口有一个方法：
void commandAction(Command c, Displayable d);

如果Screen和Canvas已经绑定了Command并有一个注册了的监听器，那么这个应用就可以得到这些事件。如果应用采用了单一监听模型（unicast-version of the listener model），那么Screen和Canvas只能在同一时刻有一个监听器。

Form中的Item也有一个状态改变的坚挺接口。定义在接口ItemStateListener的方法void itemStateChanged(Item item)在当一个交互的Gauge、ChoiceGroup或TextField的值改变时被调用。在每个状态改变之后都调用监听器是不可预计的。如果一个Item的值已经被改变，这个监听器会在它为其它Item调用或一个Command被传递到Form的CommandListener之前某个时候为这个改变调用。建议状态改变监听器至少在Form字段失去焦点时被调用。监听器只会在字段值真正被改变时调用。

Low-Level API for Events

低级图形和事件有如下方法来处理低级按键事件：

    class MyClass extends Canvas        implements Runnable {                    void doStuff() {            // <code fragment 1>            callSerially(this);        }        // called only after all pending repaints served            public void run() {            // <code fragment 2>;        }    }

Implementation Notes

List或ChoiceGroup的实现会包含键盘快捷方式来聚焦和选择选项元素，但是这些快捷方式对应用程序是不可见的。

在某些UI组件的实现中 -- Screen 和 Item -- 会基于本地组件。当Java对象不再需要时的释放过期资源的操作取决与该实现。一个可行的实现场景是和KVM的垃圾回收器挂钩。