NSFetchedResultsChangeUpdate - updated object's changedValues dictonary is empty

Question

My tableview cell is quite complex to fully relayout for each NSFetchedResultsChangeUpdate changeType. So I've decided to update it just for specific changes of the changed MO.

I thought, that the changedValues of a MO should contain the changed properties. But sometimes it contains them, sometimes it's an empty dictionary. It's always empty, when the MO has changed on a different MOC, and it contains value if the changes happened on the fetchedResultsController's MOC. I think, if my ViewController going to observe the NSManagedObjectContextWillSaveNotification notification, than the changes could be caught. But I don't want to create a separated logic to handle the updates. This my only chance?

Any idea is welcome how to get the changes of a MO inside the fetchedResultsController delegates!

- (void)controller:(NSFetchedResultsController *)controller didChangeObject:(id)anObject atIndexPath:(NSIndexPath *)indexPath forChangeType:(NSFetchedResultsChangeType)type newIndexPath:(NSIndexPath *)newIndexPath {
if (controller == _fetchedResultsController){

        switch (type) {
            case NSFetchedResultsChangeUpdate: {
                for (NSString *name in [anObject changedValues]) {
                     NSLog(@"Changed property: %@",name);
                     //Make some cell update corresponding the changed attribute
                }
            break;
            }
        default:
        break;
       }
}

I think an other solution could be to get the given tableViewCell and compare the relevant and changeable values between the MO and the cell. But I won't like to add this kind of business logic of my cell. 

Answer 1

The way I normally do this is to give the cell a property describing what to display and override setProperty in the cell to reconfigure it based on the new data.

You anyway have to do something similar for the recycling table view cells, so performance should not be an issue.

As for complexity, you have to write this code only once without having to take into account partial cases, so there should be less complexity.