| 2008年01月25日 16:18 | |
智能升级:移动中的信息更新 [PDF 86KB]
摘要
目前,外出员工与公司数据库之间的通信越来越依赖无线接入点设施。但是,收发数据需要足够可靠的互联网连接作保障,因此要完成工作就不得不忍受漫长的网络延迟,这无疑会降低员工的工作效率。通过为应用添加本地直写/脱机缓存,员工便可实现软件的用户控制,同时应用也可在没有人为监管的情况下,在接入互联网时实现畅通的服务器通信。现在,利用英特尔® 移动平台软件开发套件 1.2
就可实现这些功能。
随着无线连接技术的出现,越来越多的企业开始选择通过客户、员工和远程信息数据库之间的“即时”通信来处理日常操作。想象一下,当您的管道工人修理完渗漏水槽后,打开笔记本电脑,输入工作时间并将信息发送到公司数据库,这该是多么地简便快捷。但如果他不能连接到数据库呢?或者是数据已发送,但是连接中断,导致他不能收到确认信息呢?这就需要有一个高效灵活的应用,来流畅处理这种利用无线接入实现信息交换过程中的不可预测性。
借助英特尔® 移动平台软件开发套件 1.2 的应用编程接口(API)配合一个脱机缓存的实施,程序便可轻松应对多变的无线连接情况,从而支持用户正常工作,安枕无忧。
让我们通过一个实例来看一看具有该功能的应用是如何工作的。Sally 是一位医药供应代表,她的工作职责是向美国西海岸地区的各大医疗诊所销售药品。每完成一笔销售,她都需要向公司数据库发送相应的购买定单信息。Sally 需要尽可能快地完成订单发送,以确保库存信息保持最新。
如果附近没有可用的无线接入点,Sally 就不得不花费宝贵的时间来寻找信号较强的地方,在此时间内她本可以再完成一笔销售。借助以下将讲到的智能更新方案,她的应用得到了增强,这时她指示应用程序来发送销售数据至总部。该应用会提醒她目前无法实现互联网连接,但是数据将在有可用网络时尽快发送。于是Sally 开车前往下一家诊所。途中她经过了一个信号较强的无线接入点。仅在几秒钟之内,她的电脑便完成了登录,程序将她的信息发送到了总部。Sally 到达下一家诊所时,她的库存量已经完成了更新,应用也已做好准备接受她的下一份定单。
现在让我们来看一看接下来该如何实施。
图 1 所显示的改进的工作流能够更好地处理脱机活动。为了设计一项能够自动监控互联网连接与数据发送情况的程序,我们需要一条后台线程。该线程的主要功能就是检查连接互联网的情况,并在连接可用时发送所有现有已就绪的数据。将这些功能从主应用线程中分开后,主应用线程便可继续处理用户请求,而收发数据则可由后台线程完成。首先,主线程将数据保存在缓存结构中。
为什么这项工作要在检查连接前完成呢?正如简介中已经提到的:互联网连接可能会在程序发出数据后突然断开。因此一旦发送失败,此举可依靠缓存再次发送数据。
图 1. 智能升级计划的主要数据流
后台线程最初会处于空闲状态,等待数据添加到缓存中。这一方法适用于互联网连接需求较低的情况,例如,前面提到的水管工人在每次完成工作后记录其工作时间。在网络连接需求较高的情况下(或者大多数情况下),后台线程则可简单设置为持续监控互联网连接模式。对于本概述而言,网络连接需求较低。当缓存空闲时,后台线程将创建一个 ConnectivityInstance 例程,并利用例程属性 IsConnected 来检查有效的互联网连接。如果已建立了连接,那么可先利用 IsReachable() 来确认连接建立,然后将数据将从缓存发出。每次数据传送都将经过成功检测。如果没有收到数据库确认信息,后台线程将返回循环操作的起点,等待网络连接的出现。收到成功传送确认后,缓存内的数据将被移除。一旦缓存中没有任何数据存在,后台线程将断开已建立的连接,并等待缓存中出现新的项目。程序退出前,后台线程被关闭。
安装“网络感知”应用的一项关键要素便是针对需要发出的信息创建脱机缓存。缓存可以是一份简单的杂凑表(hash table),或是一张用于在成功连接数据库之前存储数据的连接列表(linked list)。由于数据会在任何时候尽快写入数据库(而不仅仅是被清出缓存的时候),因此要采用直写缓存(write-through cache)。但是在网络连接不可用时,这一存储方式可用作长期存储。但是,长期存储数据又会带来另一个问题。如果用户请求一个已经修改并存储在等待互联网连接的缓存中的数据点,那么就应在该请求添加到缓存之前搜索缓存内容。如果请求的数据可用,即可本地检索数据,无需考虑网络是否连接。此外,还可有效使用连接列表(linked list)来确保对正确的订单进行数据库更新,以及轻松查找先前存储的数据。
英特尔® 移动平台软件开发套件 1.2
包括了本案例概述中提及的所有功能。该 API 旨在改善移动设备的“间断性”连接状态。同时,该 SDK 还属于开源项目,因此可以研读其实现代码来了解具体细节。其部分连接代码基于微软公司的 Windows Socket 2 API
。英特尔还开发了多项易于实施的对象与方法,可快速添加到独立的应用当中。此外,这些代码应用示例还支持 C++、C# 与 Java 语言。我们还在技术文档文件目录中附有一份程序员指南,作为开发过程中的有益参考。
当然,Windows Socket 2 API 也可单独用于代码编写。为了能够使用 Winsock 2 的所有函数,您需要根据所需开发的代码类型,结合 Winsock2.h 库或 Ws2_32.dll 动态链接库文件一起使用。在实际操作中,您可能需要用到多个函数,以下是一些常用函数:
|
查看 Windows Socket 支持是否可用且就绪。 |
|
|
判断是否存在某种类型的互联网连接并返回一个句柄。 |
|
|
检索有关当前所有可用连接的信息。 |
|
|
释放 WSAStartup 返回的句柄。 |
|
|
停用 Winsock 2 DLL 文件。 |
|
|
在 WSALookupServiceBegin 或 WSALookupServiceNext 函数执行后使用,从而在连接发生改变时通知观察人员。一旦收到此类事件,WSALookupServiceEnd 便会调用以释放句柄。 |
以下是本文推荐函数的伪代码。它向您详细展示了如何通过三个后台线程函数与两个主线程函数来实现智能更新。这些代码与图 1 中显示的数据流图表是一致的。
如果需要发出的数据是在请求数据点,那么应当首先查看数据点是否存储在缓存中。如果是,应立即通知程序,以便调用另一个函数来检索数据点并将其返回给用户。以下 SearchCacheForDataRequested 函数可直观展示这一过程:
接下来列出的是后台线程函数。第一个函数包含在线程运行函数之中,即检查停止、运行与重置事件的函数。
后两个函数用于处理“数据发送”和“移除成功发出数据”事件。
有关通过互联网处理数据同步与更新的问题,至今已有众多观点和解决方案。Google 为此推出了 3 个模块,统称为 Google Gears
,可为这一问题以及其它相关的网络应用提供解决方案。我们鼓励用户积极寻求所有可行的方式与手段,以找出符合其目标的最佳答案。
该解决方案并未将处理移动应用与远程服务器通信时的所有可能场景都考虑在内。此外,虽然随着接入点数量的增加,出现两个或两个以上不同来源连接的可能性也会增长,但是该解决方案并不包括同时处理多个互联网连接的情况。另外两个未做考虑的情形是:程序正在关闭时如何处理缓存中的数据,以及数据库如何同时处理多个用户对同一数据的更新。后一个问题的解决方案不止一个,并且已经超出了本文的讨论范围。同样,从应用内部成功地接入网络,以实现无线互联网连接的场景也没有涉及。
许多数据库应用都采用管理代码,如欲了解更多的 Windows Socket 2 函数详细示例代码,请参阅有关 Windows XP 的网络说明
。此外,该文章还详述了您在运行 Winsock 2 DLL 文件时可从每个可能的网络连接上获得的全部信息。
本文介绍了一种便于移动人士实现轻松数据库信息交换的方法。微软公司的网络位置感知 API 有助于我们更好地检测运行应用内部的连接状态,无论是有线联网还是无线联网。这种能力为智能更新计划提供了重要基础,即在互联网连接时发送数据,在移动设备超出接入范围时将数据存储在缓存中。
“网络感知”应用可在找到新的连接并获准接入网络时立即将数据存入缓存。借助该应用,用户无需四处寻找理想的网络信号,即可在前往下一地点前发送数据,从而节省了大量宝贵时间。这样一来,计算机便能够为移动人士带来真正实惠,而非制造麻烦。
Judy M. Hartley 是软件与解决方案事业部的一名软件应用工程师。她于 2001 年获得了弗吉尼亚理工大学的计算机工程学士学位,毕业后不久便来到了 3000 公里以外的亚利桑那州钱德勒市,开始为英特尔效力。作为产品开发工程师,她主要负责机顶盒芯片的测试与生产准备。由于习惯家乡的气候,她于 2005 年调到了英特尔位于美国西北部的一家办事处,并投身于软件与软件支持方面的工作。

