安全配置管理器

　　如果您辛辛苦苦地开发出应用程序，但在用户设备上安装时却突然失败，没什么比这更令人沮丧的了。不幸的是，如果您未对在最终用户设备的安全设置下运行的应用程序进行测试，有时会发生此情况。避免产生安全相关问题的最佳方法是将安全规划作为应用程序设计、开发和测试过程的一个核心部分。这正是安全配置管理器的用途。

　　设备安全管理器运行在台式机上，提供两个基本服务。设备安全管理器显示当前连接到台式机的设备或仿真程序的当前安全设置（在 Windows XP 上通过 Microsoft ActiveSync? 连接，在 Vista 上通过 Windows Mobile Device Center (WMDC) 连接）。显示的信息包括设备安全策略、各个安全设置的列表，以及安装到每个设备证书存储中的证书的列表。

　　设备安全管理器还允许您使用公共安全策略配置仿真程序，从而允许您充分地测试不同安全策略对您应用程序的影响，而无需真实设备。图 8 显示了刚刚将仿真程序配置为具有一层提示安全策略后的设备安全管理器。

图 8. 更新仿真程序安全策略后的安全配置管理器

　　使用设备安全管理器，可以充分利用仿真程序轻松地对应用程序进行测试，同时确保应用程序在不同安全策略下按预期方式运行。

　　注意：

　　有关 Windows Mobile 安全性的详细信息，请参阅 Windows Mobile 开发人员中心或 Mobile2Market 常见问题。

　　CabSignTool

　　在分发应用程序之前，您通常必须使用相应的证书来签署应用程序可执行文件和安装文件，以便将您的组织标识为该应用程序的发布者。由于安全原因，必须签署用于安装该应用程序的所有应用程序可执行文件（*.dll 和 *.exe）以及 CAB 文件。签署每个单独的可执行文件、构建 CAB 文件，然后再签署 CAB 文件，这个过程很费时，尤其是在应用程序由几个可执行文件组成时。CabSignTool 实用程序是一个命令行实用程序，它将您从签署应用程序的各个部分的繁琐工作中解脱出来，从而简化了应用程序签署过程。

　　CabSignTool 实用程序一次可以签署一个 CAB 文件和所有包含的可执行文件。您只需构建应用程序可执行文件并创建 CAB 文件，而无需签署所有文件。CabSignTool 实用程序然后将 CAB 文件内容分解、签署每个可执行文件、重新组合并入了可执行文件的已签署版本的 CAB 文件，然后签署该 CAB 文件。CabSignTool 实用程序可以让您选择是使用单个证书同时签署 CAB 文件和可执行文件，还是使用不同的证书分别签署可执行文件和 CAB 文件。

　　Hopper

　　设备上的移动应用程序往往持续运行数周或数月而不关闭。在这么长的时段内长时间使用应用程序有时可能会暴露应用程序中的一些问题，而这些问题通过传统的应用程序测试是难以发现的。要发现这些问题，必须在测试周期过程中使应用程序承受其在部署后将会经历的同样类型的压力。Hopper 实用程序提供了一种执行此类压力测试的方法。

　　Hopper 实用程序模拟用户在应用程序内的随机位置执行快速单击操作。这会使应用程序承受巨大的压力，其所执行的非结构化应用程序使用程度能够暴露执行传统应用程序功能测试时不易发现的应用程序错误。Hopper 实用程序可用于对单一应用程序进行压力测试，或是在纳入更大随机性的情况下（除了在各个应用程序内随机执行单击操作外，还随机在应用程序之间进行切换）同时对几个应用程序进行压力测试。应在所有的应用程序测试中都使用 Hopper 实用程序。同样是这个实用程序，也可用于测试 Windows Mobile 设备来确保设备的稳定。在测试中使用 Hopper 实用程序不仅可以验证应用程序的稳定性，还可以验证应用程序并未给设备带来不稳定性。

　　Local Server Framework

　　Local Server Framework 是一些工具和类，它们专为简化对依赖与远程服务器通信的移动应用程序进行测试而设计。为了帮助简化移动应用程序的开发，可以通过 Local Server Framework 建立一个虚拟网络和服务器，接收应用程序发出的网络调用并返回程序所要求的结果。通过使用受到良好控制的本地服务器环境，可以更轻松地将移动应用程序中由外部网络导致的问题或服务器问题与程序中发生的那些问题加以区分。

　　示例

　　Windows Mobile 6 SDK 提供了几个您可能会觉得有帮助的示例。这些示例涉及在开发 Windows Mobile 6 应用程序时可能会遇到的大部分主题，可以通过它们节省大量时间，还可以将它们作为学习工具。以下是几个最值得注意的示例。

