0

我有一个从 Core Data 加载数据的对象。然后我使用用户输入/选择修改对象。

我的第一个想法是重写属性的 setter 方法：

-(void)setType:(NSString *)type {
    NSLog(@"setType fired | newType: %@", type);

    _type = type;

    appDelegate *appDelegate = (appDelegate *)[[UIApplication sharedApplication] delegate];

    NSManagedObjectContext *context = [appDelegate managedObjectContext];

    NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] initWithEntityName:DEFAULTS_DB];

    NSError *error;

    NSArray *fetchedObjects = [context executeFetchRequest:fetchRequest error:&error];

    if (fetchedObjects.count == 1) {
        Defaults *defaults = [fetchedObjects objectAtIndex:0];

        defaults.sceneType = type;
    }

    if (![context save:&error]) {
        NSLog(@"Error in saving first run defaults | error: %@", error);
    }
    else {
        NSLog(@"new type was saved to core data");
    }
}

我的另一个想法是在applicationWillResignActive:触发时更新核心数据（但该方法在应用程序冻结之前只运行几秒钟）和用户注销时。

我正在创建的应用程序是用户将启动的应用程序，设置他想要的内容，然后将其放下 10-60 分钟，直到他再次使用它，所以我担心我的应用程序在不活动时被杀死并丢失数据。

在 setter 方法中更新核心数据是处理更新的好方法还是一个非常糟糕的主意（资源密集，速度太慢）？

4

2 回答 2

0

这在某种程度上取决于您在每次调用客户设置器时设置和检索的数据量。我会尝试你现在正在做的事情（更新设置器中的核心数据），但在旧设备上进行测试，比如 iPad 1，看看它的性能如何。玩了一段时间后，您可以决定是否要使用每个 setter 更新核心数据。

现在，如果您根本看不到任何性能差异，我不会担心。你很厉害。通过在 setter 中提交数据，您可以放心地保存来自用户的最新操作。但是，当您保存更多数据和/或大文件/图像并且早期设备开始看到性能差异时，可能会出现一个点。

为了提前为这种情况做好准备，我建议在您的程序中设置一个缓冲区（反映您的实体的结构），该缓冲区每隔一段时间就会写入核心数据 - 可能是当应用程序进入某个状态时不活动或应用程序是否进入后台或每个固定时间段。缓冲区必须在设置器中更新。您编写代码的想法可能会打嗝，这applicationWillResignActive:源于您在处理崩溃方面的准备程度。崩溃随时可能因任何原因发生，有时可能不是因为您自己的代码错误。这就是为什么拥有缓冲区是个好主意的一个重要原因。您要么在崩溃期间丢失一大块小数据（最坏情况），要么实现性能+一致性（最佳情况）。

于 2013-02-14T21:34:13.660 回答
0

这不是典型的使用模式。典型的做法是在显示其数据并保存它之前获取您的对象。然后当用户更改某些内容时，更新对象属性并保存上下文。

于 2013-02-14T21:30:19.270 回答