微网站建设及微信推广方案ppt,wordpress多用户登录,网站规划与建设,那些网站百度抓取率比较高官方地址#xff1a;iOS App Programming Guide - iCloud Storage这个偏理论一些#xff0c;提供了很多iCloud应用设计层面的东西#xff0c;大家感兴趣#xff0c;可以一看。如果需要iCloud上手教程#xff0c;可以参考我的另外一个贴子#xff1a;http://www.cocoa…官方地址iOS App Programming Guide - iCloud Storage这个偏理论一些提供了很多iCloud应用设计层面的东西大家感兴趣可以一看。如果需要iCloud上手教程可以参考我的另外一个贴子http://www.cocoachina.com/bbs/read.php?tid86246-----------------------------------------------------------------------------------------------------------------------------iCloud支持两种应用存储 document storage存储用户文档和应用数据到用户的iCloud账户key-value data storage分享小量的非关键配置数据到应用的多个实例iCloud App的设计考虑首 先需要确认的是采用document storage还是key-value data storage。document storage用于存储应用数据要么是应用创建并私有管理的数据要么是用户创建的数据。所有用户面对的数据都应该是document storage例如用户创建的文档。key-value data storage主要用于非关键的配置数据你希望在多个app实例中共享例如应用使用的参数和配置信息典型的例子如Newsstand应用中用户上一次阅读的刊物和阅读位置。document storage 和 key-value data storage的区别 属性Document StorageKey-Value storage管理的数据类型文件和目录只能是Property-list数据什么时候应该使用使用Document Storage来管理应用的关键数据。与应用main data model直接相关的文件和数据总是应该使用Document Storage。如用户文档、私有的app数据文件、以及应用或用户生成的数据文件参数或其它配置数据如果需要在多个app实例之间共享并且不是关键数据就可以使用key-vlaue storage。只能存储property list数据并且容量有限。是否需要file presenter和file coordinator是否怎样定位数据使用 NSMetadataQuery 对象来查找文件使用默认的 NSUbiquitousKeyValueStore 对象来获取已知key对应的值如何管理数据使用NSFileManager类来管理文件和目录。使用标准文件系统函数来打开、关闭、读取和写入文件使用默认的NSUbiquitousKeyValueStore 对象来获取和设置key和value能存储多少数据只受用户iCloud账户的空间限制限制为64KB单个key也限制为64KB怎样处理冲突应用的 file presenters 必须手工解决冲突最后设置的值总是当前值。设备提供的时间戳用于确定最新的值要求设置哪个entitlementcom.apple.developer.ubiquity-container-identifierscom.apple.developer.ubiquity-kvstore-identifier数据什么时候同步设备端发生变化时iCloud总是会拉取文件元数据和数据设备总是会拉取文件元数据但是直到应用试图使用文件时才会拉取文件数据定期在设备和iCloud之间传输key-value数据怎样在运行时检查iCloud可用对某个你已经注册的容器目录调用 URLForUbiquityContainerIdentifier: 方法如果方法返回nil表示document storage不可用调用 NSUbiquitousKeyValueStore 的 synchronize 方法如果返回YESiCloud可用并且有修改同步到本地用户默认数据库如果返回NOiCloud要么不可用要么没有变化需要同步。无论如何都可以直接使用本地的用户默认数据库。系统提供了什么用户界面支持没有应用负责提供支持iCloud的信息和界面。没有多数情况下你不应该让用户知道key-value数据存储在本地还是iCloud中。另一个设计考虑是应用的用户界面如何整合iCloud支持。特别是文档有时候你需要提醒用户文档的状态比如是否已经下载、版本冲突需要解决等。一般都需要在界面上增加一些不引人注目的元素以在适当的时候提示用户。 配置应用的iCloud Entitlements使用iCloud的应用必须以iCloud特定的Entitlements签名。这些entitlements为应用提供一层安全性确保只有你的应用才能访问自己创建的文档。系统也依赖于你提供的Entitlement值来区分用户iCloud账户中你的应用与其它应用的文档。Xcode中启用iCloud Entitlements 选择应用的target选择Summary在Entitlements中勾选Enable Entitlements当 你启用App target的Entitlements时Xcode自动为你的应用配置了document storage和key-value data storage。每个Entitlement包含一个key是一个或多个容器标识字符串。容器标识字符串标识了iCloud中的一个容器目录你用来存储应用的文件。Xcode按以下方式来配置Entitlements iCloud容器域标识了应用在用户iCloud存 储中能够访问的容器目录这个域对应于com.apple.developer.ubiquity-container-identifiers。你添 加到这个列表的字符串必须匹配你的团队创建的应用bundle ID。Xcode使用当前app的bundle ID来指定第一个字符串如果你希望多个app共享一个main容器目录你可以修改为不同的bundle ID。你还可以为团队的其它应用添加额外的bundle ID第一个字符串必须不包含任何通配符随后的字符串则可以包含通配符iCloud的key-value存储域包含应用存储到iCloud的key-value data storage的单个容器标识字符串对应于 com.apple.developer.ubiquity-kvstore-identifier你 在Xcode中设置的bundle ID并不是完整限定的容器标识字符串。完整限定的容器标识的格式 是 TEAM_ID.BUNDLE_IDENTIFIER其中TEAM_ID是10个字符的团队标 识BUNDLE_IDENTIFIER 则是iCloud容器域中的某个bundle ID。当在代码中获取某个容器目录的URL时你需要传递完整限定的字符串给 URLForUbiquityContainerIdentifier: 方法。不过你也可以传递nil来获取列表中的第一个容器目录的URL通过在Entitlements中指定多个容器标识使用iCloud document storage的应用可以读取和写入内容到多个容器目录。iCloud容器域允许你指定多个字符串。第一个字符串是应用的main容器标识任何额外的字符串则代表你其它应用的容器标识。查找时会返回所有可用容器目录中的所有文件。 使用iCloud Document StorageiCloud Document Storage让你将文件和目录移动到用户的iCloud账户并在那里管理这些文件。在某个设备上修改文件或目录会先存储在本地然后再通过本地daemon进程push到iCloud。文件传输对应用是透明的因此应用只需直接操作文件。设计应用使用iCloud Document Storage需要一些重大的应用修改主要包括 应用执行的早期调用 URLForUbiquityContainerIdentifier: 方法检查iCloud是否启用。扩展应用Sandbox来包含应用请求的每个容器目录也需要调用这个方法。显式地整合 file presenters如UIDocument类到应用的数据层显式地移动文件到iCloud准备好处理版本冲突使用查找来定位iCloud中的文件处理文件在iCloud中但是没有完全下载到本地设备的情况可能需要向用户提供及时的反馈如果要在iCloud中存储live database使用Core Data不要使用SQLite如果应用还有Mac OS X版本为所有应用使用通用文档格式App支持iCloud的大部分工作都在数据层。与iCloud的交互也主要是应用要存储使用的文件和目录。不过底层数据变化时用户界面也需要一定的修改以通知用户相关的状态。当然应用应该尽可能地让用户无需关心本地还是iCloud存储。检查iCloud Document Storage是否可用每个Apple ID用户都有一个免费的iCloud账户但是用户可能禁用某个设备的iCloud。因此使用iCloud接口之前必须先调用 URLForUbiquityContainerIdentifier: 方法检确定iCloud是否可用。返回nil表示不可用返回URL表示可用第一次对指定的容器目录调用 URLForUbiquityContainerIdentifier: 方法iOS会扩展应用Sandbox来包含该容器目录。因此需要至少成功调用一次该方法以确保iCloud可用main容器目录也可以访问。整合 File Presenters 到应用iCloud中存储的所有文件和目录都由file presenter对象管理你对这些文件和目录的修改都必须通过一个file coordinator对象。file presenter实现了 NSFilePresenter 协议主要的职责是作为特定文件或目录的响应代理。在外部源能够修改一个文件之前注册的file presenter会得到通知并有机会执行任何必要的簿记bookkeeping工作。当应用想要修改一个文件时它必须通过一个 NSFileCoordinator 对象来执行修改本质上会锁住文件。file coordinator 阻止外部源修改文件并且递送相关的通知给其它 file presenters。整 合 file presenter 到应用最简单的方法是使用 UIDocument 类。这个类实现了 NSFilePresenter 协议并为你处理了所有文件相关的管理。应用唯一需要做的事情就是在得到通知时读取和写入文档数据。不管是用户生成内容的文件因此直接显示给用户还是应用替用户创建的文件无需用户交互都可以使用UIDocument。操作iCloud中的文件和目录iCloud文件和目录和本地文件目录一样应用使用相同的技术来管理文件和目录。你可以打开、创建、移动、复制、读取、写入、删除、以及其它操作。本地文件目录和iCloud文件目录的唯一区别是访问的URL不同。本地文件目录的URL相对于应用Sandbox而iCloud文件目录的URL则相对于相应的iCloud容器目录。要移动一个文件或目录到iCloud 在应用Sandbox中创建本地文件或目录。使用的时候必须由file presenter来管理文件或目录。如UIDocument使用 URLForUbiquityContainerIdentifier: 方法获取iCloud容器目录的URL使用容器目录URL来构建一个新的URL指定文件或目录在iCloud中的存储位置调用 NSFileManager 的 setUbiquitous:itemAtURL:destinationURL:error: 方法移动文件或目录到iCloud。绝对不要在应用的主线程中调用这个方法否则可能会长时间阻塞主线程或者与应用所拥有的file presenter产生死锁。移动一个文件或目录到iCloud时系统从应用Sandbox中复制该item到private本地存储这样才能被iCloud daemon监测到。尽管文件此时已经不在应用Sandbox中应用仍然对其拥有完全访问。虽然文件仍然有一份拷贝保留在当前设备的本地文件同时还发送到了iCloud这样就能分布到其它设备去。iCloud daemon处理了所有工作确保本地拷贝与iCloud是相同的。因此从应用的角度来说文件就是在iCloud中。你对iCloud中的文件和目录的所有修改都需要使用一个 file coordinator 对象。包括移动、删除、复制、重命名等操作。file coordinator确保iCloud daemon不会同时修改文件或目录并确保你修改时能够及时地通知其它人。命名文件和目录时尽量使用字母数字避免使用特殊标点和其它特殊字符。同时你还应该假设文件名是大小写不敏感的因为iCloud支持Windows。最后尽量保持文件名简单以确保这些文件能够在不同文件系统中正确地处理。选择一种响应版本冲突的策略iCloud文件的版本冲突不可避免因此应用必须对冲突采取一种解决策略。当应用的两个实例同时修改一个文件并传输给iCloud时就会发生冲突。iCloud会保存所有冲突的版本并通知应用的file presenter发生了冲突需要解决。App应该尽快地尝试解决版本冲突当冲突发生时其中一个文件被指定为current file其它所有版本都是冲突版本。当前文件和冲突版本文件都由 NSFileVersion 对象来管理可以通过类方法来获取。解决冲突 使用类方法 currentVersionOfItemAtURL: 获取当前文件版本使用类方法 unresolvedConflictVersionsOfItemAtURL: 获取所有冲突版本的数组对每个file version对象执行以下任何动作来解决冲突[list1]如果实际可行的话合并冲突文件修改的数据如果能够安全地执行而不丢失数据的话忽略某个冲突版本提示用户选择保留哪个版本的文件当前文件或冲突文件这是最后的选择。更新当前文件 如果当前文件胜利winner不需要更新当前文件如果某个冲突版本胜利winner使用 coordinated write 操作以冲突版本的文件内容覆盖当前文件如果用户选择保存冲突版本为另一个名字以该冲突版本的内容创建一个新文件设置所有冲突版本对象的 resolved 属性为YES。设置这个属性会导致冲突版本对象及相应的文件从用户的iCloud storage中删除。如果使用UIDocument类你通过 observing 文档状态变化通知并检查 documentState 属性来判断是否发生冲突如果使用自定义 file presenter每当报告有一个新版本时你都应该检查它是否冲突版本。整合查找Search到应用基础架构和应用Sandbox不同iCloud中的文件添加和删除你的应用可能都不会直接知道。在这台设备上创建的文件最终会出现在另一台设备中。如果应用不主动查找文件那就不能及时地出现在用户界面中。因此应用需要使用 NSMetadataQuery 对象来查找iCloud容器目录中的文件或目录。当应用在前台时你可以保留一个 metadata query 一直运行来接收文件添加或删除的通知应用进入后台时就停止这个 metadata query 查询。只有 iCloud 启用并且相应的容器目录已经创建时metadata查询才会有返回结果。在运行时确保使用 URLForUbiquityContainerIdentifier: 方法来检测iCloud已经启用而且应用支持的容器目录也可用。这个方法在容器目录不存在时会自动创建出来。Metadata 查找应用entitlement中设置的所有容器目录并返回合并后的所有结果。如果你希望只查找一个容器目录可以使 用 URLForUbiquityContainerIdentifier: 方法来获得该容器目录的URL然后使用 NSFileManager 类来获取目录内容的静态列表。确定文件或目录的传输状态你写到iCloud容器目录的item会尽可能快地自动传输到iCloud服务器。但是由于网络和设备类型的原因文件或目录可能不会立即下载到设备或上传到服务器。如果你需要确定文件的状态可以使用 NSURL 的 getResourceValue:forKey:error: 方法来获取以下属性的值 NSURLIsUbiquitousItemKey表示item是否存储在iCloudNSURLUbiquitousItemIsDownloadedKey表示当前版本是否已经下载并且可访问NSURLUbiquitousItemIsDownloadingKey表示当前版本是否正在下载并且暂时不可用NSURLUbiquitousItemPercentDownloadedKey对于正在下载的item表示已经下载的修改的百分比。可以使用这个值来更新进度条。NSURLUbiquitousItemIsUploadedKey表示本地的修改是否成功上传到iCloud服务器NSURLUbiquitousItemIsUploadingKey表示本地的修改是否正在上传到服务器NSURLUbiquitousItemPercentUploadedKey对于正在上传的item表示当前已经上传的修改的百分比虽然iCloud服 务器会非常努力地拉取应用在本地做的修改但是iOS设备通常却不会主动从服务器拉取修改除非你试图访问该文件。如果你试图打开一个正在下载的文 件iOS会阻塞发起打开请求的线程直到文件被完全下载并且可用。因此如果你担心潜在的延迟就根据需要检查文件的当前状态同时更新用户界面提示用 户当前文件正在下载暂时不可用。使用尚未下载完成的文件iCloud中的文件发生改变时iOS设备不会自动下载这些修改数据。相反iOS设备会下载文件的元数据因此知道此时文件已经有修改。实际修改的数据只有以下情况发生时才会被下载 应用试图打开或访问文件应用调用 startDownloadingUbiquitousItemAtURL:error: 方法显式地下载文件修改如果应用打开尚未下载完成的文件用于打开文件的 file coordinator 会阻塞你的应用直到文件或修改被完全下载。如果文件或修改比较大可能会导致很差的用户体验因此试图打开一个文件之前应该首先检查文件的下载状态。NSURL 类定义了iCloud item相关的属性可以检查iCloud文件的状态检查文件是否已经下载完成- (BOOL)downloadFileIfNotAvailable:(NSURL*)file { NSNumber* isIniCloud nil; if ([file getResourceValue:isIniCloud forKey:NSURLIsUbiquitousItemKey error:nil]) { // If the item is in iCloud, see if it is downloaded. if ([isIniCloud boolValue]) { NSNumber* isDownloaded nil; if ([file getResourceValue:isDownloaded forKey:NSURLUbiquitousItemIsDownloadedKey error:nil]) { if ([isDownloaded boolValue]) return YES; // Download the file. NSFileManager* fm [NSFileManager defaultManager]; [fm startDownloadingUbiquitousItemAtURL:file error:nil]; return NO; } } } // Return YES as long as an explicit download was not started. return YES;}为iCloud调整用户界面所有为了iCloud所做的用户界面调整都应该尽量不引人注意。当iCloud不可用时你存储在iCloud中的文档和你存储在本地是完全一样的。唯一的区别是文件系统中的位置。因此大部分用户界面都应该保持一致。以下情况可能需要针对iCloud修改用户界面 当用户生成的文档在使用之前必须被下载。只有你提供了文档浏览器才需要让用户来控制是否下载文档。应用使用的私有文件应该在不可用时自动去服务器下载。你用来提示用户的信息应该尽量友好并提供用户“开始文档下载”的选项。如果下载时间可能超过几秒钟你需要显示一个当前下载进度。当出现必须由用户解决的版本冲突。如果应用需要用户协助才能解决冲突就应该友好地提示冲突信息但千万不要显示警告或其它任何破坏性的界面。当你希望提供用户选项为应用启用或禁用iCloud时。如果应用包含一个Settings Bundle或者内部的参数设置你可以提供一个参数让用户选择是否使用iCloud。iCloud结合Database使用只有应用使用Core Data来管理数据库时才能将SQLite数据库整合到iCloud。不支持使用SQLite接口访问iCloud中的live数据库这样做很可能会毁坏你的数据库。但是只要你遵守一些额外的步骤来设置Core Data结构你就可以创建基于SQLite的Core Data从而启用iCloud支持。当然其它类型的Core Data Store不基于SQLite则无需修改可以直接支持iCloud。使用Core Data和SQLite store时实际的数据库文件不会传输到iCloud服务器。相反每个设备都维护自己的SQLite store拷贝并通过将修改写入到日志文件来同步它的内容。设备与iCloud之间真正传输的是log file在每个设备中Core Data拿到log file的内容然后使用这些内容来更新本地数据库。当然最终的效果就是每个本地数据库都拥有完全相同的修改。设置Core Data store来处理iCloud只需要你执行很少的额外工作。但是具体的步骤取决于你使用Core Data store作为中央库Central Library还是为单个文档分别创建独立的Core Data Store。使用Core Data管理文档应 用管理Core Data store为单独的文档时可使用 UIManagedDocument 对象来管理单个文档。UIManagedDocument 类自动在应用bundle中查找所有managed object model并使用它们作为文档数据的基础你也可以覆盖 managedObjectModel 属性自定义指定子类的object models。由于大部分数据由managed object context处理意味着你通常可以直接使用 UIManagedDocument 类而不需要继承子类。UIDocumemnt的自动保存行为能够自动处理所有文档的保存工作。创建新文档时执行以下步骤 创建 UIManagedDocument 对象文档的 persistentStoreOptions 属性是一个Dictionary添加一个 NSPersistentStoreUbiquitousContentNameKey 键值为你标识该文档的唯一名字。添加一些初始化数据到文档使用 saveToURL:forSaveOperation:completionHandler: 方法将文档保存到磁盘。保存文档时你也可以直接将它保存到iCloud或者先保存在本地目录然后再移动到iCloud。保存到iCloud需使用 URLForUbiquityContainerIdentifier: 方法获得相对iCloud的URL如果已经保存到本地则可以使用 setUbiquitous:itemAtURL:destinationURL:error: 方法将其移到iCloud当 你创建一个新文档时Core Data创建一个file package包含文档的内容。这些内容有一个 DocumentMetadata.plist 文件以及一个包含SQLite data store的目录。除了SQLite data store保留在本地file package中的任何东西都会被传输到iCloud服务器。打开iCloud中的现有文档时执行以下步骤 使用 NSMetadataQuery 查找iCloud中的文档Metadata查找会标识你iCloud中的所有Core Data文档。如果文档是其它设备创建文档file package最初只有 DocumentMetadata.plist 一个文件。打开 DocumentMetadata.plist 文件并获取 NSPersistentStoreUbiquitousContentNameKey 键的值创建 UIManagedDocument 对象添加 NSPersistentStoreUbiquitousContentNameKey 键到文档的 persistentStoreOptions 属性。这个键的值就是你在第2步中获取的值调用文档对象的 openWithCompletionHandler: 方法来打开文档应 用第一次打开其它设备创建的Core Data文档时Core Data会自动检测到SQLite store不存在并在本地创建一个。然后使用 NSPersistentStoreUbiquitousContentNameKey 键的值你添加到属性的那个来获取适当的transaction logs并重新构建数据库的内容。从这时候开始你就可以修改该文档并保存到iCloud。你所做的修改会保存到新的log file这样其它设备就能将其整合到它们的SQLite store。当应用从iCloud中 接收到文档修改时Core Data会自动将这些修改合并到文档的SQLite store并给应用发 送 NSPersistentStoreDidImportUbiquitousContentChangesNotification 通知。应用必须注册这个通知并使用它来刷新任何修改的记录。如果应用不刷新本地的数据拷贝就会将老的修改重新写到iCloud并产生一个冲突版本。通过及时地整合其它设备的修改应用就能避免类似的冲突。删 除一个文档时你必须同时删除文档的file package以及包含文档transaction logs的目录。同时删除所有这些东西要求你使用 NSFileCoordinator 对象来执行coordinated写入操作。文档的DocumentMetadata.plist 文件包含一个 NSPersistentStoreUbiquitousContentURLKey 键它的值就是文档transaction logs目录的URL。使用Core Data管理中央库Central Library如果应用使 用Central Core Data store来管理数据就应该将data store直接存放在应用Sandbox目录。使用一个Central data store的应用通常只有一个persistent store coordinator对象和一个persistent store对象。因此最简单的解决办法是将Core Data store保留在应用Sandbox仅使用iCloud来同步修改。在本地创建SQLite store时执行以下步骤 创 建data store时调用 addPersistentStoreWithType:configuration:URL:options:error: 方法并在传递的options Dictionary中包含 NSPersistentStoreUbiquitousContentNameKey 和 NSPersistentStoreUbiquitousContentURLKey 键。注册 NSPersistentStoreDidImportUbiquitousContentChangesNotification 通知并使用它来更新所有的记录更新。因为你只有一个data store你可以为 NSPersistentStoreUbiquitousContentNameKey 键指定任何名字。对于 NSPersistentStoreUbiquitousContentURLKey 键应该指定为应用某个iCloud容 器目录中的某个目录URL。换句话说这个URL应该基于 URLForUbiquityContainerIdentifier: 方法返回的URL构造而成。Core Data将修改写入到你指定的这个目录其它设备则在这个目录中查找修改。当检测到修改时Core Data会自动整合修改到本地的SQLite store并通知你的应用。同样你也必须及时地响应iCloud相关的修改通知。这些通知使应用能确保使用最新的数据如果你使用老版本的数据就可能覆盖其它设备的新数据并产生冲突版本。为Core Data Transaction Logs指定自定义位置应用Core Data Store的修改使用transaction logs来保存这些logs存储在用户iCloud账户的一个特殊目录中。应用的所有Core Data Stores全部使用同一个目录来保存transaction logs。默认情况下这个目录的名字和应用bundle ID相同并保存在应用默认iCloud容器目录中。如果你已经使用这个目录作为其它用途你可以通过修改Core Data stores的选项来修改目录的名字。在 基于文档的应用中要自定义transaction logs目录必须修改每个 UIManagedDocument 对象的 persistentStoreOptions 属性Dictionary。在字典中增加 NSPersistentStoreUbiquitousContentURLKey 键并设置值为你希望使用的自定义目录URL。这个URL需要首先使用 URLForUbiquityContainerIdentifier: 方法并通过添加额外的路径来扩展URL。如果应用使用单一的Core Data store管理所有数据在创建 persistent store时调用 addPersistentStoreWithType:configuration:URL:options:error: 方法并在options参数中增加 NSPersistentStoreUbiquitousContentURLKey 键值也是你希望设置的目录URL。 使用iCloud Key-Value Data Storage应用使用iCloud Key-Value data storage来存储参数、或小量的非关键配置数据。key-value data storage概念上类似于本地user defaults数据库应用通常用来存储配置。区别在于iCloud数据在用户所有设备中你的所有应用实例间共享。使 用 NSUbiquitousKeyValueStore 类需要设置com.apple.developer.ubiquity-kvstore-identifier Entitlement如果多个不同的应用配置相同的entitlement值则这些应用都可以共享相同的key-value数据。使用 NSUbiquitousKeyValueStore 类写入数据到iCloud key-value store这个类概念上也类似于 NSUserDefaults用于保存和获取简单的数据类型数字、字符串、日期、数组等等。应 用的key-value store的容量限制为64KB而每个键的限制当前也是64KB。因此应用只能使用key-value storage记录很少的数据不能用于存储用户文档或其它大型数据archive。典型的例子是杂志应用可以保存用户当前阅读的刊物和页数。这样用户 在其它设备打开相同应用时就能回到之前阅读的位置。NSUbiquitousKeyValueStore 类绝对无法代替 NSUserDefaults 类应用总是应该通过 NSUserDefaults 将所有配置数据保存在本地磁盘。然后再使用 NSUbiquitousKeyValueStore 将需要共享的数据上传到key-value store。这样确保iCloud不可用时你仍然能够访问应用的配置数据。 负责任的iCloud App用户的iCloud空间有限并且由所有应用共享。用户可以查看指定应用消耗的iCloud空间可以选择删除应用相关联的文档和数据。因此应用必须对自己存储在iCloud中的文件负责下面是一些管理iCloud文档的建议 对存储iCloud文档采取一种好的策略。允许用户启用或禁用iCloud。从用户iCloud账户中删除一个文档将从用户所有计算机和设备中删除该文档。确保用户明白这一点并确认删除操作。如果你只是想刷新文档的本地拷贝使用 NSFileManager 的 evictUbiquitousItemAtURL:error: 方法而不是删除文件。存储文档到iCloud时尽量将文档存储在Documents子目录中。用户可以单个删除Documents目录中的文档以释放空间但是Documents目录之外的所有东西都被当做数据只能一次全部删除永远不要存储缓存或其它应用的私有文件到用户的iCloud storage。用户的iCloud账户只应该用于存储用户相关的数据以及应用无法重新生成的内容。对iCloud文件和应用Sandbox文件相同对待。保存文件应该由应用需求和保留用户数据的需求来驱动。你不应该修改应用更频繁或更慢地保存iCloud文件。iCloud会自动优化自己向服务器的传输以确保最佳的性能。转载于:https://www.cnblogs.com/ligun123/archive/2012/03/22/2411112.html