　　UILayout

　　本示例展示了如何构建能够动态地适应设备外观造型差异的自用应用程序。本示例涉及如何整合停靠、定位和其他显示管理功能。本示例还包含一个用于封装此显示逻辑大量内容的类 ScreenLib。ScreenLib 类以可重用性为设计宗旨，可以轻松地调整它来适应您自己的应用程序。

　　RingtoneManager

　　本示例展示了新 Windows Mobile 6 声音 API 的使用。

　　BasicRecognition、InkNotes 和 InkSerialization
　　这些示例展示了 WISP Lite API 的几种用途。所涉及的主题包括对基于手写的输入执行文本识别、在应用程序内使用基于手写的输入以及将手写内容存储在文件中。

　　GPS

　　本示例展示了如何在托管应用程序内访问 GPS Intermediate Driver。该示例包括用于从托管应用程序提取本机调用详细信息的所有必需包装方法。

　　.NET Compact Framework 2.0

　　所有 Windows Mobile 6.0 设备的 ROM 中都包括 .NET Compact Framework 2.0 SP1。这使您可以充分利用 .NET Compact Framework 2.0 所提供的丰富功能以及在 .NET Compact Framework 1.0 基础上进行的众多改进，而不必关心是否需要将 .NET Compact Framework 2.0 运行时与应用程序一并加以部署。甚至连 .NET Compact Framework 1.0 应用程序在 Windows Mobile 6 设备上的运行情况都会得到改善，因为 .NET Compact Framework 1.0 应用程序与 .NET Compact Framework 2.0 完全兼容，所以能够在 Windows Mobile 6 设备上运行，而且不必对程序进行任何更改便可充分利用 .NET Compact Framework 2.0 的改进。.NET Compact Framework 2.0 进行了许多改进，这些改进旨在提高开发人员生产力、增强与完整 .NET Framework 的保真度和加大对设备功能的支持。本部分介绍 .NET Compact Framework 2.0 部分最值得关注的功能。

　　用户界面功能得到了改进

　　尽管 .NET Compact Framework 2.0 的大量改进遍及各处，但许多最明显的改进都是针对与用户界面有关的功能。

　　Windows 窗体控件

　　控件是应用程序用户界面的构建基块。许多应用程序的可用性与应用程序对可用控件的利用情况有直接关系。.NET Compact Framework 2.0 提供了许多新的控件；这些新控件有助于简化应用程序用户界面设计以及为用户提供改进的体验。

　　MonthCalendar 和 DateTimePicker 控件

　　作为新控件的一部分，.NET Compact Framework 2.0 提供了两个用于显示和输入基于日期的信息的控件：MonthCalendar 控件和 DateTimePicker 控件。图 9 中显示了这两个控件。如果想要在应用程序中包括日历的外观并使其在窗体上始终可见，MonthCalendar 控件会有帮助。DateTimePicker 非常适合用于显示尺寸有限的移动设备；日期和时间信息显示在看似 TextBox 控件的控件中，但当用户需要输入数据时，DateTimePicker 控件会显示完整的日历。

图 9.MonthCalendar 控件和 DateTimePicker 控件。

　　WebBrowser 控件

　　对于想要整合基于 Rich HTML 显示的应用程序，.NET Compact Framework 2.0 提供了图 10 中所示的 WebBrowser 控件。WebBrowser 控件提供了许多事件，应用程序可以通过它们跟踪用户与 WebBrowser 控件内容的交互；必要时应用程序可以通过自定义行为响应用户交互事件。

图 10. 显示 Windows Live 移动搜索页面的 WebBrowser 控件

　　Notification 控件

　　Notification 控件是新控件中最值得关注的控件之一。可以使用 Notification 控件向用户显示消息，而不会更改用户当前活动的上下文。还可以通过 Notification 控件在弹出式气球中显示消息，这与 Windows Mobile 设备显示电池电量不足消息的方式类似。

　　其他控件

　　本部分所提到的控件只是一小部分。除了此处提及的控件之外，.NET Compact Framework 2.0 还包括许多其他控件，其中有 StatusBar 控件、针对 Smartphone 的 DataGrid 控件和 UserControl 派生的自定义控件等等。

　　对设备外观造型差异的支持

