Question

我有一个对象，我从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方法中的核心数据是处理更新的好方法，还是一个非常糟糕的想法（资源过于密集，速度太慢）？

Answer 1

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

Answer 2

这取决于您每次拨打客户设置者时设置和检索的数据量。我会尝试你现在正在做的事情（更新setter中的核心数据），但是在旧设备上测试它，比如iPad 1，看看它是如何运行的。播放一段时间后，您可以决定是否要使用每个setter更新核心数据。

现在，如果你没有看到任何性能差异，我不会担心。你很厉害。通过在setter中提交数据，您可以轻松地从用户那里保存最新的操作。但是，当您保存更多数据和/或大文件/图像并且早期设备开始看到性能差异时，可能会出现这种情况。

为了提前为这种情况做好准备，我建议你的程序中有一个缓冲区（它反映了你的实体的结构），它经常被写入核心数据 - 可能是应用程序运行时处于不活动状态或应用程序进入后台或每个固定时间段。缓冲区必须在setter中更新。您在applicationWillResignActive:中编写代码的想法可能会出现问题，这源于您在处理崩溃时的准备程度。崩溃可能由于任何原因随时发生，有时可能不是因为您自己的错误代码。这就是为什么拥有缓冲区是个好主意的一个重要原因。在崩溃期间（最糟糕的情况），您要么丢失一小块小数据，要么达到性能+一致性（最佳情况）。

模型对象和核心数据

2 个答案: