为什么每次更改单元格对应的对象的值时都会调用我的`configureCell：`方法？ （但我不保存它。）

Question

I'm making an app where when you select a cell, you're segued to a new view for reading. The cell you tapped on corresponds to an object in the Core Data store (through NSFetchedResultsController ) and that object is set as the value for the article property of the view that is being segued to.

Once there, I move the position of the user in the article as they read it. (So I alter the position attribute of article via article.position = ... )

However, this occurs very frequently as they read, often hundreds of times, and each time NSFetchedResultsController is detecting the change as an update, then calling configureCell: , which then runs through a bunch of configuration for that cell. As this configureCell: method is called so often (and I only want it to be called when they go back to the table view, as that's the only time the update is needed) it's causing a decent performance loss.

I don't get why it's calling it though. I'm not saving the data with NSManagedObjectContext into the Core Data store, so why does it care? I only call that when viewWillDisappear is called, indicating that they're leaving the view, likely to go back to the table view which is where I want it!

Basically, how do I get it to only call configureCell: when it needs to/when I ask it to write the data to Core Data? It's calling it hundreds of times as is.

Answer 1

It doesn't matter if you're not persisting the changes to Core Data objects to disk; a change to a Core Data managed object IS a change, and so NSFetchedResultsController acknowledges it.

You could avoid updating the tableview that's not visible by setting NSFetchedResultsController's delegate to nil in viewWillDisappear: , and setting it back to self in viewDidAppear: . Also, add a performFetch: after setting the delegate.

The "hidden" NSFetchedResultsController will still be receiving all the changes made to the article object in the view that's in the foreground, but will ignore them since it doesn't have a delegate.

When going back to the articles list view, it will have a delegate again, and it will be able to react to all changes.