　　Windows Mobile 设备有许多不同的外观造型，而且新的外观造型在不断出现。为确保应用程序可以在 Windows Mobile 系列设备上顺利地工作，需要对应用程序用户界面进行设计，以适应设备屏幕尺寸、形状和分辨率上的差异。为了减轻您在处理这些设备差异所涉及的琐碎事务上的工作量，.NET Compact Framework 2.0 提供了几项新功能，用于简化具有适应能力的应用程序用户界面的创建。

　　在这些新功能中，最值得注意的是添加了控件停靠和控件定位功能。控件停靠和控件定位有助于使您的应用程序用户界面的适应能力更强，因为通过使用停靠和定位功能，可以提供有关控件应如何响应显示区域变化的默认行为。

　　停靠控件时，会将控件与其父控件的边缘对齐。例如，如果将控件配置为停靠在其父控件的左边缘，该控件的位置将会靠着父控件的左边缘，并沿着父控件的左边缘填充整个区域，如图 11 所示。当设备外观造型差异导致父控件尺寸发生变化时，停靠的控件会自动调整其自身尺寸，以保持与父控件左边缘的对齐。

图 11. 横屏和纵屏上显示的停靠在其父控件顶部边缘的控件

　　定位控件表示控件的一个或多个边缘应与其父控件的相应边缘保持固定的距离。设备屏幕尺寸上的差异会使控件自动调整其尺寸和位置（必要时），以使定位边缘与父控件边缘之间始终保持指定的距离。图 12 显示了定位到父控件左、右、顶部及底部边缘的 TextBox 控件。

图 12. 横屏和纵屏上显示的定位到其父控件左、右、顶部及底部边缘的控件

　　在某些情况下，让应用程序调整其控件大小或移动其控件来适应设备屏幕区域尺寸上的差异可能不切实际。当应用程序拥有大量控件，而调整大小后对用户而言控件可能变得过小而使用户无法以适当的方式与其进行交互时，通常会出现这种情况。在这种情况下，较好的解决方案是允许用户滚动应用程序显示区域，以查看屏幕边缘之外的控件。使用 .NET Compact Framework 2.0 时，无需进行任何特殊的工作来将滚动功能整合到应用程序中。应用程序显示时，.NET Compact Framework 2.0 会自动检测是否存在任何受显示尺寸限制而无法看到的控件，并在必要时为应用程序窗体添加滚动条。.NET Compact Framework 2.0 还提供了所有滚动条处理功能；因此，应用程序不需要做任何特殊处理，用户便可通过滚动窗体来查看隐藏的控件。

　　设备不仅在显示尺寸上有区别，在显示分辨率上也存在差异。如果不对这些分辨率差异加以考虑，那么最初设计用于 96 每英寸点数 (dpi) 显示的应用程序在 192 dpi 的设备上会显示得非常小，并呈压扁状。为能正常显示，控件需要进行缩放以适应新的显示分辨率。使用 .NET Compact Framework 2.0 时，处理这些分辨率差异会变得简单，因为 .NET Compact Framework 2.0 会自动缩放所有控件，以将设计时分辨率和运行时分辨率之间的差异考虑在内。

　　键盘交互和基于键盘的导航

　　.NET Compact Framework 2.0 中一项非常重要的改进是，为配备小键盘或键盘的设备提供了更好的支持。在 .NET Compact Framework 2.0 中，所有控件现在都接收 KeyUp、KeyDown 和 KeyPress 事件，这使您可以在应用程序中整合自定义键盘处理功能。通过新添加的 Form.KeyPreview 属性，您还可以选择是将键盘事件发送到各个控件，还是将所有控件键盘事件发送到包含这些控件的窗体。

　　.NET Compact Framework 2.0 还加入了对将控件设置为制表位及设置控件 Tab 键顺序的支持。这样，使用支持键盘的设备的用户便可不必使用笔针，而是使用 Tab 键在应用程序控件之间进行移动。

　　数据功能得到了增强

　　就本质而言，LOB 应用程序的大量时间花费在管理数据和与数据进行交互上。对于创建 LOB 应用程序的开发人员来说，有效率而且易用的数据类是必不可少的。Windows Mobile 6 通过在 ROM 中加入 SQL Server Compact Edition，为 LOB 应用程序开发人员提供了他们所需的完全关系型的数据库支持。借助 ROM 中的 SQL Server Compact Edition，就可以利用本地安装的关系数据库 SQL Server Compact Edition 的功能和能力，而不必在应用程序部署中加入数据库安装组件。

　　无论您是使用 DataSet 类和 SQL Server Compact Edition 来处理关系数据，还是使用 XML 类来处理分层数据，.NET Compact Framework 2.0 都提供了所需的易用、有效率而且丰富功能的类，以减少编程工作量，同时提高应用程序性能。

