问题标签 [uidocument]

当用户在我的应用中启用 iCloud 时，我需要将所有本地文件移动到 iCloud。在这里，我setUbiquitous:itemAtURL:destinationURL:error:用来移动每个文件。问题是，如果（对于任何本地文件）相同的文件 URL 已存在于 iCloud 上，此方法将失败。

我的问题是，如何确定哪个文件更新（本地与 iCloud），以便我可以覆盖 iCloud 版本或丢弃每个文件的本地版本？或者，我能否以某种方式强制 iOS 执行上传并将文件状态设置为 iCloud 上的冲突，以便我的冲突解决方法将接管并处理这个问题？

我的印象是 iCloud 只适用于 UIDocument 文件。其他类型呢？

此外，如果我的用户的文件被上传到云中，如果我的应用程序是通用的，他可以在他的所有设备上使用这些文件吗？

我有一个带有以下方法的单例类（DTTSingleton）：

在我的 UITableViewController 中，viewDidLoad 方法中有以下代码：

执行时出现错误：

由于未捕获的异常“NSInternalInconsistencyException”而终止应用程序，原因：“尝试打开或恢复已经在运行中具有打开或恢复操作的文档

我明白为什么会出现此错误，这是因为我正在尝试打开文档，而另一个打开进程已经在运行。所以我的问题是...

1）如何确保 openWithCompletionHandler 只被调用一次？

2）如何确保文档打开后执行第二个块？

谢谢你的帮助！

我有一个UIDocument基于 s 的应用程序NSFileWrapper来存储数据。“主”文件包装器包含许多附加的目录文件包装器，每一个都代表文档的不同页面。

当保存一个只修改了一小部分页面的大型文档UIDocument时，会在后台花费很长时间来编写更改（在 中writeContents:andAttributes:safelyToURL:forSaveOperation:error:）。当然，它应该只写出对文件包装器的这一小改动……什么花了这么长时间？

我的contentsForType:error:覆盖返回一个新的目录文件包装器，其中包含主文件包装器的内容（à la WWDC 2012 Session 218 - Using iCloud with UIDocument）：

这是来自 Time Profiler 的堆栈跟踪的可爱图片：

顺便说一句，它说要在该工作线程中保存约 1.6 秒 - 在实际运行时间中，这相当于大约 8 秒。

编辑：

有什么方法可以检查文件包装器是否需要写入磁盘？只是这样我可以确认我没有做一些奇怪的事情，比如当我做一个小改动时更新每个子文件包装器（尽管我确定我不是......）。

编辑：

我进一步玩了 CloudNotes 示例应用程序，似乎NSFileWrapper 确实实现了增量保存，至少在这种情况下是这样！我通过初始化一个包含 100 个注释的文档来测试它，每个注释包含大约 5MB 的数据。我在这里和那里做了一个小编辑（文本视图的单个字符更改将文档标记为需要保存），并大致记录了每次保存所用的时间。测试比较粗糙（在模拟器上运行），但结果是这样的：

• 第一次写入：~8000ms
• 第二次写入：~4000ms
• 第三次写入：~300ms
• 所有后续写入：~40ms

显然有很多因素会影响它所花费的时间，特别是因为它在后台线程中使用文件协调来节省，但总的来说，趋势似乎总是这种指数衰减，直到所有写入都变得非常快。

但我仍在试图弄清楚为什么这不会在我的应用程序中发生。对于一个大的多页文档（很大，但仍然比我上面执行的 CloudNotes 测试的文档小很多倍），用户可能要等待很多秒才能关闭文档。我不想为应该几乎是即时的事情设置一个微调器。

我有一个UIDocument基于 s 的应用程序NSFileWrapper来存储数据。“主”文件包装器包含许多附加的目录文件包装器，每一个都代表文档的不同页面。

UIDocument每当我在保存（在）时对文档进行更改时writeContents:andAttributes:safelyToURL:forSaveOperation:error:，应用程序就会崩溃。这是堆栈跟踪：

