一、序言

手持设备的用户接口编程不同于桌面微机编程。例如，手持设备的显示尺寸要小，显示设备并不总是包括点击工具如鼠标和笔。由于这些原因，在手持设备的gui编程时，我们不可能遵循与台式微机编程gui同样的规则。

cldc本身并没有定义任何的gui功能。代之的是，j2me的官方gui类用象midp这样的轮廓文件所描述，并由java社团组织定义。你可能注意到在midp中描述的gui类不是基于awt的，这似乎存在很大问题。请往下看。

二、为什么不重用awt？

经过相当的考虑之后，midp专家组决定不再重用已有的awt和swing类。原因如下:

?awt是为桌面微机开发的，并为这种情形作了优化处理。

?awt设定了某些用户交互模式。awt的组成当中考虑到了如鼠标等的点指设备，但是许多手持设备，如手机等，只有键盘用于输入。

?awt具丰富的特性，包括在手持设备上还不能实现的。例如，awt为窗口管理提供广泛支持，如窗口大小与重叠调用。然而，有限的手持设备的显示空间，使得它上面的窗口调整根本不可能实现。所以，手持设备是用不到awt的窗口布局管理器的。

?当用户与基于awt的应用程序交互时，甚至对象是动态创建的。这些对象仅在与之相关的事件被应用程序或系统处理时--此时，这些对象对于垃圾回收器来说是有效的--这些对象才存在。但是手持设备有限的cpu和内存无法承担如此重任。

三、midp gui api

基于以上原因，midp创建了它自己的简短的gui，其与awt存在相当的不同。midp gui包含了低级的和高级的api两类，这两类aip各有自己的事件集。本文将讨论并演示通过这两类api来使用对象的例子。通过api操纵事件在下一章中介绍。

高级的api主要应用在移动设备开发特别注重移植性的情况下。为了保证可移植性，api进行了高级抽象，因此给予用户在控件的外观和感觉上极少的控制。例如，你没法定义一个高级组件的可视化外观(形状，颜色或者字体)。大多数与组件的交互由系统实现体所封装；应用程序不必在乎它们。因此，底层的实现上为适应于硬件和本机用户接口风格作了必要的调整。实现了高层api的类全部继承自javax.microedition.lcdui.screen类。

而低层api作了很少的抽象处理。该设计用于要求对图形元素进行精确控制的场所，这时应用程序还可以对低层输入事件进行存取。这一类api使得应用程序可以对在屏幕上显示的内容进行精确的控制。javax.microedition.lcdui.canvas和javax.microedition.lcdui.graphics类实现该低层api。但是，应该明确指出，无法保证存取低层api的midlets程序是可移植的，因为这种api提供了存取特定设备的细节操作。

1、midp gui模型

下面是midp gui在内核上如何工作的一个模型。为在某midp设备上进行显示，你需要取得该设备的display，这是由javax.microedition.lcdui.display类来描述的。类display是唯一的显示管理器，当用于每一个活动的midlet时被实例化，并提供方法以检索有关该设备显示能力的信息。

获取设备的显示信息是很容易的。但是，对象本身并不令人感兴趣。而更令人感兴趣的抽象是screen，它封装和组织图形对象并协调通过设备的用户输入。screen由javax.microedition.lcdui.screen对象来描述并由display 对象调用setcurrent( )方法显示。一个应用程序中可有多个screen，但是在某一时刻只有一个screen在屏幕上是可见的(当前的这一个)，用户只能遍历在这一个screen上的项。图1显示了在display与它的可能的多个screen之间的一对多的关系。

图1.display与screens间的关系

在midp gui中共有三种类型的screen:

?完全封装了复杂用户接口组件(如list：下图2或者textbox：下图3)的screen。这些screen的结构是预定义好的，应用程序不能把其它组件添加到这些screen上。

图2.一组互斥的选择项

图3.一个文本框的例子

?使用表单组件的普通screen。应用程序可以把文本框，图像及一些简单的相关联的ui组件到表单上，此时表单起容器作用。

?在低层api使用的screen，如一个canvas或者graphics对象的子类。

2、lcdui包

所有的midp gui类都包含在包javax.microedition.lcdui中。该包包含了3个接口和21个类，详见表1和表2。

表 1: lcdui接口

下图显示其中的主要类及其之间的关系。

图 4.包中的主要类之间的类关系图