　　注意：

　　除本部分中介绍的许多出色的新功能之外，还可以参阅以下“性能更强，资源管理效率更高”部分中对改进的数据类运行时性能的介绍。

　　关系数据

　　.NET Compact Framework 2.0 提供的一种关系数据类对应用程序的影响最大，它就是新增的 SqlCeResultSet 类。SqlCeResultSet 类提供了直接指向 SQL Server Compact Edition 数据库的游标，该游标可以进行更新和滚动。SqlCeResultSet 类不是像 DataSet 类那样在内存中复制大量数据库数据，而是直接与 SQL Server Compact Edition 数据库引擎协作，因此不需要复制数据便可提供数据更新和游标滚动功能。

　　与 DataSet 类相比，SqlCeResultSet 类的体系结构可以大幅度减少应用程序占用的内存量。在许多情况下，SqlCeResultSet 可以将应用程序必需的内存量减少几兆字节。除了减少内存消耗之外，SqlCeResultSet 的速度要比 DataSet 类快得多。SqlCeResultSet 的速度通常是 DataSet 类的 3 到 5 倍。

　　XML

　　.NET Compact Framework 2.0 提供了几项增强功能，用于处理基于 XML 的数据。这些更改简化了 XML API 的使用，并使 XML API 在与完整 .NET Framework 所提供的功能的一致性上得到大幅度提高。作为这些增强功能的一部分，.NET Compact Framework 2.0 添加了对 XML 查询语言 XPath 的支持；XPath 可以大幅度减少导航 XML 数据所需的编程工作量，而且与使用显式导航 API 时相比，导航 XML 数据时的效率往往更高。还添加了 XmlSchema 类及相关的类，这样便可以编程方式处理和创建 XML 架构。

　　其中一个呼声较高的功能（XML 序列化）现在已经提供。.NET Compact Framework 2.0 现在加入了 XmlSerializer 类及相关的类，如 XmlElement 和 XmlAttribute 类。由于添加了这些类，现在可以轻松地将应用程序对象以 XML 形式保留和还原。

　　新的 XmlSerializer 类替代了 .NET Compact Framework 1.0 中使用的 Web 服务 XML 序列化实现。所有 Web 服务 XML 序列化和反序列化现在都通过新的 XmlSerializer 类来执行。新的 XmlSerializer 类的速度能够稳定地保持在 .NET Compact Framework 1.0 中 Web 服务 XML 序列化实现速度的二到三倍。归功于新的 XmlSerializer 类，应用程序从 .NET Compact Framework 2.0 应用程序进行 Web 服务调用所花费的总时间现在远远少于从 .NET Compact Framework 1.0 应用程序进行相同调用所花费的时间。

　　性能更强，资源管理效率更高

　　Windows Mobile 6 在 ROM 中加入了 .NET Compact Framework 2.0，从而提高了托管应用程序的性能。.NET Compact Framework 2.0 在 .NET Compact Framework 1.0 的基础上进行了重大性能改进。性能改进几乎影响到了应用程序执行的每个方面，包括应用程序资源的恢复。

　　为改进性能，.NET Compact Framework 2.0 运行时进行了全面的审查和返工。付出的努力得到了回报。尽管难以确定性能增强会给任何特定应用程序产生怎样的影响，但 .NET Compact Framework 2.0 运行时许多区域的执行速度可能接近 .NET Compact Framework 1.0 中相应操作执行速度的一倍半。其他区域进行的改进更为显著，如虚拟或非虚拟方法调度，在许多情况下，其速度几乎是 .NET Compact Framework 1.0 的两倍半。

　　除整体运行时性能改进之外，还对改进数据类的性能给予了特别关注。.NET Compact Framework 2.0 DataSet 类加载数据的速度是 .NET Compact Framework 1.0 版本的三到四倍。XmlTextReader 类进行了类似的性能改进，现在它读取 XML 文件内容的速度几乎是 .NET Compact Framework 1.0 的三倍。

　　除了许多应用程序运行时性能改进之外，.NET Compact Framework 2.0 还使垃圾回收器的性能得到巨大改进。一般情况下，.NET Compact Framework 2.0 垃圾回收器恢复内存的速度是 .NET Compact Framework 1.0 的七倍。大型对象分配的管理和恢复是与其他内存分配分开进行的，尽管其速度在 .NET Compact Framework 1.0 中已经非常快了，.NET Compact Framework 2.0 垃圾回收器的速度却是它的四倍。表 3 提供了 .NET Compact Framework 2.0 性能改进的总览。

