iCloud基础知识和代码示例

Question

作为一个初学者，我正在为iCloud奋斗。有一些示例，但是它们通常都非常详细（在开发人员论坛上，有一个针对iCloud和CoreData的示例非常庞大）。在苹果的文档都OK，但我仍然无法看到大局。因此，请允许我，其中一些问题是非常基本的，但可能很容易回答。

上下文：我有一个非常简单的iCloud应用程序正在运行（下面是完整的示例代码）。仅向用户显示一个UITextView，并且他/她的输入保存在一个名为text.txt的文件中。

在此处输入图片说明

txt文件被推送到云中，并可供所有设备使用。完美运行，但是：

主要问题：不使用iCloud的用户呢？

启动我的应用程序时（请参见下面的代码），我会检查用户是否启用了iCloud。如果启用了iCloud，则一切正常。该应用程序继续运行，并在云中查找text.txt。如果找到，它将加载它并显示给用户。如果在云中找不到text.txt，它将仅创建一个新的text.txt并将其显示给用户。

如果用户未启用iCloud，则不会发生任何事情。如何使非iCloud用户仍然可以使用我的文本应用程序？还是我只是忽略它们？我是否需要为非iCloud用户编写单独的功能？即我仅从documents文件夹中加载text.txt的函数？

苹果写道：

以与对待应用程序沙箱中所有其他文件相同的方式对待iCloud中的文件。

但是，就我而言，再也没有“普通”应用程序沙箱了。在云中。还是我总是先从磁盘加载我的text.txt，然后再与iCloud检查是否还有最新信息？

相关问题：文件结构-沙箱与云

也许我的主要问题是对iCloud应该如何工作的根本误解。当创建UIDocument的新实例时，我将不得不覆盖两个方法。首先- (BOOL)loadFromContents:(id)contents ofType:(NSString *)typeName error:(NSError **)outError从云-(id)contentsForType:(NSString *)typeName error:(NSError **)outError中获取文件，然后将文件添加到云中。

我是否必须合并单独的功能，这些功能也会将text.txt的本地副本保存到我的沙箱中？这对非iCloud用户有效吗？据我了解，iCloud会自动保存text.txt的本地副本。因此，我不需要将任何内容保存到应用程序的“旧”沙箱中（即，它曾经在iCloud之前的旧年代使用）。现在，我的沙箱完全是空的，但我不知道这是否正确。我是否应该在其中保留另一个text.txt副本？感觉就像混乱的数据结构...因为云中有一个text.txt，设备上的iCloud沙箱中有一个（即使我处于脱机状态也可以使用），而旧的沙箱中有第三个我的应用...

我的代码：一个简单的iCloud示例代码

这大致基于我在开发人员论坛和WWDC会话视频中找到的示例。我将其剥离到最低限度。我不确定我的MVC结构是否良好。该模型位于AppDelegate中，并不理想。欢迎提出任何改善建议。

Answer 1

我只是重新阅读了文档，看来我的一般方法是错误的。我应该首先在沙箱中创建文件，然后将其移动到云中。换句话说，Apple似乎建议我始终保持同一个文件的三个版本：一个位于我的应用程序目录中，一个位于设备的iCloud demon目录中（如果脱机也可以访问），另一个云端：应用程序使用与本地文件和目录相同的技术来管理iCloud中的文件和目录。iCloud中的文件和目录仍然只是文件和目录。您可以打开它们，创建它们，移动它们，复制它们，对其进行读写，删除它们或您可能想要执行的任何其他操作。本地文件和目录与iCloud文件和目录之间的唯一区别是用于访问它们的URL。iCloud文件和目录的URL相对于相应的iCloud容器目录，而不是相对于应用程序沙箱的URL。要将文件或目录移动到iCloud：在应用程序沙箱中本地创建文件或目录。在使用时，文件或目录必须由文件演示者（例如UIDocument对象）管理。使用URLForUbiquityContainerIdentifier：方法检索要在其中存储该项目的iCloud容器目录的URL。使用容器目录URL构建新的URL，该URL指定该项目在iCloud中的位置。调用NSFileManager的setUbiquitous：itemAtURL：destinationURL：error：方法将项目移动到iCloud。永远不要从应用程序的主线程调用此方法；这样做可能会长时间阻塞主线程，或者导致应用程序自己的文件提交者之一陷入僵局。当您将文件或目录移动到iCloud时，系统会将该项从应用程序沙箱中复制到私有本地目录中，以便可以由iCloud守护程序进行监视。即使该文件不再位于沙箱中，您的应用仍然可以完全访问它。尽管该文件的副本仍保留在当前设备的本地，但该文件也将发送到iCloud，以便可以将其分发到其他设备。iCloud守护程序处理确保本地副本相同的所有工作。因此，从您的应用程序角度来看，文件仅位于iCloud中。您必须使用文件协调器对象对iCloud中的文件或目录进行所有更改。这些更改包括移动，删除，复制或重命名项目。文件协调器确保iCloud守护程序不会同时更改文件或目录，并确保将您所做的更改通知其他相关方。但是，如果您深入研究有关setUbiquitous的文档，则会发现：使用此方法将文件从当前位置移动到iCloud。对于位于应用程序沙箱中的文件，这涉及从沙箱目录中物理删除文件。（系统扩展了应用程序的沙箱特权，使其可以访问移动到iCloud的文件。）您还可以使用此方法将文件移出iCloud并移回本地目录。因此，这似乎意味着文件/目录将从本地沙箱中删除，并移至云中。

Answer 2

我一直在使用您的示例，我喜欢它来帮助我掌握iCloud的基础知识。现在，我正在为您自己的应用程序解决您的问题，该应用程序必须使用本地存储的内容来支持该应用程序的现有用户，就我所知，这些内容可能会或可能不会使用iCloud创建这些情况：情况：新的用户有icloud-在icloud中创建文档没有icloud-在本地创建文档现有用户刚刚删除-将以前的icloud文档迁移到本地不只是删除-将文档打开/保存到本地刚刚添加-将本地文档迁移到icloud不只是添加-将文档打开/保存到icloud有icloud没有icloud如果有人删除了iCloud，则对普遍存在的URL的调用不会返回nil吗？如果是这种情况，我该如何将文档迁移回本地存储？我现在将创建一个用户偏好设置，但似乎有些解决方法。我觉得我这里缺少明显的东西，所以如果有人可以看到它，请发出提示。