Just do it!

去想,去做,去努力,去奋斗,自己的未来是由自己改变的.
posts - 72, comments - 269, trackbacks - 7, articles - 0
  博客园 :: 首页 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理

我看windows mobile数据同步方案

Posted on 2008-05-05 17:09 JustDI 阅读(231) 评论(8)  编辑 收藏 所属分类: windows Mobile
       距离上篇博客似乎又过了一段日子了,这段日子应该算是挣扎着过来的,从寻找同步错误的过程到使用新的解决方案,总共花了近3个星期,我想自己有必要总结下这次的经历。

      项目是使用C#+VS2008开发的,客户端数据存储采用SQL SERVER Compact Edtion 3.5,主要想应用在windows mobile 5.0操作系统及以上的手机。对于客户端和服务器端的数据同步,最初我们讨论了好几种方式,主要包括RDA,合并复制,webservice写XML文件或SQLCE。RDA使用起来虽然简单、灵活,但因为其没有冲突处理机制及跟踪增量更改于是被第一个放弃.webservice写XML文件或SQLCE,我们粗粗估算了下,除了要另外建表外,没有个几千行代码就搞不定的,这又背离了我们开速开发的宗旨。而且我们也无法保障使用webservice写XML的效率。因此我们选择了代码量少,配置繁琐的合并复制。

      程序的开发用了大约一个月左右,模拟器上调试均OK,将serverTool公开到外网,但发布到手机上了才出现A request to send data to the computer running IIS has failed的错误,因为那时候正准备将开发的结果展示给领导看,但这个错误却是意料之外的,这个错误是指示数据连接超时,当然了数据连接超时的原因有很多,而查找这个原因的过程更是让人抓狂。起先还以为是网络连接超时造成的,遂将数据删除得只剩一条,但还是出现错误。于是将原因归咎到了IIS访问用户的权限,于是乎又将快照及复制及虚拟目录的权限均设置成最高。还是出错。最后将原因归到了合并复制的配置过程上了,于是重新配置了遍合并复制,还是这个错误。没辙了,中间还使用过RDA来进行数据同步,但到了手机上还是这个错误。后来一个同事将手机连接到家里的网络,随意地点了下程序,发现可以。于是终于发现错误的源头在CMWAP的代理上网方式上。

      百度了下GPRS网络,发现中国移动提供了两种上网方式,一种是CMWAP的上网方式,采用10.0.0.172:80代理服务器,这种上网方式有些限制,首先,只有满足以下两个条件的应用才能在中国移动的cmwap接入方式下正常工作1、应用程序的网络请求基于http协议;2、应用程序支持http代理协议或wap网关协议。还有种是CMNET,这种方式没有任何限制,与我们普通的PC机上网一样,可以随意地访问各类型的网站,但这种方式的缺点是上网贼贵,在我们这边是20元50M每个月,超过了按3分/K算,如果没有超过还好说,假如超过了。。。假如一首歌是4M,那么额外的你就得支付4*30=120元,汗呀..看来不能强求我们的用户使用这种方式上网了。我们只能寻求另外的解决方案。

      不知道有没有其他朋友使用合并复制成功地同步过数据,忘了加一个条件就是使用CMWAP上网方式。至少我失败了,在各大论坛发帖求助,及疯狂地向国内知名的windowmobile专家发送邮件,甚至我的同事还将问题翻译成英文发送给window mobile小组,但均得不到满意的答案,这里我也感觉到了windows mobile移动应用在国内实在是太少,或许是局限于国内的移动网络。

      希望这篇文章能给同样遇到此问题的您带来一点帮助。好在我们现在寻找到了我们的替代方案,就是使用微软最近才推出的Sync Service,因为是使用WebService做代理中间层,因此CMWAP的限制解决了。以后的文章中会介绍关于这个框架的使用心得,感觉速度还可以接受,第一次同步时(包括表结构及)花了35s,普通的同步12~13s之间,当然,这个数据只是针对的,在不同的手机和网络条件下不一样,仅做参考。

      ps:这么看似乎前面的合并复制的翻译白写了,其实不然,因为我们的同步方案并不一定使用移动的网络,比如说桌面应用程序,具体还是要看应用了。

Feedback

#1楼    回复  引用  查看    

2008-05-05 17:37 by fox23      
支持~
继续加油,突然发现我已经远离数据库很长时间了 :-)

#2楼    回复  引用  查看    

2008-05-05 19:20 by 黎波      
可以Sync Service for ADO.NET结合SoapExtension压缩来降低数据流量和提升速度。
我个人的体会是:编码量少的很难控制,编码量多的粒度可以控制得很细。

#3楼 [楼主]   回复  引用  查看    

2008-05-05 19:56 by JustDI      
@fox23
Thanks,等以后数据库这块稳定下来就可以静下心来专攻程序了,UI层现在惨不忍睹呀。

#4楼 [楼主]   回复  引用  查看    

2008-05-05 19:58 by JustDI      
@黎波
谢谢指导,会去应用webservice压缩的,编码量少的向合并复制这样的出了问题只能找微软,而编码量多的如sync service出了问题就可以找自己了。

#5楼    回复  引用  查看    

2008-05-05 22:12 by AppleSeeker      
@黎波
我看了国外大牛的一些文章,对于软件的结构和设计是美好的,但是对于具体实现,就有点差距.我还是非常希望看到MS能够将Sync service更加强大的。

随着计算机的发展,移动设备的硬件却制约着软件的发展阿~~~

#6楼 [楼主]   回复  引用  查看    

2008-05-06 08:22 by JustDI      
@AppleSeeker
能讲下Sync service现在的瓶颈在哪吗?

移动设备的硬件的瓶颈现在电池上,电池如果没有突破一个新的境界,移动设备的处理速度也难以得到一个好的发展。

#7楼    回复  引用  查看    

2008-05-07 10:37 by 木野狐(Neil Chen)      
移动设备的存储量会如何?
是否做这样的开发只会同步中央数据库中很少的一部分数据呢?

#8楼 [楼主]   回复  引用  查看    

2008-05-07 10:46 by JustDI      
@木野狐(Neil Chen)
一张2G左右的存储卡也只要不到300块钱,而且容量现在在不断上升,价格还是不断下降,因此移动设备的存储量现在已经没有什么限制了。

同步的时候做了过滤,因为到了每个客户端那的数据量就不是很多了。2000多条的正常的记录加上表结构差不多400K左右,表结构占了100多K。

标题  
姓名  
主页
Email (只有博主才能看到) 
验证码 *  看不清,换一张
内容(请不要发表任何与政治相关的内容)  
  登录  使用高级评论  新用户注册  返回页首  恢复上次提交      
该文被作者在 2008-05-05 17:21 编辑过