Windows phone 应用开发[2]-数据缓存[转载]
2012-08-30 12:28
330 查看
今天把JDi/Server测试做完.终于有了时间来写写关于这个项目总结.关于我在博客上Post这些文章内容都是从实际项目应用而来.当然有些问题解决方案也是不断被重复设计修改.期间也碰到诸多问题.也曾为客户端在UI设计和具体的实现倍感困惑过.下午在ProductOwerUI原型设计讨论会上.设计团队针对内部一个孵化SNS项目原型设计做了三套设计方案.从IPhone到Android再到Windowsphone.顿时不禁有一个疑问.如果抛开市场定位用户群体.和业务需求等等.单单从开发人员角度来说什么样的APP才能称之为一个用户能够接受并乐于使用的呢?
在发表讨论前注意我这个命题成立条件[如上加粗字体].如果只看后半段.当然很多市场.运营甚至是最终用户都会否掉这个命题的成立条件.本篇暂且假设它是成立的.因此我在内部的Wiki上向IOS和AndroidWP团队发起一个讨论.把这个讨论结果生成一个WishList按照优先级做了排列如下:
AppWishList:
[1]:贴近用户自身实用的功能
[2]:APP自身的稳定性
[3]:良好的用户交互体验
[4]:创意
……
在发表讨论前注意我这个命题成立条件[如上加粗字体].如果只看后半段.当然很多市场.运营甚至是最终用户都会否掉这个命题的成立条件.本篇暂且假设它是成立的.因此我在内部的Wiki上向IOS和AndroidWP团队发起一个讨论.把这个讨论结果生成一个WishList按照优先级做了排列如下:
AppWishList:
[1]:贴近用户自身实用的功能
[2]:APP自身的稳定性
[3]:良好的用户交互体验
[4]:创意
……
可能这个排列对最终用户而言存在争议.在Wiki中很多人提到创意应该走在APP最前端.也就是设计阶段时应该考虑到.但是如果从开发角度而言.无论什么样的创意一旦从开发流程来执行时.并无任何差异.开发流程在每一个固定的MileStore里程碑中能够持续交付功能.并能保证整个APP自身稳定性.再次基础上建立良好的UI用户交互体验.整个APP开发使命也就算基本完成了.
如果对于Windowsphone的APP满足上面的WishList.需要注意哪些方面问题?
针对这个问题.开发者很容易陷入各种各样开发细节之中.这些细节大多是他们眼前要面对或即将要解决的问题.而无法从这些细节的泥沼之中抽身出来从整个APP全局角度来思考这个问题.那针对如上APP需要和自己理解.侧重APP稳定性和用户交互体验.可以通过以下几点来切入.
这些问题从Windowsphone一个数据列表说起.
<1>从列表说起
从一个数据列表来以小见微来说明这个问题.:在Windowsphone中目前获取动态数据列表数据方式.云端/IsolataSTorage/网络请求/Socket通信/SQLCED等.作为常见客户端而言.最多采用就是网络请求的方式来从服务器端拉去数据.在采用WebClient或HttpWebREquest方式或是云端存储涉及网络请求数据时.在Begin-End异步处理模型中应首先保证我们代码块做了正确的事.并能够在出现异常时也能正常执行流程反馈在UI上.一个APP健壮性在反馈编码上最小层级就是代码块异常处理.
但是在异常处理中很多Dev都关注程序自身功能性Bug.客户端明确定义是能够处理自身以及和外界网络发生交互时任何Exception.请求网络中断.请求超时.服务器端Server返回404NotFound.数据解析异常等等.这都需要客户端处理并UI中有所呈现.代码块的完整异常处理是APP健壮性最小单位.
对于比较常见或是不可见的异常可以通过服务器端统一过滤编码并明确返回客户端提示.这样做目的是为了保证不把程序异常直接堆栈信息暴露给用户.并采用客户端日志记录.当然在客户端异常存在某种条件下照成不可见的APP崩溃的情况.所以在UnHandlerException()方法中当APP崩溃必须退出时也得给用户一个友好的退出提示.
now.当顺利拿到数据.通过最常用的ListBox来呈现.在DataTemplate数据模板中包含文字和图片信息.在呈现文字信息之前加载时间内必须给出动态加载进度条.但注意在用户操作BackUpPress键时必要处理.
在数据呈现时.这里必须提到ListBox自身性能问题.当通过绑定ItemSource数据源时,如果呈现ObserverCollection<T>没有限定数量.会照成ListBox在UI操作发生延迟或是得不到及时响应.ObserverCollection<T>如果存在10000数据项.在后台中Silverlight必须将其实例化10000个ListItem实例项.才能通过UI呈现出现.短时间APP内存使用剧增.出现性能瓶颈.
所以绑定时数据源ObserverCollection<T>应尽可能的小的数据量20-30.尽量减少每次更新代价.如果无法避免类似在需要大型数据绑定时可以考虑在后台实现动态加载数据源方式.在数据呈现过程中请慎用ValueConverter转换器.
ValueConverter转换器慎用:
ValueConverter转换器采用自定义代码实现转换数据格式或额外操作.导致无法在实际元素呈现之前确定页面布局和数据缓存.特别是在出现大数量时ValueConverter简直就是延时器.可能导致UI线程长时间阻塞得不到响应.大大降低用户体验.请慎用!
在动态加载实现上可以参考IPhone加载数据列表的方式.当用拖拽数据列表到达底部时则动态Loading数据.尽量保证UI可操作.不要让用户把时间浪费Loading等待上.
说到这想起奇艺客户端不禁想吐槽一下[善意的:)奇艺客户端刚出第一个版本时通过首页进入到在Pivot枢轴呈现的同步剧场界面时[没有截到图]:
在Pivot控件中用户左右移动PivotItem页时总是提示用户Loading界面.要知道用户没有多少耐心去等待.而且用户一发生PivotItem切换是都会加载数据过程.当你在完全断开网络连接情况.在打开客户端时你会发现里面没有任何数据……这证明每次用户操作数据都是即时的.用户体验不太友好用户期望:
A:第一次可以允许进行加载数据.但当再次打开界面应具有可操作数据.
B:每次切换PivotItem枢轴页加载等待时间这个Loading…太不合时宜了.如果已经加载过应存在客户端中.当存在数据更新时才动态更新列表数据.
so.良好的用户体验是建立在客户端数据缓存基础之上的……
<2>Windowsphoen中构建数据缓存
数据缓存对于数据列表价值主要体现在友好的用户交互体验上.所以一个健全的客户端是无法缺少一个有效缓存系统支撑的.数据缓存在客户端中主要解决两个问题:缓存解决的问题:
[1]:效率,缓存本身就是为了提高性能,不要因为缓存的原因反而减低了性能
[2]:数据的实时性,对于缓存数据的实时性,各种缓存设计都有自己的策略,比如设置过期时间、定时刷新等。具体采用哪种策略和具体的业务不无关系
相对于PC端数据缓存设计思路可选择性在移动客户端并不是特别多.主要因为移动客户端能够使用资源和用户需求都远低于Pc端Application.类似WP中能够用来支持数据存储SQLCE数据库和IsolateStorage独立存储空间.等完全没有Pc端应用程序开放性.从一个数据列表来说对缓存要求极为简单:
数据列表缓存:
A:客户端能够存数据保证每次在断开连接情况有数据可以操作.实现数据缓存
B:能够实现数据列表以动态更新.提高UI用户交互体验
针对缓存需求设计缓存如下:
如上缓存设计则采用以单一过期时间作为缓存策略.并把该缓存更新时间的选项暴露给用户选择.用户也可以清空本地客户端缓存数据:
ok.从如上设计图不难看出.当第一次发起请求时做了一方面把数据还回客户端同时在客户端建立数据缓存.当页面再次加载时检查缓存时间是否过期.如果已经过期则重新请求服务器拉取数据.并更新本地数据缓存数据.其实在设计这个缓存时.客户端缓存更新需要暴露两个接口.一个利用缓存时间策略有客户端自动更新.当然作为用户也需要把更新列表和缓存的选项以刷新的方式暴露出来例如在列表ApplicationBar下添加刷新操作:
但是总体来看这种更新缓存的方式我们来总结这种缓存设计的优缺点:
缓存设计优缺点:
A:缓存更新策略单一.更新缓存方式统一编程容易控制.能满足基本的客户端数据缓存操作.
B:在缓存时间内存在无法获取即时数据缺陷.