一、序言
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
手持设备的用户接口编程不同于桌面微机编程。例如，手持设备的显示尺寸要小，显示设备并不总是包括点击工具如鼠标和笔。由于这些原因，在手持设备的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间的关系
