如何应对移动应用中的网络中断

IntelMobl 2007-05-17 11:09:53

挑战

设计移动应用，以透明方式处理网络中断。尽管许多设备具有内置连接性，但这并不意味着这些设备始终能够在支持网络连接的环境中运行。许多应用对实时网络连接具有内在的依赖性，但表现并不明显，只有当您试图在一台断开连接的设备上运行这些应用时才会发现。

解决方案
执行缓存的本地数据，降低离线操作的功能，满足个别应用所要求的可靠消息传递。理想情况下，所有这些要素实质上均应对用户隐藏连接状态。这一目标提出了一系列设计挑战：

数据是否应进行本地缓存以支持离线操作？
我们如何存储缓存数据以便后期上传？
当用户请求一个操作时，应用应如何处理？
离线时是否应当禁止某些操作？
我们如何执行可靠消息传递，以确保在连接恢复时可以对应用进行更新？

缓存数据和本地更新：您需要分析应用的要求，并检查所使用的数据类型。确定应用中与服务器之间相互传送数据的点。是否需要直接的服务器访问？在与服务器实现通信之前，应用能否利用缓存数据或存储更新进行可靠工作？消除这种对实时访问服务器的依赖性，还可降低对实时网络连接的依赖程度。理想情况下，无论连接是否断开，应用都应能够有效执行。

此方法的关键在于，数据并发处理方式所造成的限制。使用缓存数据即潜在地表明，您是在使用“旧的”或失效的数据。您的应用也许能够使用旧数据而不会产生问题。例如，如果数据大部分都是静态的，不会经常发生变化，那么该数据就可以缓存在此设备上。然而如果数据更新对其它系统至关重要，那么用于后期上传的缓存更新就无法被接受。

存储缓存数据有多种解决方案。如果应用使用 Microsoft .NET* 框架，就可以利用 ADO.NET 的 DataSet 对象，凭借其内置功能将数据串行处理成 XML 格式并保存为磁盘上的一个文件。您是否应使用本地数据库？对于 Pocket PC* 和 Windows* CE 设备，Microsoft SQL Server* CE 是将数据存储到本地数据库的一种解决方案。那么，离线时执行某种讯息队列系统来本地存储数据如何？或者，应用可以执行其自己基于文件的数据存储机制。您可以有多种选择。对于特定情况某些选择会更好一些。例如，如果应用需要缓存大量数据，那么与其将数据保存到基于文件的数据存储库中，还不如使用一个本地数据库。

减少的离线操作功能：设计应用时的另一个关键因素是，断开连接后功能会减少，在这种情况下应用能否正常运行。

缓存所有数据并允许用户离线进行访问，会带来什么结果？如果数据来自某些企业数据存储库，必须始终保持最新，则恢复连接后必须将旧数据上传到该系统。旧数据会使整个数据存储库无法实现同步，并可能会用设备中的旧数据重写新的关键数据。

对您应用的各功能进行分析，并确定其是否能够离开高速缓存数据运行，或者可以缓存新上传的更新数据。或者，由于其依赖于实时网络连接，您是否应该拒绝对此功能的访问。考虑一下允许用户继续使用旧数据所造成的潜在影响。此类内置于应用中的智能性，能够在离线情况下向用户提供至少一定级别的功能。这比完全拒绝访问应用要好得多。

可靠消息传递：如果应用要经常改变连接状态，则它需要某种机制来保证将更新数据上传至服务器，以及将设备上的数据刷新为最新更新数据。该应用可以使用某种无状态限制的“存储和转发”通信机制。

注意，使用 Web 服务提供可靠消息传递存在几个问题。Web 服务依赖于网络连接进行通信。如果设备未连接，则不能与 Web 服务服务器进行通信。因此，Web 服务协议内置的机制无法用于存储该数据，直到连接恢复为止；因此，您必须要对您自己的定制解决方案进行编码。

一款不提供此功能的解决方案是讯息队列。讯息队列基于“先进先出”（FIFO）规则，其中讯息（数据）以其添加的顺序存储在一个队列上。当从讯息队列检索数据时，则按数据添加的顺序进行检索。该技术允许在离线状态下将数据添加到讯息队列，并在连接恢复后以正确的顺序将其上传至服务器。无论该设备是否建立连接，数据都会以设备始终连接时的顺序上传至服务器。对更新的处理永远不会采取无序的方式。旧的更新数据永远不会覆盖新的更新数据。市场上有各种不同的信息队列系统；微软讯息队列* （MSMQ*）和 IBM MQ Services* 只是其中的两种。Microsoft .NET Framework 包括类库，支持在 MSMQ 上通信。

...全文