问题标签 [uimanageddocument]

我开始了解UIManagedDocument它的能力。据我了解，它是一种存储在文档目录中某个位置的数据库形式。

无论如何，我试图将它用作数据库，通过将数据存储在其中NSManagedObjectContext但是，在创建UIManagedDocument数据并将数据保存到其上下文几秒钟后（在我猜测超时之后），应用程序崩溃并告诉我没有持久的存储协调器。

Apple 文档上似乎没有太多关于如何在创建托管文档后创建持久存储协调器的指导。

我该怎么做？

谢谢！

编辑

我正在使用的代码：

更新

在后台线程上执行此代码后。打开文档后，我的应用程序仍会在完成处理程序上成功记录“否”。但是，我的应用程序没有崩溃，而是得到以下日志：

此方法还创建一个“DocumentMetaData.plist”（根据我在评论中提到的 CS193P 视频中提到的这些文件，我认为这是必要的）而不是一个名为“persistentStore”的文件。

我正在使用斯坦福的 CoreDataTableViewController 来显示动态表。

应用程序如何工作：要向该表中添加一行，会弹出一个子屏幕进行数据输入，当子屏幕关闭时，插入新创建的 managedObject，并通过回调重新加载表。

我注意到在重新进入屏幕后，新添加的行会间歇性地从表中丢失。我注意到这种行为仅在第一次使用 saveToURL 创建 UIManagedDocument 对象时发生。随后，在重新启动应用程序并使用 openWithCompletionHandler 打开 UIManagedDocument 后，列表始终正确显示。

这是我用来创建/打开 UIManagedDocument 的代码：

运行上述代码时，始终调用 onDocumentDidLoad()，成功标志为 YES。

非常感激任何的帮助。提前致谢！

- 编辑以下代码以显示我的创建方法，然后关闭并重新打开文档以响应 Jody - 我仍然遇到同样的问题。---

在使用 Core Data 时，我发现我的UIManagedDocument对象的 adocumentState等于 5。UIDocument文档只定义了这些常量：

这将是 0、1、2、4 和 8。5 可能是使用的特殊状态UIManagedDocument，但我在任何地方都找不到它的记录。当核心数据模式发生变化时，状态似乎发生了。我不知道国家是什么意思。我通常会收到错误：Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'This NSPersistentStoreCoordinator has no persistent stores. It cannot perform a save operation.'，这是有道理的，因为文档需要以正常状态打开才能用作持久存储。

现在我只是检查状态是否等于 5 并删除持久存储并在发生这种情况时重新创建它。但是一旦我的应用程序上线并存储用户数据，我就不想这样做了。managedDocument.documentState == 5我还没有研究过迁移核心数据模式的最佳实践，但在我的代码中进行检查似乎也有点混乱。在任何地方都没有关于此文档状态的任何文档吗？

更新：现在我正在查看它，这是有道理的，这些常量被定义为它们的方式的原因是它们可以按位或一起作为掩码。因此，documentState等于 5 意味着它既是UIDocumentStateClosed也是UIDocumentStateSavingError。不过，这些错误非常普遍。我将如何缩小根本原因？

此外，我看到的所有用于检查这些文档状态的示例代码都显示检查是否相等， ie if (managedDocument.documentState == UIDocumentStateClosed)，但这意味着这是不正确的，应该使用按位与检查，即 ie if (managedDocument.documentState & UIDocumentStateClosed)。

我正在创建一个 NSManagedObject 子类 ( Group)，设置一些属性/属性，然后将其传递给不同的对象（它存储在strong属性中）。该对象获取一些Group信息并通过GCDAsyncSocket. 服务器响应一些信息，然后我想将这些信息存储为Group. 但是，当服务器响应并GCDAsyncSocket调用 的委托时，所有的Group属性都设置为nil。

由于我正在使用UIManagedDocument我的核心数据实现，当自动保存启动时，我收到以下错误：

错误域=NSCocoaErrorDomain 代码=134030“操作无法完成。（Cocoa 错误 134030。）”UserInfo=0x1f5c96f0 {NSAffectedObjectsErrorKey=("<Group: 0x1f5aa300> (entity: Group; id: 0x1f5c73b0; data: {<entities)这里, nil values>})" ), NSUnderlyingException=无法更新从未插入的对象。}

