谢国坤, 霍爱清, 汤 楠
(西安石油大学陕西省钻机控制技术重点实验室,陕西西安710065)
Vcard[1]也称为电子名片,是一种交换个人信息(如姓名、地址、电话号码和电子邮件地址)的简单方法。Vcard规范可作为各种应用或系统之间的交换格式,且这种格式与传递的方式无关。符合Vcard规范的文件可以在文件系统、点对点交换的公共电话网络、以有线网络或无线传递等方式进行交换。由于Vcard文件具有如此出众的优点,现在越来越多的应用软件都选择支持 Vcard功能来实现联系人或日程表信息的本地存储。如何将 Vcard文件的数据解析出来存放到不支持Vcard数据的单板中就显得十分重要,是一个有待解决的问题。
某软件的用户界面是采用Vcard3.0规范来保存联系记录的,而绝大多数型号的单板又不支持Vcard格式。为了解决这一问题,在分析了直传单板方式、AT命令写单板方式基础上,提出并设计了SDK层直接解析转换方式,即在SDK层对Vcard字符流进行解析,并转换成Vcard对象模型,动态拆分成AT命令并分段下发给单板,实现了Vcard字符流的解析存储。该方案既满足SDK层作为工具集的设计原则,又可以不依赖于单板型号,给第三方的UI用户界面提供了更强的功能集合。该方案的设计原则是首次使单板在不改变其硬件结构的基础上,具有了存储Vcard数据的能力,通过SDK层的适配作用,使单板作为底层存储介质,可以支持更多样化的用户界面,具有非常广泛的应用前景和市场价值。
对于每一条联系人记录来说,用户界面通过接口参数传下来的是标准的Vcard3.0字符流。基于这个原因,可以采用在SDK层对数据不做任何解析,直接透传到单板上,单板将该条记录形成一个文件进行存储[2-3]。这种做法的优点就是SDK层和单板对Vcard均不做出任何解析,不用增加额外的代码,以文件的形式保存到单板的Flash中,每个文件都有一个唯一的索引进行标识。在用户读取的时候可以直接将文件中的Vcard字符流上传给界面,由界面显示成联系人记录格式。该方法的缺点也是显而易见的,以文件的形式直接进行存储牺牲了高通平台的电话本的读写响应速度 (通常对单板的读写性能都有着较高的要求,一般单条记录的读写时间不能超过240ms)。
为了解决记录读写效率的问题,决定记录内容的存储还是要交给高通平台提供的电话本实现机制,可以利用电话本的备注字段进行Vcard字符流的存储[4-5]。这样对Vcard字符流也不需要做任何解析,通过AT命令写到单板上,并利用单板提供的索引标识每一条记录,SDK和单板均不需要额外的算法开销,易于实现,并且存储效率很高。但是有一个致命的缺陷,那就是AT命令固有的长度限制。AT命令通过通信端口传输数据包,包的大小是有严格限制的,对于AT的发送除了AT两个字符外最多可以接受260个字符,终端设备主动上报的消息或者用户请求相关(userrequestcorrelation,URC)最大长度都限定在668个字符范围之内,而用户界面传下来的字符长度完全是随机的、未知的。
考虑以上两种方案的不足,提出采用在SDK层对Vcard字符流进行解析,并转换成Vcard对象模型的方式。根据单板所能支持的字段数量和顺序动态合成AT命令,同时为了避免AT超长,对电话本的读写命令进行了扩展,每次只下发4个字段的内容,并标识这条记录一共被拆分成多少条,当前AT内容属于第几条,类似于长短信的拆分方法。这种方法的优点是单板方面改动较少,完全保留了高通平台的电话本存取机制,记录读写的效率也是非常高。当然也存在一定的缺点,那就是 SDK层要增加解析 Vcard文件的算法,并且要建立Vcard字段和单板字段的映射表,动态组成AT命令下发单板,而且要对现有的读写命令进行扩展。但是这些算法的开销还是很值得的,这部分可以封装成一个动态库,用于扩展SDK的功能。只要单板支持扩展的AT命令,那么就可以给任何使用Vcard保存联系人的第三方UI软件提供无缝集成。下面以增加一条联系人记录为例,给出从界面到单板的处理流程[6-9],如图1所示。而读取过程就是该流程的逆操作,本文将不再赘述。
为了避免AT超长,对电话本的读写命令进行了扩展,每次只下发4个字段的内容,并标识这条记录一共被拆分成多少条,当前AT内容属于第几条[10-13]。
图1 从界面到单板的处理流程
扩展读取命令AT^CPBREX,命令格式及响应如表1所示。
表1 扩展读取命令AT^CPBREX
扩展写入命令AT^CPBWEX,命令格式及响应如表2所示。
表2 扩展写入命令AT^CPBWEX
结合增加一条联系人记录的实例,对所做设计进行具体阐述。
将一条记录写到单板上步骤如下:
步骤1 假如用户从接口参数传下来Vcard字符流如下[14]:
BEGIN:VCARD
VERSION:3.0
FN:Joe Smith
TEL;TYPE=CELL:+13913131212
TEL;TYPE=HOME:949-362-2399
TEL;TYPE=WORK:029-88886666
X-WMC-MOBILE-2:949-555-1212
TEL;TYPE=FAX:949-362-2300
EMAIL:jsmith@smith.com
X-WMC-EMAIL:joe.smith@smith.com
UID:{4421FEE4-A25D-11D3-9F7C-005004AE6818}
步骤2 使用扩展的读取命令获取单板所支持的字段列表和字段长度,该命令的上报应该以OK结尾,由于所有的字段名称都做了缩写处理,所以单条AT足以上报所有单板侧所支持的字段类型,命令格式如下所示:
AT^CPBREX=?
^ CPBREX:(1-500),”FN”,32,”CELL”,48,”HOME”,48,”WORK”,48,”EM”,48,”XWEM”,XWGD,5
OK
步骤3 建立单板侧上报字段与用户界面支持的 Vcard字段对应的映射表,如表3所示。其中以X-WMC开头的是自定义的字段名称。将步骤1中传下来的Vcard字符流转换成Vcard对象模型,包括解析用户自定义的字段。
步骤4 过滤掉单板侧不支持的字段类型,按照单板上报的字段顺序从对应的Vcard对象中获取数据,构造出即将下发的AT结构[15]。就本例而言需要获取姓名、手机号码、家庭号码、办公号码、电子邮件、扩展电子邮件和群组编号这7个字段内容。然后每4个一组分段下发,其中字段编码内容是可缺省的,每下发一条写命令如果成功,单板侧需要上报一个OK响应,必须拆分的每条命令都返回OK,这条记录才算保存成功,否则按保存失败处理。写命令的执行流程如下所示:
AT ^ CPBWEX:3,2,1,”80534E4E3A”,1,”+13913131212”,2,”949-362-2399”,2,”029-88886666”,2
OK
AT ^ CPBWEX:3,2,2,”jsmith@smith.com”,1,”joe.smith@smith.com”,1,”4”,2
OK
至此一条记录就被写到单板上了。
表3 单板侧上报字段与Vcard字段对应的映射
在不改变单板存储结构以及存储方式的基础上,无需实现Obex协议或Diag协议的前提下,通过建立Vcard对象模型以及AT命令的扩展,实现了Vcard数据的动态字段解析和存储。整个过程大部分工作都是放在SDK层来完成的,单板侧只需要支持扩展的AT命令即可,而用户界面无需做任何额外的改动。这种方案符合了SDK层作为工具集的设计原则,在不依赖于单板型号的同时,给第三方的UI界面提供了更强的功能集合。
[1]Cronin.From victorian visiting card to vcard:the evolution of a communicative genre[J].Journal of Information Science,2003,29(1):65-68.
[2]孙鹤飞.基于IMS的双模智能手机的设计与实现[D].西安:西北大学,2008.
[3]Deitel H M,Deitel P J.C++编程金典[M].周靖,黄都培,译.北京:清华大学出版社,2002.
[4]CN101237610,基于点还本分组的短信息发送方法和移动终端[P].中兴通讯股份有限公司,2008-08-06.
[5]蔡东.基于BREW平台的CEMA移动终端电话本的研究和实现[D].西安:西安电子科技大学,2008.
[6]Gary JBronson.C++程序开发与设计[M].刘勇,译.北京:人民邮电出版社,2002.
[7]刘天印,李福亮.C++程序设计[M].北京:北京大学出版社,2006.
[8]Andrew Koenig,Barbara Moo.C++沉思录[M].黄晓春,译.北京:人民邮电出版社,2008:133-150.
[9]赵清杰.C++程序设计 [M].北京:清华大学出版社,2008:183-193.
[10]深圳市森森科技发展有限公司.AT指令集[Z].4-5.
[11]华为技术有限公司.GTM 900 AT命令手册Version 1.12[Z].2007:40-56.
[12]李志伟.基于AT指令的串行通信程序的设计[J].微计算机信息,2007,23(3):272-274.
[13]李佳.一种数据卡PC侧收发AT命令模块的实现方法[J].计算机测量与控制,2010,18(6):1370-1372.
[14]杜青.Symbian OS C++编程诀窍[M].北京:清华大学出版社,2009:103-106.
[15]CN101140517,在PC软件中实现名片夹Vcard格式方法及装置[P].中兴通讯股份有限公司,2008-03-12.