随笔-71  评论-4  文章-0  trackbacks-0
Java嵌入式开发之二

J2ME之谜


  第一节 引言 J2ME概述

  到目前为止,大部分人都已非常熟悉 Java 2平台,以及 Sun如何把 Java技术分成三个版本 (标准版、袖珍版以及企业版),Sun 在1999年6月时推出了 Java 2袖珍版 (J2ME)来满足消费电子和嵌入设备的需要。J2ME是为了那些使用有限的能源、有限的网络连接 (常常是无线连接)以及有限图形用户界面能力的设备开发的。它最初的目标是 16位或 32位处理器,16 MHz时钟频率, 512K或更少内存的设备。乍一看之下, J2ME就像一个没有绑定明显主题的松散的应用程序接口和技术规范。我们想通过说它不是什么东西的方法来描述它,它不是一组用于台式机 Java应用程序规范,如果你再观察仔细一些,你会发现所有的 J2ME组件都围绕一个中心,这些中心被称为configuration(配置 ,Sun的市场营销资料也称它们 design centers,设计中心),它们中间的每一个都是用于消费电子和嵌入设备的特别的类。

  Connected limited device configuration(有限连接设备配置,简称 CLDC ) 这个配置定义了 Java应用程序接口以及支持手持设备的技术,就像 Sun的文档中所描述的那样, " devices that you hold in your hand(你握在手中的设备) " Palm序列手持设备可能是这一领域的设备的最好的例子,特别是它有开发 CLDC的功能以及 Palm设备运行期系统可用。
Connected device configuration(连接设备配置 CDC ) 这个配置定义支持象 Sun文档中所说, " devices that you plug into plug into the wall(你插入墙的设备)的设备的应用程序接口和技术,这样的设备的一个例子可能就是机顶盒。

  这两种配置不同的地方就在于它们应用于的装置的能力, CLDC设备的处理器能力有限 (与台式机系统比较 ),并且存储器大小一般也只在128 KB到 512 KB之间, 与此同时, CDC系统就不同了,它可能有 32位或 64位处理器,以及有限的存储容量,不过它的下限也得超过512K。 它遵循的原则就是,每个不同的能力硬件的配置都将被不同的虚拟机支持。 基于 CDC的系统使用一个功能强劲的虚拟机,而基于 CLDC系统的使用 KVM (我过会儿会介绍)。

  每个配置代表一种低水平的,基本的应用程序接口,在这两个相似基础之上是 profile(简表),用于特殊设备的额外的应用程序接口。 我想通过看一张来自SUN提供的文档中的图表 (参见图 1 )来解释这其中的关系。



图一解释 配置和简表的体系结构 J2ME的体系结构被横向地分成三层,纵向分成两部分。配置包括一个控制配置核心类的虚拟机, 具体的 简表位于每个配置之上。


  J2ME现在定义两个配置, Connected Device configuration(连接设备配置 CDC )和限制性更强的 Connected Limited Device Configuration (有限连接设备配置)。 简表的实现是 Java应用程序接口的一个集合,用于适应被定义配置的应用程序接口提供的服务,简表是一个完整的运行环境,一个在简表上执行的应用程序不需要额外的支持类。

  J2ME没有定义满足这两种配置的标准化用户接口,Sun也承认现在的消费设备多种多样,用户界面也各不一样,所以定义一个可用于所有用户的界面是一场失败的战争。 J2ME中的用户界面定义在简表中。


  第二节 J2ME的体系结构

  现在个人计算机系统的数量和种类已经发展到无法控制的地步,请你想一想,你编写的程序运行在“信息家电”舞台的情景吧,这些信息家电包括呼叫器,行动电话,像Palm这样的个人数字助手(PDA),电视机顶盒,POS终端以及其他的消费电子设备。现在全世界上光是手提电话生产商就有许多,更不用说别的家电设备了,而且每一种家电设备又有不同的特性和界面。所以,你可以想到, Java应用程序的轻便性以及能够解决开发这么许多不同的设备程序的能力,使大家对J2ME有很大的期许。当然,为了更好的开发这些信息家电,就要求把Java的精髓压缩进一个非常小的程序包中,这就是J2ME。

  J2ME是一种通过许多部件和规范的技术, 这众多的部件和规范帮助 J2ME来满足这众多的消费产品的不同的需要。和所有的爪哇程式语言技术一样,在它的核心属于一种虚拟机。 就像使用所有 Java技术一样,J2ME的核心也在一种虚拟机中。 最初,用于 J2ME应用程序虚拟机的被称作 Kilobyte virtual machine或简称 KVM。就像它名称的含义, KVM比较小,通常只有 128K或更少。这比起我们通常了解和使用的 Java 2标准版 Java虚拟机 ( JVM )的 32 MB来说就小得多了。

  用于连接虚拟机的是一系列配置和简表,它们提供了用于特定 J2ME环境的类应用程序接口(见图二)。 每个配置和简表处理一般或具体的消费产品,配置和简表规范是由多种多样的设备生产商和用户共同开发并建立的。配置是用于一组通用设备的最小的 Java平台, 常常归为一种横向的设备分组,相对来说,横向分组设备是那些共享相同的内存安排,通信带宽,能量需求以及用户能力的设备,一般认为配置能够提供这众多的设备的所有需求。
