如何解决移动软件中的连接状态问题

原文地址： http://www.intel.com/cd/ids/developer/apac/zho/325176.htm

挑战

确保移动应用在任何连接状态下都能提供几乎相同的用户体验。目前，在全世界数万个热点地区我们都能够使用移动笔记本电脑与 Internet 连接。但即使公共网络的数量如此之多，仍无法覆盖大多数地区。真正意义上的无所不在的无线网络连接可能永远不会实现，即使在许多城区实现地毯式覆盖也非一朝一夕能够达到。与此同时，用户仍会发现自己并没有获得稳定的网络连接。在这些情况下，需要静态连接的 Web 应用以及客户端-服务器应用将失去意义。这种进退两难的局面提供了一个机遇，各个公司纷纷开发新的应用，或改造现有产品，使其适用于移动环境。

无论是否具有稳定的网络连接，移动软件应用都必须平稳可靠地运行。对于多数应用而言，失去网络连接将导致工作停滞。脱机工作时，我们头脑中始终盘算着联机时需要完成的“待处理”任务清单。而当联机时，我们又不得不考虑各项工作与那些“待处理”清单的优先级，并不时提醒自己手动收集下次脱机时需要使用的所有文档。最乐观的结果是，这套工作流方案为我们带来了很多麻烦，最悲观的结果是，它严重削弱了我们的工作能力。即使不考虑对工作效率的影响，这种方法也耗用大量带宽，对内部网络提出更高要求，增加了蜂窝连接成本。

解决方案

提供本地客户端接口，与本地数据库交互，当网络连接可用时，本地数据库自动与企业数据保持同步。 特别是，通过使用应用同步或发布-订阅模型即可获得脱机功能。例如，使用企业数据库引擎，如 Microsoft SQL Server*，您可以设置数据发布。

在客户端计算机上，可以安装 SQL Server* Personal Edition，如果使用 Pocket PC*，则可安装 SQL Server* CE。第一次对设备进行同步时，所有发布数据将下载到设备上。但在后面的同步中，仅从客户端上传已修改的数据，并仅下载所有客户端已合并的更新数据，这就降低了网络带宽要求。

相对而言，这种功能的实现比较简单。设备中保存了应用需要的数据（初始同步后），因此，无论网络连接是否可用，应用都能够成功运行。根据应用的要求，应用可能仅需要偶尔与后端数据库进行重新同步。虽然这具有一定可预测的风险（在客户端应用中使用的数据可能是过时的），但却降低了解决方案的复杂性。

还有若干种技术，可以扩展 Web 应用，以便更好地服务于经常需要脱机工作的移动用户。

• 内容高速缓存： 该技术包括门户为响应统一资源标识符（URI）（例如 Web 页地址）请求而提供的内容脱机缓存。不缓存生成该内容的代码。例如，超链接可能会引用 Java* Server Page（JSP）或 Active Server Page（ASP）。用户访问链接时，应用服务器运行生成页面内容的脚本，将 HTML 流返回客户端。缓存的就是 HTML，而不是 JSP 或 ASP。
• 代码复制： 该技术可使门户内容更加动态化。在提供内容、与用户交互以及收集和处理数据和数据存储的过程中，门户可以执行诸如 Java Servlet、JSP、ASP 等代码以及服务器控件。该技术仅将代码从门户复制到客户端。
• 数据复制： 复制客户端数据可以生成更多的交易型交互以及专门查询。借助该技术，应用可以从门户向客户端复制数据，也可以从客户端向门户复制数据，或者进行双向复制。复制时将交换并应用所有新数据和更新数据。如果数据仅在客户端或服务器上可写，则部署比较简单；而另一方面，如果多份数据之间的更新是独立的，则方案的部署比较困难。
• 仿真： 当用户在浏览器中选择 URI 时（通过在地址栏中输入统一资源定位符（URL）或单击超链接），浏览器将尝试联系 URI 指定的服务器，并通过超文本传输协议 (HTTP) 请求资源。如果浏览器无法联系服务器，浏览器将返回一个错误。

通常情况下，本地 Web 浏览器将尝试联系网络上的演示服务器。当系统脱机时，Web 浏览器将重定向至提供缓存内容的本地演示服务器（驻留于客户端）。通过使用多数浏览器支持的自动代理机制，开发人员可以轻松实现此功能。可以创建 JavaScript 函数以用于自动代理机制，该机制可动态重写所请求的 URL，然后通过网络提交请求。该函数会根据网络状态修改 URL，以将浏览器重定向至本地运行的演示服务器。

本文属于“如何使软件应用实现移动化 ” 一文中所述系列内容的一部分。