表 3. .NET Compact Framework 2.0 在 .NET Compact Framework 1.0 基础上进行的性能改进总览
任务	.NET CF 2.0 较之于 .NET CF 1.0 的性能改进
整体运行时执行	速度快一倍半（平均）
方法调度	速度快两倍半
DataSet 加载	速度快三到四倍
XmlTextReader 读取	速度快三倍
垃圾回收器内存恢复	速度快七倍
垃圾回收器大型对象恢复	速度快四倍

 

　　不但应用程序在使用 .NET Compact Framework 2.0 时比在使用 .NET Compact Framework 1.0 时的性能更高，而且在 Windows Mobile 6 设备上运行的 .NET Compact Framework 2.0 应用程序与在较早版本 Windows Mobile 设备上运行的同一 .NET Compact Framework 2.0 应用程序相比，前者的启动速度要比后者快 25%。Windows Mobile 6 设备上启动时间得到缩短是因为在设备 ROM 中安装了 .NET Compact Framework 2.0。与将 .NET Compact Framework 2.0 安装在 RAM 中的设备相比，单是将 .NET Compact Framework 2.0 安装在设备 ROM 中便可使应用程序启动速度提高 25%。

　　所有这些性能改进不但意味着用户对您的速度更快且响应更及时的应用程序更为满意，还加快了应用程序的开发速度，因为现在您等待的时间减少了。应用程序的启动和运行速度都更高，获得应用程序测试结果的时间也更短。

　　本机代码互操作性进行了重构
　　.NET Compact Framework 2.0 在 .NET Compact Framework 1.0 已有功能基础上增加了许多新功能。由于增加了如此多的新功能，.NET Compact Framework 2.0 应用程序仅使用托管代码所执行的工作就比在 .NET Compact Framework 1.0 应用程序中可以执行的工作多得多。即使使用这些众多的新功能，托管应用程序有时仍需要与本机代码进行交互。与 .NET Compact Framework 1.0 相比，.NET Compact Framework 2.0 提供的本机代码互操作性实现进行了显著改进，大幅度简化了通过托管应用程序代码与本机代码进行的交互并减少了混淆。

　　.NET Compact Framework 2.0 添加了组件对象模型 (COM) 支持，使托管应用程序可以直接调用 COM 组件。不必再像 .NET Compact Framework 1.0 所要求的那样，为使 COM 对象可访问而创建自定义本机库。

　　本机代码封送层进行了改进，以支持比过去多得多的数据类型。.NET Compact Framework 1.0 中的大部分数据封送限制已不存在。现在可以直接将大部分参数从托管应用程序传递到本机代码，而无需进行任何特殊的编程；这包括包含嵌入式类型（如字符串和数组）的类和结构。.NET Compact Framework 2.0 还通过 MarshalAs 属性提供了可自定义的参数封送。

　　对于那些需要处理要求使用窗口句柄的本机函数的开发人员来说，现在所有 .NET Compact Framework 2.0 Windows 窗体控件都提供了 Handle 属性。Handle 属性公开控件基础窗口的本机窗口句柄，可以将该属性传递给要求使用窗口句柄的本机方法。

　　SQL Server 2005 Compact Edition

　　所有 Windows Mobile 6 设备都将 SQL Server Compact Edition（一种企业质量关系数据库）安装在 ROM 中；对于 Pocket PC 和 Smartphone 设备都是如此。借助 ROM 中的 SQL Server Compact Edition，应用程序就可以充分利用本地的完全关系型数据库 (SQL Server Compact Edition)，而不必在应用程序部署中加入数据库安装组件。这会减少部署支持的时间和成本。

　　注意：

　　使用 SQL Server 2005 Mobile Edition 创建的现有数据库文件与 SQL Server 2005 Compact Edition 完全兼容，而且无需对数据库文件进行修改即可使用。

　　功能丰富

　　SQL Server Compact Edition 是一个功能丰富的关系数据库，提供了完整的 SQL 语法，其中包括内部联接、外部联接和子查询。SQL Server Compact Edition 提供了完整的事务一致性，这种一致性确保了数据库始终保持一致的状态，即使是在应用程序崩溃或设备完全断电时也是如此。SQL Server Compact Edition 提供记录级、页面级和数据库级的锁定功能，这确保了数据库的完整性，即使是在多个线程或应用程序同时进行访问和更新的情况下，也是如此。一项针对 LOB 应用程序的重要功能是，SQL Server Compact Edition 支持的数据库大小高达 4 GB。

