re: NSManagedObject subclass accessor pattern mystery?
re: NSManagedObject subclass accessor pattern mystery?
- Subject: re: NSManagedObject subclass accessor pattern mystery?
- From: Ben Trumbull <email@hidden>
- Date: Tue, 30 Sep 2008 03:08:31 -0700
So I have a CoreData app (10.5.5, 64 bit only) that has a
NSManagedObject that has an NSColor* that is part of its data model.
Because this color is actually a computed value that we want to cache,
it is declared as a property:
@property (retain) NSColor* color;
but since we may need to calculate it, we also map it to an instance
variable _color:
... this doesn't follow. That you need to calculate it doesn't mean
it has to be in an ivar.
@synthesize color = _color; // we actually implement both setter and
getter - should we stil declare this?
Modeled properties should never be declared synthesized. (a)
pointless (b) unhappy
The problem I have is that I want to cache the components of the
color as well (as
separate CGFloat properties)
I have the feeling this is your only actual problem, and everything
else would go away if you just used the standard modeled properties
conventions.
The best place is in the -awake* methods, specifically -awakeFromFetch
You should also have a custom setColor public setter for when you
update the value. Core Data won't call that because Core Data doesn't
update your values, you do.
In other words, I read my document off of disk, and CoreData magically
makes sure that my "color" property is set. But since it never seems
to call my setColor: setter
Correct. Core Data rarely uses the public accessor methods. Those
are for you and your client code. Semantically "initializing" the
object from the database values and "setting a new value" are very
different operations.
thought that perhaps if I just observed when the "color" property
changed, I could fire then: but that code never seems to fire either.
Exactly. The values have not changed. Ideally, there should never be
KVO notifications from an object simply being restored/initialized.
There are still some places where practically and ideally don't yet
meet, but we do try to not issue superfluous notifications.
Digging into the
documentation some more, it seemed that implementing this might do the
trick:
- (void)setPrimitiveValue:(id)value forKey:(NSString *)key {
if ([key isEqualToString:@"color"]) {
[self setColor:value];
return ;
}
[super setPrimitiveValue:value forKey:key];
}
Uhm ... the documentation says:
"you therefore absolutely must not override: primitiveValueForKey:,
setPrimitiveValue:forKey:"
Try Dave's suggestions about using transformable properties, and the
references to the custom accesors.
- Ben
_______________________________________________
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