views:

98

answers:

1

Yeah, the documentation has an example:

@interface Circle : NSManagedObject
{
    CGFloat radius;
}
@property CGFloat radius;
@end

@implementation Circle

- (CGFloat)radius
{
    [self willAccessValueForKey:@"radius"];
    float f = radius;
    [self didAccessValueForKey:@"radius"];
    return f;
}

- (void)setRadius:(CGFloat)newRadius
{
    [self willChangeValueForKey:@"radius"];
    radius = newRadius;
    [self didChangeValueForKey:@"radius"];
}
@end

But that's pretty much everything. So: How would I model that? And imagine this was a CGRect...there's no such type to select. So how can this work? There's a big piece of the puzzle missing. I guess these are transient properties of undefined type??

+1  A: 

See Core Data Programming Guide Non-Object attribue

Short answer, you define them as transients of an undefined type and then store their values in one or more persistent attributes.

I like a lot of fine grain in my models so in this case I would create a separate entity to model the rectangle. It would have four attributes of float. It would have transient values to set and get an actual rectangle object.

(CGRect are IIRC actually support by the NSKeyedArchiveProtocol so you don't have to do this for them.)

When you generate a custom NSManagedObject subclass, the attributes of that class are not limited to the attributes of the entity defined in the data model. You can go crazy and slap on all kinds of attributes of any type as long as you don't try to directly store that type in the persistent store.

TechZen
I see. So if I would make an attribute of type Transformable, and don't define any custom transformer class, then the NSKeyedArchiver is used which is able to archive an CGRect? Starts to make sense...
dontWatchMyProfile
Yes. Most API provide types can be save without to much fuss.
TechZen