图二解释: J2ME层次 Java虚拟机是 J2ME技术的核心,但是配置和简表提供特殊环境的类应用程序接口。配置是用于一组通用设备的最小的 Java平台,而简表则为具体的设备家族或特别的应用程序提供更具体的能力。

  J2ME领域的新的开发者常常被这些事实困惑的, 事实上, Sun的第一个配置(现在只是一种配置的引用实现 )带有称为 KVM的虚拟机引用实现, KVM满足配置的虚拟机的必要条件。然而, Sun的 KVM也可以被另外一个虚拟机所代替,现在, 正是因为配置和虚拟机结合得有点紧密,因此导致了这么多的混乱。

  另一方面,简表完善了 配置,为某个具体的设备家族或某个具体的工业片段应用程序提供更高的性能。 换言之, 简表为具体的纵向市场的设备比如说行动电话提供更多的性能。这里的关键就是 简表必须完善 配置, 没有 配置和虚拟机提供核心类应用程序接口和运行期环境的话,简表也不会工作。

  通常,简表为一种给定的垂直分组设备提供用户界面、输入法、持久性机制。这类 简表被认为是发展这些设备应用程序的完整的工具包。我们见到最多的应用程序简表的例子就移动电话简表和个人数字助手(PDA)简表,其他简表为范围宽广的设备提供非常特殊的功能或应用程序可移植性,这方面的例子就是提供远程方法调用 ( RMI )功能的简表和提供统一银行事务的简表。

  虚拟机、 配置、 简表…你是不是已经被搞迷糊了? 如果这样的话,我们就来简化一下 J2ME体系结构吧。 如果你想为小型信息家电编写 Java应用程序的话,你就需要两个前提:一个 配置和至少一个 简表。 现在, 一般是配置捆绑了虚拟机和一套针对你的平台所能够用的横向分组设备的Java类库。其次,你至少还需要一个 简表来为你的平台提供附加的 Java类,这个 简表通常会为你的设备提供用户界面、输入和数据库类。有了这两个前提,你就了使用 Java为你的设备编写应用程序的基本的J2ME环境。


  第三节 详细谈谈J2ME配置

  J2ME可以在好几个不同的配置中进行配置。 就像先前提到的,每个配置为一组通用设备提供最小的 Java平台,到目前为止,只有两种配置规范。通过 Java规范定义的这两种配置是 Connected Limited Device Configuration (有限连接设备配置, CLDC )和 Connected Device Configuration (连接设备配置 CDC )。

  CLDC是为使用较小的存储容量的设备设计的 (参见图3 )。 CLDC用于内存在128到 512K之间的消费电子设备, 这一类别中典型代表的设备包含呼叫器、行动电话、PDA和POS终端;而另一方面, CDC用于比 PC机小但是具有比 512K内存多的设备,这一类设备包括互联网络电视系统、机顶盒、POS系统、汽车导航以及娱乐系统。一般来说, CDC使小型设备只要具有少量的资源,至少比台式机要少的资源就能进行Java编程,而CLDC使小型设备所拥有的资源只要比一张智能卡多一点就可以进行Java编程了。
