2

好的，假设我正在制作一个观鸟应用程序。

有一个“官方”鸟类数据库。其中存储在一个UIManagedDocument. 它用于填充UITableView所有鸟类，并使用图片和数据为每个鸟类提供一些详细的视图。该数据库将在未来升级，包含更多鸟类。

然后用户可以到农村去拍鸟。他将它们添加到应用程序的另一个部分，称为“日记”，当他识别出这只鸟时，他会将其与一只“官方”鸟联系起来。此信息（所有用户收集的数据）应使用 iCloud 进行备份。它还用于填充日记UITableView和详细视图。

从日记的详细视图可以转到“官方”鸟的详细视图。从该视图中，您可以转到包含该鸟在用户日记中的所有登记册的列表。

问题是：我应该UIManagedDocument为每个用户条目使用一个吗？这如何UITableView与缩略图一起使用？

4

3 回答 3

3

AUIDocument是物理文件包装器的管理类。AUIManagedDocument是提供 CoreData 堆栈的子类。

文件包装器只不过是文件夹或文件的抽象。对于UIManagedDocument该文件夹包含 CoreData 堆栈连接到的 SQLite 数据库。

您不会将单个文档用于日记条目，就像您不会将单个 Word 文档用于每个写作段落一样。

由于您的应用程序听起来更像 Apple 所说的“鞋盒应用程序”，其中一个用户拥有一堆数据，他们可以添加和减去这些数据，因此没有真正需要使用文档架构。然而，这UIManagedDocument为您提供了一个免费的堆栈，因此可能很有用。

如果是我在构建这个应用程序，我可能会采用这种方法。

  1. 您的官方鸟类的只读数据库。该数据库在首次启动和需要更新时下载。你不应该试图把它放在你的包中，因为它会很大。它不会在任何时候备份。

  2. 一个包含您的日记条目的读写数据库。此数据库备份到 iCloud，并且不会在 Bird 数据库的升级中涉及。

  3. 通过使用 GUID 而不是 CoreData 关系松散耦合两个数据库。

在此处输入图像描述

例如，野鸭的 GUID 可能是DUCK1234. 将该 GUID 作为属性（例如 birdGUID ）写入您的日记条目。要查找野鸭的所有日记条目，请在日记数据库上对“birdGUID == 'DUCK1234'”进行查询，然后您就会得到所有发现的时间。

这样做的原因是您可以升级官方鸟类数据库，而不必担心损害用户数据。假设您购买了一个更好/更便宜的数据库或另一个有鸟叫的数据库，您可以调整架构以应对这种情况。

编辑

一种方法（一种简单的方法）是用两个NSPersistentStores 

NSPersistentStoreCoordinator *myPersistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:[NSManagedObjectModel mergedModelFromBundles:nil]];

NSDictionary *readonly_options = @{NSReadOnlyPersistentStoreOption:@YES};

[myPersistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:officialBirdStoreURL options:readonly_options error:&error];

NSDictionary *readwrite_opts = @{NSMigratePersistentStoresAutomaticallyOption:@YES,
  NSInferMappingModelAutomaticallyOption:@YES};

[myPersistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:diaryStoreURL options:readwrite_opts error:&error];

NSManagedObjectContext *workingContext = [[NSManagedObjectContext alloc] initWithConcurrencyType: NSMainQueueConcurrencyType];

workingContext.persistentStoreCoordinator = myPersistentStoreCoordinator;

我不会完全解释这一点，因为有很多优秀的核心数据教程，但请注意NSReadOnlyPersistentStoreOption在您的 Bird 数据库上设置。

这不涉及使用UIManagedDocument，因为您没有对堆栈进行足够的控制。

总而言之，堆栈从下到上。

  • UIManagedDocument- 模型控制器。处理文件包装机制并提供免费堆栈。不需要。可能使多文档应用程序更容易（或不）。
  • NSManagedObjectModel- 模型，你的核心数据模型的模式。
  • NSPersistentStore- Model ，表示磁盘上的单个 SQLite 数据库。
  • NSPersistentStoreCoordinator- 任意数量的控制器NSPersistentStore
  • NSManagedObjectContext- 模型工作区，就像一张便条纸。使用和保存或使用和丢弃。

在这个阶段不要被束缚UIManagedDocument。它是文件系统的控制器，顶部有一个 CoreData 堆栈。它不能做你想做的开箱即用的事情。

担心真正的问题是如何加载两个数据库并使用它们的数据来驱动你的 UI。

如果以后它真的很重要，您可以移动基于 UIManagedDocument 的体系结构。如果这是我的应用程序，我不会打扰。

于 2013-09-13T14:58:52.297 回答
0

我什至不确定我是否会UIManagedDocument为您的应用提案使用一个，更不用说为每个用户条目使用一个了。如果您的应用程序设计旨在根据区域（例如）包含多本鸟类“书籍”，那么UIManagedDocument每个“书籍”都是有意义的，但在我看来，您正在制作一个单一的鸟类数据库，这将是随着时间的推移建立起来，加上一个列出用户全部信息的“日记”（但仍然是主要鸟类数据库的一部分）。

你的应用听起来像是一个直接的基于核心数据的应用的候选者。您的模型设计将包含鸟类记录，以及代表“日记”的记录，该记录与鸟类记录的“现场用户条目”相关联。即使您有多个“日记”，UIManagedDocuments这似乎也有点矫枉过正，并且可以更好地坚持“简单”的核心数据实现。

为了简单起见，使用一个NSFetchedResultsController来管理 Core Data 和您之间的交互。UITableView

在我看来，合并多个UIManagedDocuments会使你的设计变得相当复杂。

于 2013-09-12T14:07:24.260 回答
0

如果你去看UIManagedDocument我的 github repo https://github.com/dtrotzjr/APManagedDocument - 它可能有用，也可能没有。;-)

于 2013-09-13T23:23:10.443 回答