　　有亲切感
　　SQL Server Compact Edition 提供了 SQL Server 2005 SQL 实现的丰富子集，使您能够充分利用现有的 SQL Server 技能。您还可以充分利用现有的数据库编程技能，因为 SQL Server Compact Edition 为托管应用程序提供了一个 ADO.NET 库，并为本机应用程序提供了一个 OLEDB 库，这两个库都与 SQL Server 2005 的对应库保持一致。

　　SQL Server Compact Edition 与 SQL Server Management Studio 和 Visual Studio 2005 完全集成。通过 SQL Server Management Studio，可以创建新的 SQL Server Compact Edition 数据库、查看数据库对象、创建表、修改表以及执行交互式查询。图 13 所示的 SQL Server Management Studio 中显示的是 SQL Server Compact Edition 数据库中表、表列和表索引的列表。

　　图 13. 在 SQL Server Management Studio 中查看的 SQL Server Compact Edition 数据库表、表列和表索引

　　Visual Studio 2005 完全支持 SQL Server Compact Edition，其提供的面向数据的功能与为其他数据库提供的相应功能是相同的。使用 Visual Studio 2005 时，可以将 SQL Server Compact Edition 数据库作为数据源添加到项目中。添加 SQL Server Compact Edition 数据源时，Visual Studio 2005 的行为与其对 SQL Server 2005 数据库的行为相同；它会生成强类型 DataSet 派生的类，并将数据库表添加到 Visual Studio 2005“数据源”窗格中。可以完全像在使用 SQL Server 2005 时那样，将表和列从“数据源”窗格拖动到应用程序窗体上，Visual Studio 2005 会自动生成相应的控件和数据绑定代码。图 14 显示了“数据源”窗格中查看到的 SQL Server Compact Edition 数据库表。

图 14. Visual Studio 2005“数据源”窗格中 SQL Server Compact Edition 数据库的表

　　通过 Visual Studio 2005 Server Explorer，可以打开 SQL Server Compact Edition 数据库，并以交互方式浏览数据库内容。还可以通过 Server Explorer 打开数据库表，以查看、添加、修改和删除记录。

　　内置数据同步支持

　　设计移动 LOB 应用程序时必须处理的其中一个最重要的问题是数据同步策略。第一次将数据从企业数据库复制到移动设备时，设备和企业数据库都拥有相同的信息；不过，不久这两个数据库拥有的信息便会不同。用户方的活动可能会导致设备上的数据发生变化；类似地，整个企业其他地方的活动可能会导致企业数据库中的数据发生变化。您需要决定应用程序如何将设备数据库与企业数据库进行同步，以使两个数据库恢复到一致的状态。

　　没有一种策略能够适用于所有应用程序，这也是 SQL Server Compact Edition 自身直接支持几种不同数据同步机制的原因。如果大部分数据更改是对设备（例如，收集信息的公用事业读表器）数据副本进行的，SQL Server Compact Edition 为这样的应用程序提供了远程数据访问 (RDA)。RDA 是一种非常轻型的数据同步实用程序，用于跟踪对设备数据库所做的更改，及在以后将同样的更改应用到企业数据库。在更为复杂的情况下，SQL Server Compact Edition 提供了合并复制。合并复制是一种合作式的数据同步实用程序，用于跟踪对设备数据副本和企业数据副本所做的更改。

　　对数据进行同步时，设备数据库和企业数据库都会交换其各自的数据更改历史，以使两个数据库保持一致。作为数据同步过程的一部分，合并复制会经历一个更改协调阶段，在该阶段中，将对双方的更改进行审查，以确定要交换的具体数据。更改协调阶段会自动检测可能已发生的任何有冲突的数据更改，并采取相应的措施。合并复制对更改冲突的处理是完全可配置的，可以进行自定义。合并复制还包括一些高级数据同步功能，这些功能不能供 RDA 使用：后台数据同步（又称异步复制）及进度事件。可以通过后台数据同步功能启动合并复制进程，使其在后台线程上运行。这便使主应用程序线程可以用于保持响应及时的用户界面。进度事件提供有关数据同步进程状态（包括每个表更改的交换时间及更改协调阶段进度）的应用程序定期更新。

　　RDA 和合并复制都通过 Web 服务器执行数据同步过程，数据更改通过超文本传输协议 (HTTP) 或安全超文本传输协议 (HTTPS) 进行传送。通过 Web 服务器执行数据同步带来了极大的灵活性，因为这使 SQL Server Compact Edition 数据库可以在设备能够连接到 Internet 时就与企业数据库进行同步，无论是通过像 WiFi 这样的高速连接还是速度较慢的移动电话连接，都是如此。

