离线应用的一种设计方案
简介
所谓离线应用，就是在离线时能够把数据存储到本地，在线时同步到服务器上。HTML5提供了程序缓存和本地存储两种机制来实现， 可以用cache manifest和indexedDB来搜索相关内容。各个浏览器对此支持都不太一样，本文尝试出一种可行的方案。
程序缓存
程序缓存比较容易设置，只要写一个.manifest文件，再把它写到html元素的属性就可以了。我遇到的一些问题：
- Firefox13有提示缓存，但是离线之后看不了。Chrome19成功了。
- 没有测试动态文件缓存例如.php，感觉即使保存下来，也就和浏览器离线浏览差不多。
- 开启缓存之后，外链的音乐文件chrome19就不认了。
- 有些第三方服务不能缓存，例如百度地图，需要在离线应用设计中加以考虑。
因此对离线应用而言，我认为程序缓存的作用就是保存静态文件。
本地存储与数据库
据说浏览器限制本地存储为5M，所以就不考虑了。主要是利用浏览器支持的indexedDB来完成数据操作。
数据流/对象交互设计
浏览器中的视图view一般直接从服务器中存取数据。考虑了离线应用之后，需要加入一个中介mediator，如上图所示，为视图屏蔽掉在线与离线的区别，简化视图设计。在此有两者实现方式：
1. 以原有的在线方式为主，在原有的数据流上开分路。好处是不改变原有的数据格式，不中断原来网站的运行。
2. 以离线方式为主，无论在线与否，视图都只对indexedDB进行数据存取，在后台进行indexedDB与服务器的数据复制replication。
方式1的测试成本要比方式2高一些。方式1要测试视图到服务器，视图到indexedDB和indexedDB到服务器三条路径。方式2只要测试视图到indexedDB和indexedDB到服务器两条路径。因此我选择了方式2。
数据复制replication
视图到indexedDB的数据存取理论上是比较容易的，实际上有很多莫名其妙的地方。这里只讨论数据复制。需要考虑的是数据的版本控制。
- 复制前没人改过数据，本地数据版本与服务器版本一致，开启数据复制过程。
- 复制前有人已经改过数据了，本地数据版本比服务器版本低。此时可提示用户选择如何进行数据操作。这种情况我没有测试。
复制过程需要考虑数据表中每一条数据的状态，其转换图如下：
- C本地新加入的数据
- R从服务器加载，未改过的数据。
- D从服务器加载，本地删除的数据
- U从服务器加载，修改过的数据。
- P正在复制过程中的数据。为了不破坏复制过程的原子性，一般禁止修改与删除。
总结
从本文的方案可以看出，离线应用的难题在于本地数据与服务区数据的同步，最好能得到浏览器的支持。