图二解释 设备覆盖的范围 J2ME有两个配置CLDC和 CDC,CLDC是为使用较小的存储容量的设备设计的,而CDC用于比 PC机小但是具有比 512K内存多的设备。

  除了在容量大小和能力上对虚拟机规定了必要条件,配置还规定了类应用程序接口要包含常见的 java.io、 java.net、 java.util和 java.lang包,配置可能还要包括其他需要的程序包。

  CLDC

  CLDC起源可以追溯到1999年JavaOne大会上介绍的Sun的第一个袖珍版 Java和第一个 KVM以及相关的类库,虽然 CLDC和所有的配置都满足成为虚拟机的条件,可它本身还不是虚拟机,CLDC的引用实现只是包含在当前的分布中的 KVM。

  根据规范中所说,运行 CLDC的设备应该有 512K或更少的内存空间、一个有限的电源供给 (通常是使用电池)、有限的或断断续续的网络连接性 ( 9600 bps或更少 )以及多样化的用户界面甚至没有用户界面。 通常说来,这个配置是为个人化的、移动的、有限连接信息设备而设计,比如呼叫器、移动电话和 PDA等。

  与 J2SE相比, CLDC缺少下列所说的这些特征:

  AWT(抽象窗口开发包), Swing或其他图形库

  用户定义类装载器

  类实例的最终化

  弱的引用

  RMI

  Reflection(映射)

  CLDC有四个包: java.lang、 java.util、 java.io和 javax.microedition。 除了 microedition包以外,其他的这几个包都是J2SE包的核心子集,CLDC采用这些J2SE类库,但是把其中一些在微型设备中用不到类、属性、方法去掉了。因此 CLDC类库有许多细微的差别。 如果您想研究J2SE和 CLDC类库之间的差别,请参阅相关文档,在此就不详细说明了。

  想要理解为什么CLDC去除这么多J2SE中重要的类和特征,请回想一下与 CLDC相关的两条基本原理。首先,它只有 512K的内存空间, 而像RMI和映射需要的内存太大了。 其次,配置必须满足为一组通用设备提供最小的 Java平台。 在个人移动信息设备领域中,许多系统都不能支持 J2SE中的众多的高级特征。 例如,许多消费电子产品不能支持浮点数; 因此 Float(浮点类)和 Double(双精度类)就被删除了。 再看另外一个例子,许多系统没有或不提供访问一个文件系统的功能或权限。 因此与文件有关的类也被丢弃了。又如,错误处理是一个代价非常高的过程处理,在许多消费电子设备中,故障恢复是很难的甚至是不可能的。 所以在 CLDC中,许多错误处理类也被删除了。

  java.microedition程序包提供了一个一般的结构来替代许多 J2SE网络输入/输出类。 CLDC一般连接器结构还定义了一个 Connector类,允许许多不同类型的连接能够使用静态方法,下表列出使用同一个Connector类创建和打开五种不同类型的连接的方法:

  HTTP Connector.open("http://www.xyz.com");

  套接字 Connector.open("socket://111.222.111.222:9000");

  通讯端口 Connector.open("comm:1;baudrate=9600");

  数据报 Connector.open("datagram://111.222.111.222");

  文件 Connector.open("file:/xyz.dat");

  一般连接器结构提供给应用程序开发者一个到通用低水平硬件的简单的映射表。成功执行 open语句将返回一个实现一般连接界面的对象。

  CDC

  CDC涵盖了个人电脑与有至少 512K内存的小型设备之间的中间地带。现在,这一类设备通常是共享的、固定的 (不用移动)网络连接信息设备,像电视机机顶盒,网络电视系统、互联网电话与汽车导航/娱乐系统等等。

  首先,CDC基于 J2SE 1.3应用程序接口,包含所有定义在CLDC规范(包括 javax.microedition程序包)中的Java语言应用程序接口。与CLDC相比, CLDC所有缺少的特性和类在 CDC中都被补齐,包含映射、最终化、所有的错误处理类、浮点数、属性、输入/输出 ( File、 FileInputStream等等 )和弱的引用。 一般说来, CDC中预期的类包括一个J2SE子集和一个完整的 CLDC超集,如图4中所示:

图4 :J2SE、CLDC和CDC的关系
  就像使用所有的配置一样,CDC有基层虚拟机的具体的必要条件。 根据 CDC规范,基层虚拟机必须提供实现完整的 Java虚拟机的支持 。 如果虚拟机实现有一个用于激活设备的本地方法的界面,它必须兼容 JNI 1.1版本。 如果虚拟机实现有一个调试界面,它必须兼容 Java虚拟机调试界面 ( JVMDI )规范。 如果虚拟机有一个简表界面,它必须兼容 Java虚拟机简表界面 ( JVMPI )规范。 可见,为了实现这些功能,CDC肯定会变得很大,就不能称其为K虚拟机了,因此,我们通常称用于CDC的虚拟机为 CVM,这里的 C代表 compact、connected、consumer。

  第四节 谈谈J2ME简表

  虽然配置为一组通用设备提供了最小的 Java平台,但是应用程序开发者感兴趣的是为一个个别的设备生产应用程序,当他们只是使用配置的话,他们编写的应用程序就会有一些欠缺。 配置必须满足所有的设备的最小的要求, 用户界面、输入机制和数据持久性有高度地设备具体性,每一种设备都有自己的用户界面、输入机制和数据存储方法,这些往往不在配置所满足的最小要求的范围之内。

  简表为相同消费电子设备的不同的生产商提供了标准化的 Java类库, 事实上,虽然配置规范的开发由 Sun领导,但是许多简表规范仍将继续由特殊设备的供应商领导。 比如说, Motorola领导了行动电话和呼叫器简表规范的开发,又如 Palm 领导 PDA简表的开发。

  现在,五个已知简表已经有了规范, 记住,每个简表的责任都是为了完善配置的不足,下表列出了这五个简表:

