iCloud(苹果云端)是苹果推出的新功能,它可以存放你的内容,并以无线的方式将他们推送到你的装置上。即让现有苹果设备实现无缝对接,让使用者可以免费储存5GB的资料。
一、特点
iCloud将苹果音乐服务,系统备份,文件传输,笔记本及平板设备产品线等元素有机的结合在了一起,而且联系非常紧密。简而言之,iCloud平台可以将你的个人信息存储到苹果的服务器,通过连接无线网络,这些信息会自动推送到你手中的每个设备上,这些设备包括iPhone、iPod Touch、iPad,甚至是Mac电脑。(代表:MobileMe)
二、功能:存储内容
1、应用软件、电子书与备份恢复
- 在 iPhone 上下载一款新应用软件,它就会自动出现在你的 iPad 上。你不必担心多部设备同步的问题。
- 一旦你从 iBookstore 下载了电子书,iCloud 会自动将其推送到你其它的设备。
- 通过 WiFi 等无线网络,实现每天自动备份。备份的内容包括音乐,照片,视频,应用程序,书籍等。
2、Documents in the Cloud(云端文档):帮助用户在不同的设备上进行同样的文本编辑操作。
3、Photo Stream(照片流) :所有iPhone拍摄的照片会自动推送至服务器,然后服务器会将这些内容再推送到你之前使用个人ID登录过的每个苹果设备上,有点类似Android的Picasa相册。
4、iTunes in the Cloud(云端iTunes):购买的音乐或软件可以在任一相同 Apple ID 的设备上多次下载。
5、iTunes Match:通过扫描用户收藏的音乐库,能够发现用户并非通过苹果购买的音乐。如果iTunes Match发现苹果自家Music Store库中存在匹配音乐,苹果就会向用户提供同等质量的基于云的版本,但前提是用户须是iTunes Match的付费用户。
6、5 GB 空间:免费空间是 5 GB,可以保存邮件,文档,备份数据等等。iTunes 音乐不占用空间。
7、Mobile Me 邮箱免费:me. com 的邮件免费了,支持推送,不含广告。
三、合理利用iCloud存储空间
- 应该存储:
1、用户文档
2、包含用户建立的数据的app特殊文档
3、通过key-value(键-值)存储的参数
4、改变一个SQLite数据库日志文件
- 不该存储:
1、缓存文件
2、临时文件
3、App支持的可重建文件
4、下载的大数据文件
5、一个SQLite数据库的存储文件
- 系统管理本地的iCloud存储
1、iCloud文件存储在iCloud,同时本地有缓存。当网络不可用时,本地缓存的iCloud数据允许用户可以继续工作。
2、由于本地缓存的iCloud数据和其他文件共享空间,当没有足够的空间缓存iCloud数据,系统会自动的通过维护一个优化的本地文件子集来解决这一问题。
- 你的App帮助系统管理本地存储的两个特列
1、当用户文件当前不需要或者不太可能很快需要,通过调用NSFileManager的方法evictUbiquitousItemAtURL:error:来帮助系统从ubiquity container移出文件。当App需要使用此文件时,系统必须重新下载该文件。
2、相反,当你想确保一个文件本地可用,则可以通过NSFileManager的方法startDownloadingUbiquitousItemAtURL:error:来启动一个下载到一个ubiquity container。
四、条件:
1、使用 WLAN 或其他互联网连接。
2、iOS5.0及以上版本或安装 OS X Lion 的 Mac 电脑或配备 Windows Vista 或 Windows 7 的 PC (推荐使用 Outlook 2007 或 2010)。
五、iCloud三种存储
1、Key-value storage(键-值存储):针对离散值,如参数——股票或天气信息、位置、书签、设置和偏好,以及简单的游戏状态。
2、Document storage(文档存储):针对用户可见的基于文件的信息。如演讲、文字处理文档、图表或图纸和复杂的游戏状态。
3、Core Data storage(核心数据存储):针对结构数据。建立在iCloud文档存储,存储如基于服务器的核心数据存储等
六、键-值存储
1、申请权限
- 在Xcode项目设置中选择iCloud键-值复选框获得使用键-值存储的com.apple.developer.ubiquity-kvstore-identifier权限。
- 使用共用的NSUbiquitousKeyValueStore对象来达到app与iCloud键-值存储的交互。
- 通知的传入将更改你的键-值存储。当收到通知,监测用户信息词典并且决定是否改写app的用户默认值。这两步的过程,让你有机会去决定,基于iCloud-originated变化,是否要改变你的app的设置。
2、解决冲突(简单自动)
- 系统以最后写入的值为准
- 为了允许app参与解决键-值冲突,使用NSUbiquitousKeyValueStore对象来与用户默认相协调(而非替代)。
3、数据大小限制
键-值存储的总共可用空间为1MB(每app)。所以你可以指定键的最大数量为1024,且每个与键关联的大小限制为1MB。
七、文档存储
1、数据和信息与iCloud交互过程
- 首先,申请权限,app在后台线程调用NSFileManager的方法URLForUbiquityContainerIdentifier:来建立iCloud存储和获取ubiquity container的URL。
- 然后,系统授权app访问ubiquity container。
- 最后,app可通过访问ubiquity container进行数据的读写入iCloud。
2、首次传送文件到iCloud(从ubiquity container到iCloud)
- 首先系统(ubiquity container)发送文档的元数据,包括文档名,修改日期,文件大小和类型等。此传递过程很快。
- 然后系统发送文档数据到iCloud服务,这些数据在发送前都被自动加密。
3、文档改变时传送到iCloud(从ubiquity container到iCloud)
- 文档元数据快速的传给iCloud服务,以便其传播到其他设备
- 仅上传文档更改的部分。此优化可以减少网络流量和设备电量。
4、首次从iCloud接收文档(上面2的逆过程)
- 从iCloud接收文档元数据
- 接收文档数据根据设备类型
- iOS:非自动下载
-Mac:自动下载
5、从iCloud接收改变的数据
- 接收更新的元数据,在设备已经下载过的前提下
- 系统(ubiquity container)通过询问iCloud马上发送相应的增量数据来响应。
八、基于文档的工作流
典型的基于文档的app工作流:
工作流 | 基本类 | 描述 |
创建一个新的标准文档 | UIDocument (iOS) NSDocument (OS X) | 在文档格式中使用一个文件对象来创建和管理数据结构。文档类能自动地支持将新的文档保存到ubiquity container或本地存储。 |
创建一个新的核心数据文档 | UIManagedDocument (iOS) NSPersistentDocument (OS X) | 使用核心数据文档的子类创建和管理你的核心数据存储。详见“Designing for Core Data in iCloud” |
获取iCloud文档的URLs | NSMetadataQuery (iOS) 自动 (OS X) | iOS,使用元数据在iCloud文档中查询对象来定位和获得实时更新的信息。 OS X v10.8及以上,一个文档自动的使用一个元数据查询来打开对话框。 |
提示用户打开一个文档 | Custom UI (iOS) Automatic as part of the document architecture (OS X) | iOS,app直接负责呈现一个简单感觉的用户文档的选择UI。 OS X v10.8及以上,一个基于文档的app的打开命令呈现一个对话框让用户选择iCloud文件。 |
处理版本冲突 | UIDocument, NSFileVersion(iOS) 自动 (OS X) | iOS,文件检测和通知关于冲突的信息。如必要,使用NSFileVersion对象(每个修订的文档)来解决冲突。 |
移动,重命名,复制,删除基于iCloud的文档 | NSFileCoordinator NSFileManager | 在磁盘上操作文件使用NSFileManager类,并且总是结合一个文件协调对象的上下文。 |
九、选择合适的iCloud存储:键-值存储与文档存储的区别
属性 | 文档存储(Document storage) | 键-值存储(Key-value storage) |
目的 | 用户文档、复杂的私人app数据,包含复杂的app或用户生成的数据的文档。 | 可以用简单数据类型表达的偏好和配置数据 |
权值 | com.apple.developer. ubiquity-container-identifiers | com.apple.developer. ubiquity-kvstore-identifier |
数据形式 | 文本或者文本包 | 仅属性列表数据类型(numbers, strings, dates等) |
容量 | 仅受限于用户iCloud账户可用空间 | <=1MB/每app,<=1MB/每key |
可用性检测 | 对ubiquity containers调用URLForUbiquity- ContainerIdentifier:方法,返回nil则文档存储不可用 | 总是可用。若账号未登录,则改变将在下次登进账号是推送到iCloud |
本地数据 | 利用一个NSMetadataQuery对象获取可用iCloud文件中新的信息 | 使用共享的NSUbiquitousKey-ValueStore对象来检索值。 |
管理数据 | 使用NSFileManager类来直接处理文件和目录 | 使用默认的NSUbiquitousKey-ValueStore对象来操纵值。 |
解决冲突 | 文档(作为操纵者)自动处理;在OS X中如有必要,NSDocument会为用户呈现版本。对于文件,你可以手动解决。 | 最近的一个值被设为键值推送到同一个iCloud关联的所有设备。每个设备分别改变时间来提供所需的时间戳。 |
数据传输 | 自动的,来响应本地文件系统的变化 | 不适用(键-值存储不使用元数据) |
用户界面 | iOS:未提供。若需要,App负责显示iCloud数据信息。如此达到无缝和最小的改变App的pre-iCloud UI。 OS X:NSDocument提供iCloud的UI。 | 不适用。用户不需要知道键-值数据存储在iCloud。 |
十、核心数据存储
1、使用一个SQLite 核心数据存储要点:
- Apple建议你将你的SQLite核心数据存储在你的app的ubiquity containers下的一个<my_folder>.nosync子目录中。这样确保不同账号关联各自正确的数据。
- 不要预填充一个新的SQLite存储内容。相反,你必须利用migratePersistentStore:toURL:options:withType:error:方法移动已有的存储内容。
- 当使用iCloud,设备上的SQLite存储是一个代表数据来自核心数据日志文件的缓存。
- 若删除一个存储文件,则必须首先撤销核心数据堆栈。然后删除存储的文件包和包含存储事物日志的文件夹。每个删除操作需要你去使用一个NSFileCoordinator对象来执行一个协调的写操作。
2、2进制存储和XML存储的局限性
2进制和XML存储文件是本身转移到iCloud服务器中,当有任何改变,系统上传下载整个存储。当数据很大,或者更改过于平凡,这将产生大量数据与iCloud交互,所以没有SQLite存储有效。
所以2进制或者XML存储适合数据量小且变化不平凡的iCloud-enabled app中。
3、在OS X中,NSPersistentDocument类不支持iCloud
在OS X中,核心数据与文档体系结构的集成是通过NSPersistentDocument类,但是NSPersistentDocument类不支持iCloud。
4、核心数据App启动顺序的设计注意要点
- 第一步,使用共享的NSUserDefaults对象读取用户的默认数据库,在app运行过程中,使用此对象保存用户的选择以便下次运行。
- 当iCloud不可用时,确定app的行为。
- 当用户登出iCloud或者切换iCloud账号,早前使用账号的ubiquity containers对于app已不可用。
- 本地核心数据存储可能比另一个同账号的设备上的存储要新或者旧。所以在app启动时,核心数据可能需要结合iCloud的改变日志和本地存储相一致。