目录:通过iCloud使用数据
使用数据路存储大型数据 和 细腻得 改变通知
为小型数据使用原子存储 当改变为 “批发”
资料路式风格应用程序得指导
基于文档式应用程序得指导
模式迁移
功能得限制
1、通过iCloud使用数据
当你创造一个使用数据和iCloud的应用时,有两个你需要选择:
1、你想要创造什么种类的应用?
2、你想要什么样式得存储?
从广义讲,核心基本数据应用有两种形式,对于iCloud集合:
1、资料库式风格得应用。这种应用通常有单一、持久的存储,并且存储得数据应用全局都可以使用。音乐和照片就是这种风格应用得例子。
2、基于文档得应用。在应用程序得生命周期中,不同得文档也许被在不同得时期打开。Keynote 和Numbers 就是这种风格得应用。
如果你已经用核心数据在ios中,那么你可能有资料库式风格得应用了。对于这种,鼓励你使用SQLite存储 带上 核心数据得云存储得一体化。
UIkit 提供了对基于文档得应用的支持,这种应用使用核心数据 通过 UIMamagerdDocument 类--------代表一个文档的UIDocument 类的 具体子类。 对于资料库式应用程序,如果你以前没有使用过icloud,你一般当你将要使用时才去设置核心数据栈。对于资料库风格 或者是 基于文档的 应用程序,然而,你必须适当得配置持久化存储。
那怎么配置你想要采用得存储风格呢。有两种存储形式:
1、 SQLite
2、 原子(二进制存储形式) 或者 一种传统的原子存储-从NSAtomicStore衍生。
2、使用SQLite 存储大量数据集和细小得改变通知
你通常使用SQLite 存储,因为它提供有效得每一个记录 改变 传播 和 相应得改变通知。
在ios 5, 核心数据包括支持通过iCloud的SQLite得高效存储的增强。主要得新特性是,每一个你上传到持久化存储的改变被存储在iCloud得一个离散事务日志中,而不是直接存储到iCloud得持久化存储。这就意味着,通过iCloud,改变的传播高效(这个替代将为每一个改变推送给SQLite)。但对于这样,也有几个结果:
*你必须告诉核心数据哪里去存储离散事务日志,和 存储改变 相关的。
当配置一个存储时,你做这些通过提供
NSPersistentStoreUbiquitousContentNameKey
得值和 可……选
NSPersistentStoreUbiquitousContentURLKey 得键值。(如果你没有指定一个
NSPersistentStoreUbiquitousContentURLKey得值,那么一个URL得建造,通过应用束identifier对NSFileManager的
URLForUbiquityContainerIdentifier:
方法。
)内容得名字被用于标识这个存储 通过不同设备,以至于事务始终与所有设备,多种持久化实例同步。出于这个原因,你应该必须确保你为每一个存储停工一个唯一得名字,例如UUID。
*当你从iCloud删除一个存储时(或者使设备本地,或者完全删除),你必须直接删除相应得事务日志。
你做相应得操作,通过NSFileManager。如果你指定一个传统和 惟一的
NSPersistentStoreUbiquitousContentURLKey
,
简单删除目录将会移除所有得和存储相关的事务日志数据;如果你得NSPersistentStoreUbiquitousContentURLKey被分享,那么你将仅仅移除NSPersistentStoreUbiquitousContentNameKey得子目录。
* 你不必存储SQLite文件本身在有改变的地方,他将被传播通过iCloud。
这个包括整个包含SQLite存储文件的父目录。
这个将在以后在应用程序样式得文章中 讨论。