www.sosof.com

当前页面位置: » 丰搜网 » 文档中心 » 详细内容

在本章和下一章，我们将讨论如何使应用程序尽可能地可移植，以及如何编写高效的代码。尽管java（尤其是无线java）并非“编写一次，到处运行”，将java midlet移植到不同的无线设备上通常还是比较简单的。和移植相关的问题源于手机的多样性：不同的堆内存、不同的持久化存储、不同的屏幕尺寸，以及不同的用户输入方式都使得一个应用程序在一系列设备上以一致的行为运行的难度大大增加。一些设备还有可选的api包，还要为每一个操作考虑到网络问题，如允许的jar文件尺寸。

这一章将研究如何开发能在尽可能多的手机上移植的midlet。我们将讨论如何使用设计模式和代码编写准则来帮助移植，使开发者能从自己的努力中获得最大的可重用性。

创建可移植代码的价值被市场上一系列java设备扩大化了。它们中的许多都是相似的；例如，series 60平台为一系列设备提供了一个创建应用程序的方式。甚至在series 60设备中，开发环境也是有不同的。一些手机包括wireless messaging api（jsr 120）和java蓝牙api（jsr 82）。新出的series 60设备，如nokia 6600，支持midp 2.0，早期的设备如nokia 3650，仅支持midp 1.0。symbian系统设备也有不同的用户界面。它们不同大小的屏幕，更显著的是用户输入方式的不同：sony ericsson p900使用一个非常大的触摸屏和一个小的操纵杆，而通常series 60手机都有较小的屏幕并使用键盘和一个方向操纵杆。

然而，这些不同点并不意味着：一个应用程序不得不完全重写以便运行在所有的设备上。不管我们的应用程序使用等form、textfield和list高级组件，还是使用canvas自己绘制和处理事件（或者同时使用这些技术），我们仍然能够做许多工作使得我们的midlet可移植。

最后，核心应用程序应当在不同设备上均保持不变，任何不同都应该是由于不同的用户界面引起。例如，图形操作可能由于较小的屏幕而改变，或者根据不同的用户输入而创建不同的菜单。确保核心应用程序保持不变需要将其从ui中分离，这需要基于一个恰当的模式。

开发者除了要创建一个可移植的架构，还要满足不同设备的性能。这需要知道设备支持哪些api并相应更改midlet。

当讨论编程模型时，我们还将讨论symbian系统设备的不同之处，并看到这将影响到应用程序的实现。

已经有许多类型的结构设计可以在面向对象的编程语言如java中采用，这有助于代码的可移植性。虽然我们不打算讨论设计理论的细节，通常在midlet开发中考虑重要的概念还是值得的。传统上，这些设计都是与桌面应用程序或基于服务器的应用程序开发关联的；然而，由于内存和处理器能力的约束对无线应用程序越来越小，这些模式变得愈加重要。下面的章节将介绍两种有用的设计模式。

这是在gui应用程序中广泛使用的模式。它将应用程序分为3个特定的实体：一个模型、一个视图和一个控制器。每个实体都依赖于其他实体，但是自身拥有特定的功能。模型-视图-控制器（model-view-controller，mvc）模式可以追溯到smalltalk编程语言的ui模型。这3种实体如下：

· 模型（model）：也叫做（也许更为恰当）引擎（engine）。模型持有应用程序的数据。它处理来自控制器的请求并改变数据。它和视图关联，当其数据改变后，通知视图更新显示，这样确保数据的最新状态反映到视图上。它还响应来自视图的查询模型状态的请求。简言之，它提供了应用程序的核心业务逻辑。

· 视图（view）。模型视图负责将数据表现给用户。为了响应来自模型的通知，视图获得数据的当前状态并绘画它到屏幕。它还提供接受用户输入的用户界面。

· 控制器（controller）。控制器负责管理应用程序的流程。它响应捕获自视图的用户输入，处理输入并向模型发送指令来相应地改变其数据状态。

一个基本的mvc实现的uml类图如图6.1所示。这些对象间的交互在uml序列图（见图6.2）中可见。