简 表完善配置
Mobile information devices profile (MIDP)移动电话和呼叫器 CLDC
Personal digital assistant profilePalm和Handspring的PDA 设备 CLDC
Foundation profile用于所有不需要GUI的CDC设备的标准简表 CDC
Personal profile替代PersonalJava的Foundation完善的简表 CDC
RMI profile 提供RMI的Foundation完善的简表 CDC
 
  现在我想谈一谈另一个Java类库集,它现在差不多可以被认为是另一个简表了。当Sun为Palm开发第一个KVM时,他们需要一组类来 开发Palm的演示程序。这套类库被封装进 com.sun.kjava程序包, 在 CLDC早期的开发中,这些类被广泛的使用来测试和演示 J2ME。因为 kjava是唯一的允许应用程序开发者使用 J2ME和 KVM开发应用程序的类,所以它就被广泛使用了。甚至到了今天,一个用于 PDA或更特殊一点的 Palm的简表多已经在开发中,许多开发者仍然希望使用 kjava类来开发 PDA应用程序。尽管 kjava类不被支持,并且仅仅用于设计测试程序或演示程序,并且它们将被一个即将到来的简表所替代,但是开发者们仍然热衷于使用它来开发。

  MIDP

  Mobile Information Device Profile(移动信息设备简表 ,简称 MIDP ),第一个实现的简表,补充了 CLDC并且提供应用程序语义和控件、用户界面、持久存储器、网络和用于移动电话的计时器、双通道呼叫器和其他无线电设备。 因为 MIDP和 CLDC两者都有引用实现,我们可以使用一个例程来研究一下这个简表。

  下面的例子是一个允许用户输入代表想知道的基金报价的代号的例子。应用程序然后通过 HTTP接到一个金融网站,获得基金报价,把价格储存在一个数据库,然后把价格返回给用户。
// 到如需要的J2ME类
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
import javax.microedition.rms.*;

