Re: Detecting Managed Object Property Change From Undo Redo
Re: Detecting Managed Object Property Change From Undo Redo
- Subject: Re: Detecting Managed Object Property Change From Undo Redo
- From: Richard Charles <email@hidden>
- Date: Mon, 26 Jan 2015 17:10:01 -0700
> On Jan 26, 2015, at 12:10 PM, Jerry Krinock <email@hidden> wrote:
>
>
> On 2015 Jan 26, at 07:00, Richard Charles <email@hidden> wrote:
>
>> Where do you post the notification from for a managed object property change?
>
> Just to clarify: Your question refers to how I do it in my real apps, using NSNotificationCenter, not how I did it in the YouTube video, which was demonstating KVO.
>
> Commonly, I use a custom setter, like this:
>
> - (void)setRating:(NSNumber*)newValue {
> [self postWillSetNewValue:newValue
> forKey:constKeyRating] ;
> [self willChangeValueForKey:constKeyRating] ;
> [self setPrimitiveRating:newValue] ;
> [self didChangeValueForKey:constKeyRating] ;
> }
>
> wherein the -postWillSetNewValue:forKey: posts notifications.
>
>> It doesn’t work in a managed object's custom public property accessor because the public property accessor is not called during undo redo.
>
> Ah, I’d forgotten about that. Indeed, the undo and redo tasks registered by Core Data do not try and put things back in order using public accessors the way I would (screw it up). Instead, Core Data registers these annoyingly opaque undo and redo tasks that, I presume, just change the whole object graph to a previous (consistent) state in one fell swoop. I think that’s why Core Data does undo and redo so reliably. But real apps often need to observe all object changes, and so the resulting un-observability transfers the complexity elsewhere. [1]
>
> The way I’ve worked around that is to, as Mike Abdullah said, register for NSObjectsChangedInManagingContextNotification. I do it in a kind of “entity manager” class that also does some fetching, etc. But read the NSObjectsChangedInManagingContextNotification documentation and understand the edge cases in which this notification does not get sent. Other patches may be necessary.
>
> So, going back to my YouTube video, I think you should take another look at using KVO. The fact that it "just works” with undo and redo is nice, and with tricks like Kyle Sluder’s crafty -startObserving… and -stopObserving… methods, the bookkeeping may be tractable.
>
>
> 1. Google: “there are no solutions only tradeoffs”
>
It is not uncommon for this application to work with large data sets. I tested using KVO on a managed object property and undo took 34 seconds. I implemented custom accessors (public and primitive) containing custom change code and undo took 3 seconds.
I have not tested using NSObjectsChangedInManagingContextNotification to see how long an undo would take but the thought looking through the notification for specific properties in specific objects seems daunting. I saved out the notification description for the change mentioned above and it was a 29 MB text file. So using notifications from the managed object context for this property change does not seem to be the way to go.
It looks like using custom public and primitive accessors is the way go. Not for everything, but where it is needed.
Richard Charles
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden