SyncML 规范可能会有所帮助,但它很难阅读并且明显偏向于 SyncML。
我不得不为 Task Coach 实现这个,所以这里有一些想法:
修改标志就足够了,时间戳并不能真正提供更多信息。通常,我的对象处于以下状态之一:
修改对象时会发生以下转换:
- 无 -> 修改
- 新 -> 新
- 已删除->(不应该发生)
- 修改 -> 修改
以及删除时的以下内容:
- 无 -> 已删除
- 新 -> 实际删除(可能从存储中删除)
- 已删除->(不应该发生)
- 修改 -> 删除
同步时,设备首先将所有状态不是“无”的对象发送到桌面。如果其中一个的状态为 != None,桌面会要求用户解决冲突。在任何情况下,对象都会在设备上进入状态 None,或者如果其状态为 Deleted,则从存储中删除。
然后,桌面将自己的更改发送到设备。由于设备上的所有对象都处于无状态,因此不会发生冲突。桌面上的对象进入无状态或从存储中删除,同步结束。
根据设备/桌面状态,有两种可能的冲突:
- 修改/删除。如果用户选择信任设备,则桌面对象被设备替换;否则,桌面不做任何事情并保持已删除状态,以便在阶段 2 中将对象从设备中删除。
- 删除/修改:如果设备获胜,则该对象实际上已从桌面删除。否则,对象会在桌面上进入状态 New 以便在阶段 2 中在设备上恢复。
- 删除/删除:呃。只需将其从存储中取出。
- 修改/修改:用户决定保留哪些值,可能在逐个字段的基础上。状态在桌面上保持为已修改,以便这些选择在阶段 2 中传播回设备。
如果为每个字段保留已修改状态,则可以避免一些冲突,例如,在设备上具有修改的主题和在桌面上修改摘要的对象不会触发冲突。
您可以查看 Task Coach 的代码作为示例(SourceForge 上的 SVN 存储库,它具有 Python 桌面应用程序和 iPhone 应用程序)。实际上,在这种情况下,我决定使用更简单的方法;我不跟踪桌面上的状态。在第 1 阶段(设备到桌面)之后,我只是将设备上的对象完全替换为桌面上的对象。因此,没有冲突(设备总是获胜)。
显然,这只适用于两个固定设备之间;如果您想与多个手机/桌面应用程序同步,则必须为每个应用程序分配一个唯一的 ID,并为不同的设备/应用程序保持不同的状态。这可能会开始变得多毛。
高温高压