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: Jerry Krinock <email@hidden>
- Date: Mon, 26 Jan 2015 23:32:22 -0800
> On 2015 Jan 26, at 22:14, Quincey Morris <email@hidden> wrote:
>
> On Jan 26, 2015, at 17:55 , Jerry Krinock <email@hidden> wrote:
>>
>> What in the world is that nonCompliantKVCivar?
>
> It’s just an ivar that was defined separately from this particular code fragment. It’s “non compliant” because Core Data doesn’t have a way of backing a property with ‘short’ scalar storage.
I don’t think so, Quincey. You seem to be saying that the only example given by Apple is a bad example, because it is a a nontypical, special case. I mean, most attributes in most apps are objects, not scalars. The ‘rating’ I used as an example is a NSNumber object. But I really don’t think that matters to this discussion, so let’s move on…
> There’s sort of no point in doing exactly this, BTW …
> All that’s going on here is that Core Data doesn’t use ivars as backing storage for properties …
> This explains, a primitive accessor. It’s a rare thing, an un-duck …
All very good explanations.
>> So this instance variable is somehow tied to the persistent store.
>
> It’s not, though. You must have done something wrong that made it work (!). I have a theory about that, which I’ll get to in a moment.
I’m going to skip up to there now…
> My guess is that you provided an implementation of ‘setPrimitiveRating:’ (the setter), but that you *didn’t* provide an implementation of ‘primitiveRating’ (the getter).
Your guess was correct. So I corrected that mistake and re-ran the experiment with both setter and getter,
- (void)setPrimitiveRating:(NSNumber*)newRating {
_rating = newRating ;
}
- (NSNumber*)primitiveRating {
return _rating ;
}
> you will then have to do extra work to get the value to persist, since the ivar itself doesn’t”.
Nope. It still persists! Apparently, the persistent store is written by the public accessor, and/or there is some magical connection between the public and primitive.
But with my mistake corrected, the user interface now works again. Essentially, the app works just the same without those trivial primitive accessors and ivar, as with them. So far, we’ve done no harm.
But the useful thing is that, as Richard Charles claimed, and I’ve now confirmed this, although the public accessors do not get invoked during Undo and Redo operations, the primitive accessors do. So, provided that he implements both the primitive setter and getter, he can slip some code into the getter to post a notification of the value change.
_______________________________________________
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