很明显，我正在修改UIDocument在后台枚举的文件包装器的同一实例。实际上，我检查了在返回数据模型的快照时contentsForType:error:，返回的子文件包装器指向与数据模型中当前驻留（和正在编辑）的对象相同的对象，而不是副本。

这是实施此方法的认可方法（根据WWDC 2012 Session 218 - Using iCloud with UIDocument）。

所以我想问题是：这种方法如何是线程安全的？

当主文件包装器fileWrappers本身是目录文件包装器时，情况是否有所不同？如果制裁的方法是错误的，应该怎么做？

在我基于 iCloud 的应用程序中，我注意到如果在 UIDocument 打开（并且尚未关闭）时发生崩溃，文档的状态有时会变为UIDocumentStateSavingError并且它永远不会再次成功打开。

当我[UIDocument openWithCompletionHandler:]在此之后运行时，文档永远不会打开，返回NOforsuccess和 5 （UIDocumentStateClosed和UIDocumentStateSavingError） for documentState。

在 iOS 5 上，我还观察到它NSMetadataQueryDidUpdateNotification会不断被调用（每秒），直到文件被删除并重新启动应用程序。这会导致应用程序中出现额外的可用性问题。

还有一件事，在 developer.icloud.com 上，我注意到该文件显示了第二个存在冲突的版本。但是，即使重新启动或重新安装应用程序，在我的任何设备上都没有发现此冲突。

我该怎么做才能让 UIDocument 正常打开？

这是我到目前为止所尝试的：

• 使用 .检查[NSFileVersion unresolvedConflictVersionsOfItemAtURL:]冲突并删除所有旧版本[NSFileVersion removeOtherVersionsOfItemAtURL:]。

• 在调用[[NSFileManager defaultManager] evictUbiquitousItemAtURL:]之前调用[UIDocument openWithCompletionHandler:]以将文件重新下载到设备。

• 从 developer.icloud.com 下载主要版本和冲突版本，查看其中是否有损坏或部分文件。两个都开得很好。

• 我的头撞在我的桌子上。初步结果不成功。

在多个设备上密集使用 UIDocument 和 iCloud 时，大量事务日志将保存到 iCloud。这将导致长期使用 iCloud 上的可用空间减少。

我想知道是否有一种方法可以在不丢失数据的情况下清理这些日志，即设备应该仍然能够恢复当前的数据状态？某种日志合并？

我发现，我可以通过以下方法检测到 iCloud 上 UIDocument 的删除：

该方法被正确调用，但我不知道在该方法中要做什么。目前我关闭文档，如果它仍然打开，但看起来文档在关闭时保存在旧路径上，所以文档重新出现。

我已经进行了激烈的搜索，但在 Apple 文档和任何论坛中都没有找到任何内容。

有人有过类似的经历还是有人正确处理了删除？

我注意到 UIDocument 让应用程序知道更改的方法，例如presentedItemDidChange，只有在应用程序在前台运行时才会被调用。

我想知道的是，如果用户要切换应用程序或将我的应用程序发送到后台，我怎么知道 UIDocument 自从用户上次看到它后再次将应用程序带到前台时是否发生了变化？

或者，我是否应该在每次应用程序返回前台时更新所有内容，以防 UIDocument 已更新？

我刚刚阅读了有关在 iCloud 中使用 UIDocuments 解决冲突的文档： 解决文档版本冲突

在“如何告诉 iOS 文档版本冲突已解决”一章的最后一点中写道：

删除文档的已解决版本。对于您不再需要的任何版本，调用 NSFileVersion 的 removeAndReturnError: 方法来回收文件的存储空间。文档修订保留在服务器上，直到您将其删除。

但在代码示例“清单 6-3”中，没有调用 removeAndReturnError: 方法。这种方法不是必需的还是我应该在哪里调用它？

谢谢你的帮助

利纳德