应用程序设计：处理带有背景上下文的核心数据；合并由 MOC 过滤的通知

Question

我有一个应用设计问题，希望有人能提供帮助。

让我们进行一个非常简单的设置：用于显示来自服务器的新闻项目的 Core Data 应用程序。

• 主线程/UI 有一个托管对象上下文，所有视图控制器都使用它来显示数据。

• 一个 NSOperation 在后台运行，检查服务器，它自己的上下文，在同一个持久存储上。

我想合并后台上下文中的更改，所以我使用 NSManagedObjectContextObjectsDidChangeNotification。

According to the Apple docs:

一些系统框架在内部使用 Core Data。如果您注册以从所有上下文接收这些通知（通过将 nil 作为对象参数传递给 addObserver... 方法），那么您可能会收到难以处理的意外通知。

所以，我想将我在主线程 MOC 中合并的通知过滤为来自后台操作 MOC 的那些更改。

获取/维护对后台操作 MOC 的引用的最简洁方法是什么，以便我可以将一些东西插入 addObserver 方法并正确过滤通知？我能想到很多涉及大量耦合的方法，但它们看起来都像是 hack。

有什么建议或想法吗？其他人如何处理这个问题？

Answer 1

这是它在我的应用中的工作方式：

// should be executed on a background thread
- (void)saveWorkerContext {
    if ([_workerContext hasChanges]) {
        NSNotificationCenter *nc = [NSNotificationCenter defaultCenter];    
        [nc addObserver:self selector:@selector(workerContextDidSave:)
                   name:NSManagedObjectContextDidSaveNotification object:_workerContext];

        NSError *error;
        if (![_workerContext save:&error]) {
            NSAssert(NO, @"Error on save: %@", error);
        }

        [nc removeObserver:self name:NSManagedObjectContextDidSaveNotification object:_workerContext];
    }
}

- (void)workerContextDidSave:(NSNotification *)notification {
    if (_mainContext) {
        [_mainContext performSelectorOnMainThread:@selector(mergeChangesFromContextDidSaveNotification:) 
                                       withObject:notification waitUntilDone:NO];
    }
}

Answer 2

--- 修改后的答案---

使用 NSFectchedResultsController 似乎是您最好的选择。当 MOC 的更改影响它的结果时，它将通知它的委托人。这消除了视图控制器了解或直接观察来自后台 MOC 的事件的需要。

这是我在 NSOperation 工作进程中使用的模式。

将后台 MOC 存储在 NSOperationQueue 子类中，maxConcurrentOperationCount 为 1。这确保操作将连续发生。

• NSOperationQueue 子类
• 为背景 MOC 添加属性
• 实现 NSOperationQueue 的 MOC getter 以从 Persistent 存储中延迟创建后台 MOC，并注册负责将上下文与后台 MOC 合并的类确实保存通知（通常是您的 AppDelegate 或单例）
• 取消注册类的观察并清理dealoc中的背景MOC

创建您的 NSOperationQueue 子类。

在添加操作之前，使用队列的背景 MOC 属性中的背景 MOC 为它们配置。安排好后，您的操作将使用后台 MOC 执行工作并保存。

当确实保存通知进入观察类时执行合并。合并后，每个使用前台 MOC 获取的结果控制器将在任何更改对其结果产生影响时通知它的委托。这包括从后台 MOC 合并中添加或删除。

Answer 3

我不确定我是否完全理解您的问题：如果您只有一个后台线程与您要跟踪的一个特定 MO​​C 相关联，那么没有什么特别的事情要做：使用属性来维护对 MOC 的引用。你照常处理，如下代码sn-p所示。

// create a new MOC
self.backgroundMOC = ...; 

// register to receive notifications
[[NSNotificationCenter defaultCenter] addObserver:self
                                      selselector:@selector(contextDidSave:) 
                                             name:NSManagedObjectContextDidSaveNotification
                                           object:self.backgroundMOC];


// pass backgroundMOC to your background thread
// and handle notifications here
- (void)contextDidSave:(NSNotification *)notification
{
        NSManagedObjectContext *MOC = (NSManagedObjectContext *) [notification object];
        if([MOC isEqual:self.backgroundMOC])
           [managedObjectContext mergeChangesFromContextDidSaveNotification:notification];

}

Answer 4

如果您不想在保存上下文的线程/操作之间进行任何通信，那么识别生成通知的上下文是否属于您的唯一方法是检查其持久存储 url。

只有您的上下文才会有您的商店 URL。 API URL 将具有系统存储或内存存储。

当然，通常情况下，您确实会在进程之间进行通信，并且可以只传递对象引用以进行识别。