　　如果数据存储在用户桌面计算机上单独的数据库中，而不是存储在企业数据库中，SQL Server Compact Edition 为这样的应用程序环境提供了 SQL Server Compact Edition Access Database Synchronizer (ADS)。通过 ADS，可以使用用户桌面 Access 数据库中的数据填充设备上的 SQL Server Compact Edition 数据库。SQL Server Compact Edition 数据库会自动跟踪对设备数据库所做的更改。以后将设备插入底座时，SQL Server Compact Edition 会使用 ADS 将设备数据库更改应用到 Access 数据库。

　　安全

　　移动设备的可移植性要求遵循安全实践，以确保不会危及重要信息的安全。为保证 SQL Server Compact Edition 数据库中数据的安全，SQL Server Compact Edition 支持使用密码来保护数据库和对数据库内容进行加密。创建数据库时，可以轻松地设置用于保护和加密数据库的密码。以下是一个 SQL 语句，它在 C 盘上创建名为 SafeData.sdf 的数据库，将密码设置为 P@ssw0rd，并将数据库配置为对所有数据都加密。

　　Create Database "c:\SafeData.sdf" databasepassword 'P@ssw0rd' encryption on

　　将对数据库中存储的所有数据进行加密。成功地访问数据库内容的唯一方法是在打开数据库时提供正确的密码。以下示例显示了如何在 C# 程序内以编程方式创建受密码保护的加密数据库文件。

SqlCeEngine dbEngine =
  new SqlCeEngine(@"data source=\My Documents\SafeData.sdf;password=P@ssw0rd;encrypt database=TRUE");
dbEngine.CreateDatabase();

　　除了提供安全数据库内容之外，SQL Server Compact Edition 还在使用 RDA 或合并复制与企业数据库进行同步时提供安全数据交换。RDA 和合并复制都支持通过 Internet 与后端数据库进行交换时，使用 HTTPS 对更改历史数据进行加密。

　　AJAX
　　Windows Mobile 6 具有更新版本的 Microsoft Internet Explorer? Mobile，其中包括运行基本 AJAX 应用程序时所需的 XML DOM 和 JavaScript 支持。这使您可以利用现有 ASP.NET、XML 和 JavaScript 技能来构建在 Windows Mobile 6 设备上运行的、功能丰富的基于浏览器的应用程序。

　　注意：

　　计划于 2007 年 5 月 1 日发布的 Windows Mobile 6 SDK Refresh 包括支持基本 AJAX 应用程序的 Windows Mobile 6 仿真器映像。

　　简化应用程序部署

　　将应用程序部署到最终用户后，才能说它是成功的。部署应用程序和为该部署过程提供支持非常耗时，而且可能会对可以用于开发新功能和应用程序的时间产生显著影响。Windows Mobile 6 纳入的许多增强功能可以减少您在管理和支持应用程序部署上花费的时间和精力。这些增强功能降低了应用程序部署的总成本，通过减少您在管理和支持应用程序部署上所花费的时间，Windows Mobile 6 让您可以有更多的时间来为应用程序添加功能和创建新的应用程序。

　　需要安装的软件更少

　　Windows Mobile 6 通过在每个 Windows Mobile 6 设备的 ROM 中加入 .NET Compact Framework 2.0 SP1 和 SQL Server 2005 Compact Edition，简化了托管应用程序和自用应用程序的部署。在 ROM 中提供 .NET Compact Framework 2.0 SP1 和 SQL Server Compact Edition 大幅度简化了应用程序的部署，并降低了为成功安装应用程序而必须为最终用户提供的支持级别。

　　在 ROM 中提供 .NET Compact Framework 2.0 SP1 和 SQL Server Compact Edition 的益处有很多。您拥有了一个定义明确的目标平台，它确保这些核心软件组件始终存在，且始终得到正确的安装。应用程序安装软件包的整体大小仍然较小，因为它仅包含应用程序组件。较小的安装软件包的下载和安装时间都较短，这简化了应用程序分发和应用程序更新的分发。较短的安装和下载时间还为改善用户体验创造了条件。

　　除了用户、部署和支持体验得到改善外，在设备 ROM 中安装 .NET Compact Framework 2.0 SP1 和 SQL Server Compact Edition 还为给应用程序提供更好的运行时环境创造了条件。将 .NET Compact Framework 2.0 SP1 和 SQL Server Compact Edition 安装在设备 ROM 中，这样它们便不会占用设备 RAM 的空间。减少在 RAM 中安装的软件为应用程序留出了更多的 RAM 空间来存储数据。

　　对基于 URL 部署的支持
　　

