一、序言
手持设备的用户接口编程不同于桌面微机编程。例如，手持设备的显示尺寸要小，显示设备并不总是包括点击工具如鼠 标和笔。由于这些原因，在手持设备的GUI编程时，我们不可能遵循与台式微机编程GUI同样的规则。
CLDC本身并没有定义任何的GUI功能。代之的是，J2ME的官方GUI类用象MIDP这样的轮廓文件所描述，并由JAVA 团 组织定义。你可能注意到在MIDP中描述的GUI类不是基于AWT的，这似乎存在很大问题。请往下看。
二、为什么不重用AWTb>
经过相当的考虑之后，MIDP专家组决定不再重用已有的AWT和Swing类。原因如下:
·AWT是为桌面微机开发的，并为这种情形作了优化处理。
·AWT设定了某些用户交互模式。AWT的组成当中考虑到了如鼠标等的点指设备，但是许多手持设备，如手机等，只有键 盘用于输入。
·AWT具丰富的特性，包括在手持设备上还不能实现的。例如，AWT为窗口管理提供广泛支持，如窗口大小与重叠调用。 然而，有限的手持设备的显示空间，使得它上面的窗口调整根本不可能实现。所以，手持设备是用不到AWT的窗口布局管理器的。
·当用户与基于AWT的应用程序交互时，甚至对象是动态创建的。这些对象仅在与之相关的事件被应用程序或系统处理时 –此时，这些对象对于垃圾回收器来说是有效的–这些对象才存在。但是手持设备有限的CPU和内存无法承担如此重任。
三、MIDP GUI 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之间的一对多的关系。
图2.一组互斥的选择项
图 4.包中的主要类之间的类关系图
文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览93576 人正在系统学习中
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！