探索J2ME：构建开销追踪系统

菜单命令

如图A所示，你可能会感到奇怪：程序清单A中的cmAdd和cmEditCommands 到底起了什么作用呢？为什么显示屏幕右边的Menu命令呢？显然， Expenses并没有创建它啊？原因是这样的，我给应用程序设置了软按钮之外更多的命令，应用程序管理器为此创建一个Menu命令用来访问其他命令。图C显示了调用Menu命令的结果。

图C

你如何知道哪些Commands 会对应专门的按钮，那些又对应菜单选项呢？好的，答案很简单，你不需要知道！命令组件的位置完全由平台的实现决定。而你则可以给Command构造器指定一个优先级作为最后一个参数，从而暗示某个Command对应某个专门的按钮。你设置的数值越低，应用程序管理器就越难于为Command.找到适当的专门按钮。因为cmExit的优先级被设为1，所以它算是搞到了真正的立足之地（按钮），而cmEdit和cmAdd的优先级分别是2 和3，结果就分配成了菜单选项。

事件处理

lcdui组件的事件模型和AWT、Swing所采用的事件处理系统是一样的。每一种类型的事件都具备表示事件的定义接口，组件调用接口上的给定方法把发生事件的情况报告给一个或者多个侦听器对象。你完全能想象得到，其差别无非是lcdui的事件处理系统相比之下得到了大大的简化。它只有几种事件需要处理，每一种组件一次都只能注册一个侦听器，只不过把 AWT组件内的addXListener改成了lcdui类的setXListener。

Expenses关心两种类型的事件：commandAction和 itemStateChange。commandAction事件发生在用户调用Command或者选择List.中项目的时候。另一方面，itemStateChange则在用户通过Item组件改变显示数据的时候触发。因为Expenses并没有包含任何产生itemStateChange事件的组件（将来会涉及到），所以我们略过其内容而仅仅关注于commandAction。

命令性能

实现CommandListener接口的类会接收组件发出的事件通知。而这些组件则通过接口的commandAction方法调用setCommandListener向接口注册。我把Expenses的commandAction方法有关的代码放到了程序清单B中，从中你可以看到应用程序的事件处理真是够简单的。方法由发出事件通知的对象变量实例接手，我检查该变量决定需要采取的行动。

事件列表

lsMain组件是一种implicit list，它还可以产生commandAction事件。确定某一事件是否来自某个List组件这个工作是通过比较传递给commandAction的Command实例和静态常量List.SELECT_COMMAND来实现的。就Expenses而言，lsMain命令的行为等同于cmEdit命令的行为：两者都会触发编辑所选的开销项目。

说了半天口水都快干了。下次我们会建立一个更复杂些的表单，它提供了添加/编辑功能，同时用到了若干个Item组件。