// 扩展MIDlet类来构建我们的自定义MIDlet
public class FundTracker extends MIDlet implements
CommandListener {

file://显示管理者变量
private Display display = null;
file://MIDlet的表单变量
private RequestForm reqForm = null;

file://MIDlet构建器
public FundTracker () {
display = Display.getDisplay(this);
reqForm = new RequestForm("Fund Tracker");
reqForm.initForm();
reqForm.setCommandListener(this);
}

file://开始 MIDlet 应用程序
protected void startApp() {
display.setCurrent(reqForm);
}

file://暂停 Midlet
protected void pauseApp() {
}

file://销毁Midlet
protected void destroyApp(boolean unconditional) {
}

file://通过监听者响应命令
public void commandAction(Command c, Displayable s) {
if (c == reqForm.getExitCommand()) {
destroyApp(false);
notifyDestroyed();
return;
}
if ((c == reqForm.getGetCommand()) &&
(reqForm.getSymField().getString().length() > 0)) {
getAndDisplayQuote();
} else
{
reqForm.getMsgString().setText("Symbol required");
}
}

file://储存由#分开的成对的基金字符串和报价字符串
private void storeQuote (String fund, String newQuote) {

file://数据库变量

RecordStore quoteDB = null;

try {
quoteDB = RecordStore.openRecordStore(
"FundQuotes", true);
byte[] data = (fund + "#" + newQuote).getBytes();
int size = data.length;
quoteDB.addRecord(data, 0, size);
quoteDB.closeRecordStore();
}
catch (Exception recordException) {
System.out.println("Unable to store quote and/or
use Fund Quote database.");
}
}

file://通过QuoteService类取回提交的代号表示的基金报价
private void getAndDisplayQuote(){
String fundSymbol = reqForm.getSymField().getString();
if (fundSymbol.length() > 0) {
String theQuote = QuoteService.getQuote(fundSymbol);
if (theQuote != null) {
storeQuote(fundSymbol, theQuote);
reqForm.getMsgString().setText(theQuote);
}
else
reqForm.getMsgString().setText("No quote" +
'' '' + "Check Symbol");
}
}
}


  MIDP应用程序称为 MIDlet, 为了创建一个 MIDlet,你必须写一个扩展基本 MIDlet类的类 (就像我们在上面代码段中列出的那样)。 这有点类似常见的 applet或 servlet。 MIDlets独有的东西是把多个 MIDlet组成一个 MIDlet套件的能力。 这就允许 MIDlet在一个单独的 JVM环境中共享资源,比如一个数据库等等。 事实上,我们上面给出的例子还包括一个 MIDlet ( RetrieveQuote,见上段程序),用于取回所报价格。 当MIDlet被请求时, MIDlet通过构造程序实例化,然后调用实例的 startApp()方法。

  在 FundTracker例子中, MIDlet的用户界面或显示是由 Display类的一个实例管理的。 对于每个 MIDlet,只有一个显示管理器实例。 所有可以显示的项目,像屏幕或画布(canvas),通过这个管理器都能够成为可见的。因为行动电话和呼叫器能力的多样化,又因为用于这些设备的应用程序类型的差异, MIDP规范提供了两种类型的用户界面。一个可移植性稍差、明确设备、低水平的应用程序接口,允许图形元素精确的控制和放置。 这个接口类型是用于应用程序特性比较典型的设备特别设计的,比如电子游戏。 一个可移植性稍好的、抽象的、高级的 GUI应用程序接口,提供来用于商业应用程序。

  我们的例程使用的是高级的应用程序接口和典型的用户界面组件 (文本框,列表等等 ),是这类界面通用的。比如说,实际的表单和所有的小组件在一个单独的文件中都已定义。 就像在代码段一中列出的那样,当 MIDlet创建时,一个表单的实例与 MIDlet关联。 在调用 MIDlet startApp()方法的时候,通过 Display对象显示表单。 使用一个用于表单的类,允许我们在我们简单的报价检索应用程序中重新使用这个表单 ( RetrieveQuote )。为了清晰性和风格,我们通过一个单独的类来定义报价服务。 为了演示一般连接器结构的能力,我们的报价服务类通过一个 Connector实例取回报价。



  MIDP要求平台设备提供一个机制用来储存简单的数据记录,通过正常的平台事件,比如重新启动和电池更新维护系统的完整性。 MIDP称一个持久数据库为 RecordStore。 在我们的示例中, MIDlet打开并添加一条记录到 " MutualFundQuotes " RecordStore。 正如我们的演示程序,能添加到 RecordStore中的唯一一种类型的记录是字节数组。 相同的 RecordStore是一个资源,它可以通过套件共享。 根据 MIDP规范, 当 MIDlet从平台中删除后,RecordStore也会被从平台中删除。

  PDA简表

  Palm公司是开发PDA简表规范的领头人, 这个简表也是完善了 CLDC,在相当长的一段时间内,它都将是 kjava类程序包的替代品。 Java规范建议这个 profile至少应当提供两个核心功能片段: 一个用户界面显示工具包,适合于 "有限的尺寸和深度显示 "和一个持久数据存储器机制。 显示工具包应该是抽象窗口工具包的一个子集, 而持久机制将为应用程序、数据、配置/环境信息提供简单的数据存储。

  Foundation简表

  下面三种简表不是非常常见, 这三种简表的职责都是为了完善 CDC。 Personal和 RMI简表实际上是 Foundation简表的扩展。 Foundation简表的任务是担任一个基础简表,便于以后开发出来的提供图形用户接口、 网络等功能的简表附着在它之上。 除了用于基础简表, Foundation简表还提供完整网络的支持,不管有没有使用图形用户接口。

  Personal简表

  在当前的规范需求下, Personal简表提供下一代 PersonalJava环境。这个简表允诺,提供互联网连接性和 Web保真度以及一个能够运行 Java applets的 GUI。

  RMI简表

  回想一下 CDC配置为共享的、固定网络连接信息设备提供最小的 Java环境。 RMI简表将通过提供 Java到 Java的RMI来协助提供更好的网络连接性。 通过使用 J2SE ( 1.2.x或更高版本的 ) RMI,这个简表将允许这些网络设备与其他系统应用程序交互操作 (这个系统不必也运行 J2ME )。

  kjava类

  正如前面提到的那样, kjava类是最初提供的一个供测试用的类,在 Palm设备上运行早期的 KVM和配置版本。 它们将被 PDA简表代替。 kjava类扩展了 CLDC并且提供一个图形用户接口、 Palm数据库访问,简单集合类和一个三角法计算器。

  在代码段2中,我使用 com.sun.kjava重写了 MIDP FundTracker程序,让它在 Palm上工作。 和前面的程序一样,这个简单的程序允许用户输入一个公基金代号并从WWW上的金融报价服务商那里取回报价。

  kjava应用程序被称作 spotlet。 事实上,一个应用程序可以由很多 spotlet组成,但是在任何时间只有一个 spotlet可以显示在 Palm屏幕上。 在我们的例子中,我们创建一个基本 spotlet-- RequestFormSpotlet.java,为我们的两个 spotlets子类提供用户界面。代码段 2扩展了基本的 RequestFormSpotlet以便得到并储存一个报价。 RetrieveSpotlet也扩展了基本 RequestFormSpotlet并允许储存的报价被取回(见图)

  代码段2
import com.sun.kjava.*;

public final class FundSpotlet extends RequestFormSpotlet {

public static void main (String args[]) {
new FundSpotlet().draw();
}

private void draw() {
initForm();
setTitle("Fund Quote Requested");
}

public void penDown(int x, int y){
if (getExitButton().pressed(x,y)){
getGraphic().playSound(Graphics.SOUND_CONFIRMATION);
System.exit(0);
}
if (getSymField().pressed(x,y))
getSymField().setFocus();
if (getGetButton().pressed(x,y)) {
quoteRequested();
}
}

private void storeQuote (String fund, String newQuote) {

int dbType = 0x46554e44;
int dbCreator = 0x43415454;
com.sun.kjava.Database quoteDB;

try {
quoteDB = new com.sun.kjava.Database(dbType,
dbCreator, com.sun.kjava.Database.READWRITE);
if (!quoteDB .isOpen()) {

com.sun.kjava.Database.create(0, "MutualFundQuotes",
dbCreator, dbType, false);
quoteDB = new com.sun.kjava.Database(dbType,
dbCreator, com.sun.kjava.Database.READWRITE);
}
byte[] data = (fund + "#" + newQuote).getBytes();
quoteDB.addRecord(data);
quoteDB.close();
}
catch (Exception recordException) {
System.out.println("Unable to store quote and/or use
Mutual Fund Quote database.");
}

}

private void getAndDisplayQuote() {
String fundSymbol = getSymField().getText();
if (fundSymbol.length() > 0) {
String theQuote = QuoteService.getQuote(fundSymbol);
if (theQuote != null) {
storeQuote(fundSymbol, theQuote);
message(theQuote);
}
else
message("No quote. Check Symbol");
}
}

private void quoteRequested() {
message("");
getGraphic().playSound(Graphics.SOUND_STARTUP);
if ((getSymField().getText().length() > 0)) {
getAndDisplayQuote();
} else
{
message("Symbol required!");
}
}

}


  在 RequestFormSpotlet程序中,类似于 MIDP中的 Display对象,单独的 Graphics管理许多 spotlet用户界面显示。它考虑到了屏幕会被清除,显示边界会被建立。 不象 MIDlet,没有屏幕或画布对象来让我们添加用户界面小组件, 取而代之的是按钮、文本字段等等,直接描画在 spotlet上。 paint()方法利用图形环境从独一无二的 Graphics在屏幕上显示小组件。

  我们的MIDP程序的 QuoteService类的大部分可以重新使用。 因为 kjava没有象 MIDP中HttpConnection这样特定的连接器界面,所以我们必须利用更多标准的一般的连接器结构表单获取 HTTP链接。 为了做到这一点,使用代码段 3中的代码替换 getQuotePage()方法。注意注意使用 Connector,就像在 MIDP中我们使用 HttpConnection一样。

  代码段3
private static String getQuotePage(String symbolString) {
StringBuffer quotePage = new StringBuffer();
int ch;
try {
InputStream in = Connector.openInputStream (
"testhttp://someurl/some_application?page=++&mode=fund&symbol="+
symbolString);
while ((ch = in.read()) > 0) {
quotePage.append((char)ch);
}
in.close();
return quotePage.toString();
} catch (IOException ex) {
System.out.println("Exception reading quote from
  HTTP Connection");
 return null;
 }
}


  Palm设备广泛利用数据库, 你的 Palm中的通讯簿、备忘录和记事本应用程序都与数据库有关。 kjava程序包提供了一个非常小的 Database类,不仅可以创建并保持应用程序数据,而且可以访问现有的数据库。 如果你熟悉 Palm数据库,你可能会对 kjava Database类提供的功能和信息感到失望。 然而,请再次记住, kjava只是一个演示的版本。

  在我们的例子中,我们的 spotlet访问一个 Palm数据库 (如果不存在的话,则创建一个新的数据库)来储存公基金报价。每个 Palm数据库都必须有名字、创建者 ID (一个 Palm登记的唯一的标识号 ) 和一个指定到某个单独应用程序的类型号。 试图打开数据库要通过尝试创建一个带有 ID信息的数据库实例来实现。 就象 MIDP RecordStore,记录被添加进 kjava数据库,通过把一个字节数组当成记录添加到数据库中的形式。

  第五节 再谈谈一些J2ME规范

  在 J2ME内还有很多子规范, J2ME的重要的部分如下:PersonalJava、K虚拟机 (KVM)、Java嵌入服务器以及 PersonalJava的两个扩展规范: JavaPhone和 JavaTV应用程序接口。 你可以想象, JavaPhone是一个定位于无线电智能电话和互联网络可视电话的应用程序接口,而 JavaTV则满足机顶盒市场的需求。

  下面我想详细的谈一谈以上的规范:

  1、PersonalJava

  PersonalJava应用程序环境目标是 Web连接消费设备----常常执行来自网络的小应用程序。问题是 PersonalJava如何适合 J2ME的配置和简表方案。 答案是 PersonalJava将被包容进 Connected Device Configuration中,最终将被定义为 Personal简表,即前面所谈到的Personal简表。

  另一方面,有一段时间将有两个 Java应用程序接口为嵌入开发世界服务: PersonalJava和 EmbeddedJava。 PersonalJava偎依在 J2ME大伞之下, 可为什么 EmbeddedJava不呢? EmbeddedJava不和 PersonalJava同在 J2ME内,是因为在 PersonalJava和 EmbeddedJava应用程序之间有一个基本的差别。 PersonalJava应用程序期望连接到某类网络中下载并执行小应用程序。 按照这种观点, PersonalJava设备就是一般用途的消费设备; 它们的能力可以被扩展。

  相比之下, EmbeddedJava设备则惨了点。 它们执行的功能都非常具体的,基本没有必要提供下载新的代码到 EmbeddedJava设备的能力。 Hence, PersonalJava设备使用可扩展 Java应用程序接口; 而EmbeddedJava设备则没有,因为没有必要使用。

  PersonalJava可以以两种形式得到: 由原码形式的,提供给那些对把PersonalJava移植到其他设备感兴趣的开发者,那些已经把 PersonalJava移植到某个具体的操作系统和处理机的组织提供二进制形式的 PersonalJava环境。有兴趣探索 PersonalJava的开发者如果没有二进制平台也可以使用 PersonalJava模拟环境 ( PJEE )。 这个模拟器运行于 Solaris/SPARC或 Windows,并且在许多配置中可用。 这些多种多样的配置基于“ look and feel”和类库支持 (环境是否提供 PersonalJava规范中规定的最低限度的或最大的类库)。PJEE包括类文件,一个应用程序 launcher和一个 appletviewer (两者都是为了调试功能并使其最优化)和其它的附带的文件 (例如字体叙述文件)。

  J2ME家族的另一位成员 JavaCheck实用程序,提供了 PersonalJava的补充支持。 你把应用程序传过 JavaCheck,它将告诉你你的应用程序在一个 PersonalJava环境中能否顺利地执行。 JavaCheck检查类之间的依赖关系,如果应用程序调用了一个在 PersonalJava不可用的应用程序接口,它就会给出一个警报信号。 (据我所知,目前有两种JavaCheck的版本可用,一个是用于检验 PersonalJava 1.0版应用程序,另一个用于检验 1.1.x版程序。 当前的 PersonalJava应用程序接口规范是 1.2,用于这一版本的 JavaCheck还没有。 读者请去Sun相关网站去看看( http : file://java.sun.com/products/personaljava)。

  2、KVM

  前面我也说过,KVM是用于 J2ME平台最小的虚拟机,并且是用于CLDC配置的虚拟机。可是J2ME应用程序并不一定非要使用 KVM,J2ME技术可以使用任何虚拟机,不过至少应当有 KVM这样的功能。

  为了满足基于KVM的设备一般只有狭小的内存空间和有限的处理能力的事实, KVM使用 C编写 (它不是现有的VM改进了的以后的产品)。 此外, KVM是模块化的, 也就是说,它是由模块构建的,当某个模块实现了预先设定的目标后,就可以很容易地把这一模块卸载。 可选的某块包括: 大的数据类型 ( long、 float和 double ),多维数组、类文件验证等。

  KVM的本地界面以轻便性为原则构建,所以在KVM中任务切换不依赖硬件产生的记时器中断,因此在这种意思上来说不是抢先式。任务切换发生在虚拟机执行了一个预设编号的字节码之后。 并且, KVM的无用单元收集利用一个标记清扫(mark and sweep)算法来实现无用单元释放。 因此,对象引用是直接的,就像标准 Java一样。

  当然,除了虚拟机以外还有许多可用的执行环境,在小型设备中,虚拟机必须要么被扩展,要么在附加工具协助下提供一个更加完整的运行期环境,正是这个原因, KVM需要附带的工具,比如说, JavaCodeCompact工具提供了预链接和预加载类, 允许Java类被直接地链接进虚拟机中。((设备上所有的应用程序使用的类 can直接地嵌入虚拟机。)

  KVM一个可选的附件就是 Java Application Manager ( Java应用程序管理器,简称 JAM )。JAM的工作就是处理下载、安装、执行和卸载 CLDC设备上的应用程序的细节问题,因为资源有限,在CLDC设备上有可能不存在这些功能。JAM也处理更新安装应用程序的操作。(如果更新过程失败,它甚至可以重新使用旧的应用程序。 )

  3、Java Embedded Server(Java嵌入服务器)

  Java Embedded Server( Java嵌入服务器,简称 JES),在 PersonalJava基础上建立,是一个用于嵌入式网络设备的运行期环境。为了理解 JES,你必须理解两个核心概念:服务和服务空间结构。后者是前者的容器。服务程序是运行于一个 JES服务器上的组件化程序;服务空间结构是为服务程序提供生命周期 支持的环境。

  技术上说,服务程序是界面的实现,事实上,它是一个实现特定活动的Java类集合。比如说,假如把 JES配置为一个家庭的气候控制系统的服务器,可以把从模数转换器读到的温度数据放进一个数据组件程序中。我就可以称这个组件为ReadThermostats服务程序。

  在 JES的领域,服务的封装媒介称为 bundle。简单地说,bundle就是一个带有特殊内容的JAR文件。服务程序和bundle之间有一对一关系,一个bundle带有一个服务程序。服务程序和 bundle之间有一对一关系,一个 bundle带有一个服务程序。可这也不一定,一个 bundle可以设置多个服务程序索引 (注意, JES提供的所有的核心服务,每个 bundle中只有一个 )。

  正如前面提到的那样,服务空间的一项工作就是管理服务程序的生命周期,这个工作的很大的部分包括解决服务隶属关系。bundle内容的一个重要的部分是bundle服务的依赖信息。所以,当服务空间打开一个bundle安装它的服务时,服务空间就可以确定外部需要什么服务。而且,一个服务的依赖关系并不是静止不变的,它们可以随某些事件改变。比如说当服务程序更新时的变化就是一个很好的例子。一个服务的新的版本可以添加或去除依赖关系。服务空间跟踪并解决这样的动态依赖关系。如果服务空间处理所有服务程序的生命周期,这就暗示了服务空间被赋予知晓一切的能力,那就是说,它能够推论结构、依赖、安装的细微差别等所有它负责的服务。服务空间通过在 bundle内伴随服务的 Java代码模块处理一些任务,这些模块被称作 wizard(向导)。JES向导是根据它们完成的任务命名的:

  Dependencies -向导告诉调用者一个bundle依赖关系是什么。

  Installer-向导处理bundle中服务的安装和删除操作。

  Activator -向导知道如何启动和终止服务。

  Updater -向导控件更新bundle中的服务。(更新向导不仅知道更新一个服务,而且知道在何时和什么情况下更新服务。 )

  About -这个向导,就像它名称意味的那样,返回关于 bundle内容的信息。

  Dispatcher -这是一种元向导(meta-wizard)。服务空间调用dispatcher向导定位一个bundle的其他向导。

  当一个 JES服务器启动的时候,服务空间并不是完全没有启动服务。JES定义一组核心服务(可选),这些都是任何 JES服务器的组成部分。这些核心服务包含:

  HTTP服务

  日志 -记录错误和事件日志
  
  日期 -精确到秒的日期/时间服务
  
  连接管理器 -提供网络服务和Socket绑定,也处理连接接收。

  线程管理器 -管理服务器提供的线程。thread管理器支持线程池并允许有效使用线程上界的规范。

  计划程序 -提供未来的事件计划安排 (可用于告诉服务器某某动作必须在某某事件发生 )

  RMI

  SNMP

  控制台 -提供远程管理服务器功能

  基于 HTTP的远程应用程序接口实现

  基于 RMI的远程应用程序接口实现
 
  如果你把服务空间结构当成 JavaBean中的容器的话, JES就变得容易理解了。在这种类比关系中,服务程序就相当 JavaBean。那么,正象组件容器提供一个环境供 JavaBeans实例化、运行一样,服务空间就是以实例化的服务的聚集地。服务空间管理安装、实例化、执行、终止以及卸载服务;它也提供应用程序接口供服务交互作用。
posted on 2006-07-07 14:57 zjw_albert 阅读(210) 评论(0)  编辑  收藏

只有注册用户登录后才能发表评论。


网站导航: