> On Jan 26, 2015, at 12:10 PM, Jerry Krinock <je...@ieee.org> wrote:
>
>
> On 2015 Jan 26, at 07:00, Richard Charles <rcharles...@gmail.com> 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 (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