但是，我知道对象已插入。它做了一些研究，发现了很多与使用两个或多个不同的托管对象上下文相关的问题，但这不是我的问题（因为我得到的唯一托管对象上下文来自UIManagedDocument.

一些代码：

有人知道我在这里做错了什么吗？

我已经设法了解如何将 UIManagedDocument 合并到一个简单的测试应用程序中，并且它可以按预期工作！但是，现在我正在添加对这个基本应用程序的支持，因此如果用户不想使用 iCloud，它也可以工作。

因此，当该URLForUbiquityContainerIdentifier:方法返回“nil”时，我使用建议的方法返回本地文档目录的 URL

但是，当我尝试将 a 保存UIManagedDocument到本地 URL（例如：）时，file://localhost/var/mobile/Applications/some-long-identifier/Documents/d.dox我收到以下错误：

使用此保存方法：

如果 ubiquity 容器（iCloud 文件夹）由于某种原因不可用，我会将任何新文档添加到用户的“文档”目录，但是，如果它再次可用，我会将文档添加到 ubiquity 容器中。

我的问题是，保存被视为无处不在的容器的文档的最佳方法是什么，如此不可靠？

例如，如果用户关闭云中的文档，这些文档就会被删除。发生这种情况时是否有通知要收听，以便我可以将它们传输到本地目录？

反之亦然，如果用户打开云中的文档，是否有将文档从本地移动到无处不在的存储的通知？

谢谢

UIManagedDocument 的文档中简要提到了

为了支持异步数据写入，Core Data 实际上使用了一对嵌套的托管对象上下文。

这是特定于 UIManagedDocument 或 Core Data 的吗？

同一份文件还指出

如果合适，您可以将数据从后台线程直接加载到父上下文。

这是否意味着在下面的代码中

我应该简单地将第一行替换为

做到这一点？

我想我也对直接使用这个父上下文在哪里“合适”感到困惑。我的意思是，这听起来已经像是 performBlock 用于将任务卸载到后台队列。为什么我需要弄乱父上下文？

如果有人为我澄清所有这些，我将不胜感激。

UIManagedDocument只要设置了属性“文档”（类型），我就有以下代码在我的视图控制器上使用。

我不确定其他人是否这样做，但我发现 Core Data 中的并发概念非常令人困惑，文档中有一个解释它，但仍然很难掌握。出于这个原因，我想知道人们是否对如何加快我用来保存新设置的代码（UIDocument如果它不存在）有任何想法。如果其他人想使用它，此代码确实有效。

我的主要目标是尝试缩短文档保存和加载所需的时间。目前执行此操作大约需要 20 秒，这太长了！

应该在UIManagedDocument我的两个设备上打开相同的内容，然后保存（使用以下代码）：

我被告知UIManagedDocuments documentState 更改为UIDocumentStateSavingError然后我收到此错误：

有谁知道为什么会发生这个错误？

最近，我正在使用 iOS 中的时间表应用程序，但我在使用 Core Data 时遇到了麻烦。

我的应用程序有一个类似于 Apple 创建的原始日历应用程序的主用户界面，我将所有事件数据保存在 Core Data 数据库中。

我创建了一个UIManagedDocument以使用其NSManagedObjectContext从数据库中获取数据，并且一切正常。

但是，我需要在运行时使用NSManagedObjectContext在几个不同的视图控制器中多次获取数据。每次我这样做时，我都需要重新打开UIManagedDocument，但打开文档需要太多时间（可能需要 2 秒甚至更长时间，我必须在视图中显示微调器）。

所以这是我的问题：

1. 打开 managedDocument 的正确方法是什么？（我的意思是在午餐图像时间打开它？）
2. 有没有办法只打开一次 managedDocument 并在运行时保持打开状态？（所以我可以一直使用它的上下文）
3. 数据是否存储在我创建的 managedDocument 中？（我发现如果我删除文档，数据就消失了）

谢谢。