iCloud：我可以忽略那些禁用iCloud的人吗？
我正在为iCloud的想法苦苦挣扎，并在这里发布了一个更一般的问题。 我最大的问题是决定是否应该停止将用户的数据放在应用程序沙箱中的旧文档文件夹中。 为了说明我的问题：
据我所知， 文件没有给出答案。 假设我有一个处理不同txt文件的应用程序。 一旦我开始我的应用程序，我只是检查是否有任何txt文件在云中是这样的：
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { NSLog(@"AppDelegate: app did finish launching"); self.window = [[[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]] autorelease]; self.window.rootViewController = self.viewController; [self.window makeKeyAndVisible]; // (1) iCloud: init NSURL *ubiq = [[NSFileManager defaultManager] URLForUbiquityContainerIdentifier:nil]; if (ubiq) { NSLog(@"User has iCloud enabled! Let's get the txt files from the cloud."); [self loadDocument]; } else { NSLog(@"User doesn't have iCloud enabled. App is thus worthless."); } return YES; } 然后我有一个方法来检查云中是否有任何txt文件，如果是，加载它们。 如果没有，我只需在云中创build新的txt文件。
这意味着应用程序不会将任何数据存储在文档文件夹中。 据我了解，一切都在我的设备的本地iCloud存储（也可以访问，如果用户离线）或在云中。 所以文本文件存在两个地方：在我的设备和云。
所以没有必要在我的本地文件夹中存储第三个副本，对吧？ 或者，这是我必须忽略的原因？ 换句话说，如果我向用户提供iCloud，我应该如何使用本地文档文件夹？ （我可以简单地忽略那些不会注册iCloud的人吗？）
编辑：只是为了澄清，当我谈到应用程序的沙箱中的标准文件文件夹，我的意思是这样一个：
NSArray *paths =NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES); NSString *documentsDirectory = [paths objectAtIndex:0];
没有理由将文档存储在本地存储以及iCloud中。 但是，您应该给用户closuresiCloud存储的选项。 closuresiCloud存储后，只能在本地存储中查找文件（与iOS5之前的应用程序一样）。 最好的办法是尝试隔离需要知道文档存储位置的代码部分，并testingiCloud是否可用并启用，并让该代码返回文档应存储的URL。
更新：如果你想分歧iOS5与iOS4，你只需要testing是否有iOS5的function。 有几种方法可以做到这一点。 一种方法是检查：
if ([UIDocument class] == nil)
在iOS4上这将是真实的，在iOS5上这将是错误的。 我不知道你的文件有什么样的数据结构，但你可以做的一件事就是创build一个UIDocument的包装。 在这个包装类里面，你可以拥有一个UIDocument结构的实例variables，以及你在IOS4中需要的字段（比如文件的path）。 当您实例化您的课程时，请testingiCloud是否已启用，以及UIDocument是否可用，如果有，请使用它并设置该字段。 否则，请设置其他字段并将UIDocument字段保留为零。 当你需要对你的“文件”进行操作时，testingUIDocument字段是否为零，如果是“老”的话。 否则，只需将请求传递给UIDocument对象。
也许我有点慢，通过重新阅读第四次或第五次的文档，我遇到了这个问题，这表明你应该总是在沙箱中创build你的文件，然后把它们移到云端。 所以从某种意义上说，苹果build议在任何时候都有3个版本的相同的文件：
应用程序使用相同的技术来pipe理iCloud中用于本地文件和目录的文件和目录。 iCloud中的文件和目录仍然只是文件和目录。 您可以打开它们，创build它们，移动它们，复制它们，读取和写入它们，删除它们或者您可能想要执行的任何其他操作。 本地文件和目录以及iCloud文件和目录之间的唯一区别是您用来访问它们的URL。 而不是URL相对于您的应用程序的沙箱，iCloud文件和目录的URL是相对于相应的iCloud容器目录。
将文件或目录移动到iCloud：
在应用程序沙箱中本地创build文件或目录。 在使用中，文件或目录必须由文件展示器（例如UIDocument对象）pipe理。
使用URLForUbiquityContainerIdentifier：方法来检索要存储项目的iCloud容器目录的URL。 使用容器目录URL构build一个新的URL，指定项目在iCloud中的位置。 调用NSFileManager的setUbiquitous：itemAtURL：destinationURL：error：方法将项目移动到iCloud。 切勿从应用程序的主线程调用此方法; 这样做可能会阻塞您的主线程很长一段时间，或导致与您的应用程序自己的文件演示者之一的僵局。 将文件或目录移动到iCloud时，系统会将该项目从应用程序沙箱中复制到专用本地目录中，以便iCloud守护程序可以监视该项目。 即使该文件不再位于沙盒中，您的应用程序仍然可以完全访问它。 尽pipe该文件的副本保留在当前设备的本地，但该文件也会发送到iCloud，以便将其分发到其他设备。 iCloud守护进程处理确保本地副本相同的所有工作。 所以从你的应用程序的angular度来看，这个文件只是在iCloud中。
您对iCloud中的文件或目录所做的所有更改都必须使用文件协调器对象进行。 这些更改包括移动，删除，复制或重命名项目。 文件协调器确保iCloud守护进程不会同时更改文件或目录，并确保通知您其他感兴趣的方所做的更改。
看这里。
请记住，如果用户启用了设备备份到iCloud，则无论如何都要备份文档目录。
这实际上取决于您是否计划在应用程序/平台之间使用iCloud作为同步工具。 如果不是，使用iCloud存储文档确实没有意义。