使Java代码可移植之二

核心提示：本文内容摘自即将出版的《Symbian OS J2ME编程指南》一书，关于本书的具体介绍请访问：http://www.china-pub.com/computers/common/info.asp?id=255386.3 移植问题这一节讨论一系列特定的移植问题，使Java代码可移植之二，涉及UI（包括低级图像和高级U

本文内容摘自即将出版的《Symbian OS J2ME编程指南》一书，关于本书的具体介绍请访问：http://www.china-pub.com/computers/common/info.asp?id=25538　

6.3  移植问题

这一节讨论一系列特定的移植问题，涉及UI（包括低级图像和高级UI组件）、可选的和第三方API以及下载大小限制。

为了创建能在一系列不同类型和功能的设备上运行的MIDlet，在MIDlet运行期间，识别设备的性能是非常有用的，这样它就能动态改变其行为，或者在提供MIDlet时，服务器能发送一个恰当的经过裁剪的JAR文件。

支持设备的运行期识别也是相当有限的：我们能使用System.getPRoperty()来识别JTWI或MIDP版本，并且我们可以使用Canvas.getHeight()、Canvas.getWidth()、Canvas.isDoubleBuffered，Display.isColor()和Display.numColors()来识别显示能力。

当前，当下载一个应用程序时，通常让用户点击手机上的链接来（例如，“BoyRacer for Sony EriCSSon P800/P900”或“BoyRacer for Nokia 6600 or Series 60”）下载。然而，在每个HTTP处理期间，设备将自己的识别码加入用户代理字段（例如，“Sony Ericsson P900”或“Nokia 6600”），这能够被提供下载的服务器识别来发送恰当的JAR应用程序。针对设备识别的Composite Capability/Preference Profiles（CC/PP，参见www.w3.org/Mobile/CCPP）UAProf标准正在慢慢地形成，它将使提供下载的服务器能够获得一个手机的更具体的特性。

HTTP处理一个URI，它指向手机的具体信息，但是也能包含一些其他信息，这些信息能够标识出单个手机相对厂家标准可能进行了哪些修改。这就能使下载服务器为一个指定的手机动态创建一个量身定制的JAR文件。

通常，需要检查目标设备的设计标准并尽量服从这些标准。甚至开发者可能实现任何他们希望使用的低层GUI API，对用户而言，使用他们熟悉的界面会更轻易。因此，对于不同的主机设备，尽可能地模拟菜单和命令的标准命名法。一些设备为用户提供一个一致的界面。例如，在Nokia手机上，右边的软键通常总是“导航”命令，如退出、后退和取消等，左边的软键用于“主动的”命令，如确定、选择和连接等。

6.3.1  低级图形内容

在游戏应用程序中，构成基本用户界面的便是图形内容。

尽管在一个游戏环境中，主要的Sprite一般都保持大小不变，但对于背景图像就不一定。背景构成了游戏的“世界”，并且随着屏幕尺寸不同而变化。例如，Nokia 6600显示像素为176×208，而Sony Ericsson P900显示像素为208×253，当显示软键盘时，尺寸变为208×173。

当UI被初始化后，需要使用Canvas.getHeight()和Canvas.getWidth()方法来查询设备屏幕的宽度和高度。这就为创建背景图像提供了足够的信息。使用TiledLayer时，我们能做以下两件事情：