　　为 Windows Mobile 6 上的 Internet Explorer Mobile 添加基本 AJAX 支持提供了新的应用程序分发途径。对于适合使用基于 AJAX 的解决方案的应用场景，只需以电子邮件发送相应的 URL 便可对应用程序进行部署。用户接收到该 URL 时，只需使用 Internet Explorer Mobile 浏览到该 URL，而不需要在设备上安装其他软件，因为 Internet Explorer Mobile 已具备了运行基本 AJAX 程序所需的一切条件。

　　代码签署得到了简化

　　Windows Mobile 安全策略的一个重要方面是使用证书来签署应用程序可执行文件和安装文件。在较大的应用程序中，正确签署应用程序可执行文件和安装文件的过程可能很冗长。新的 CodeSignTool 实用程序（本文前面提到过）让您可以通过执行一个命令来签署所有必需的文件，从而显著减少了签署应用程序安装文件的工作量。

　　构建一个在许多设备上运行的应用程序

　　Windows Mobile 设备的灵活性及强大的可编程性使得越来越多的人使用它们来实现各种目的。由于用途是如此的广泛，因此没有一种设备外观造型能够适用于所有人。为满足如此多样的用户需求，Windows Mobile 设备提供有多种外观造型。表 4 显示了部分常见的 Windows Mobile 设备外观造型。

表 4. 常见的 Windows Mobile 设备外观造型
尺寸	分辨率	触摸屏
176x220	96 dpi	无
240x320	131 dpi	无
320x240	131 dpi	无
320x320*	128 dpi	有
240x320 / 320x240	96 dpi	有
480x640/640x480	192 dpi	有
240x240	96 dpi	有
480x480	192 dpi	有

　　

　　* Windows Mobile 6 中新增的分辨率

　　由于有这么多种类的外观造型可以使用，因此您必须确保所构建的应用程序能够适应设备外观造型的差异。您需要记住的是，Windows Mobile 设备支持的外观造型列表的内容正在不断得到扩充。Windows Mobile 6 包括许多新的功能和资源，目的是减少构建能够轻松地适应外观造型差异的应用程序所需的工作量。您将会发现，Windows Mobile 6 使得既能利用每个设备的特定能力，又能在多种设备外观造型上顺利工作的应用程序的构建变得前所未有的简单。

　　注意：

　　320x320 显示外观造型引入了一个新的分辨率和与之前外观造型略有不同的显示区域。请确保在您的应用程序测试中包括这个新的外观造型；否则，它与其他外观造型的差异可能会导致应用程序在采用该外观造型的设备上显示时遇到困难。

　　遵循安全最佳实践

　　最初的 Windows Mobile Pocket PC 设备包括的设备安全功能非常少。随着该平台的成熟，其安全性也日益提高。改进 Windows Mobile 平台安全性的趋势可能还将继续下去。为了最大限度减少与未来版本 Windows Mobile 的兼容性问题，现在就应着手将仅有的几个安全最佳实践整合到您的应用程序中。

　　您的应用程序应只向应用程序可执行文件所在的文件夹或“我的文档”文件夹写入内容。在未来的某个时间，可能需要具备特殊权限才能向这些文件夹以外的文件夹写入内容。 写入注册表时，只向 HKEY_CURRENT_USER 配置单元写入内容。与文件系统类似，在未来的某个时间，可能需要具备特殊权限才能向注册表的其他区域写入内容。

　　在所有设备上都统一的 API 集Windows Mobile 设备提供了在所有 Windows Mobile 设备上都统一的 API 集。这是一个关键因素，它使构建能够在所有 Windows Mobile 设备上工作的单一应用程序可执行文件变得切实可行。在所有 Windows Mobile 设备上，Win32? API 和 .NET Compact Framework 2.0 都是全面和一致的。拥有一致的 API 集减轻了为不同设备类型管理和分发单独的可执行文件所需进行的工作。

　　确实需要做特殊考虑的一个领域是设备显示，本部分的其余内容将对此做专门介绍。

　　设备仿真

　　设备仿真器是开发能够在不同外观造型设备上成功运行的应用程序的最重要工具之一。借助于设备仿真器，可以在许多不同外观造型的设备上测试应用程序而不必访问采用这些外观造型的物理设备。Visual Studio 2005 和 Windows Mobile 6 SDK 提供的仿真器映像加在一起超过了 25 种，让您可以在多种外观造型的设备上全面地测试应用程序的行为。有关该仿真器支持的众多设备外观造型的示例，请参阅图 15。

图 15. 几个设备仿真器外观造型示例