How to store CGRect and other things in core data

Question

I'm having a few teething problems with coredata, but feel it would clear things up for me greatly if someone could explain some simple cases to me.

I want to put my model into coredata, and at a most simple case take advantage of undo/redo. Thing is, all the examples I see tend to store either strings or integers. What if I have a class as follows that I wanted to implement in core data (a made up example):

@interface Badge : NSObject {

NSString *textForBadge;
int      badgeValue;
UIColor  *color;
CGRect    rect;
NSMutableArray *awards; // this would be a list of 'Category' - another custom class
}

These are all made up on the spot, but each highlight a confusion

As I see it, I would open the .xcdatamodel and add a new Entity caled 'Badge', which would be an NSManagedObject. I then add a property for textForBadge of type String. So far so good. I do somthing similar for badgeValue, but then come to the UIColor and CGRect and I'm a bit stumped, since there isn't a property for those. Am I supposed to create an entity to represent each (i.e a Rect entity that has four properties x,y,w,h) that are ints? Then populate a CGRect with these ints each time? Ditto for the UIColor?

Finally, I come to my list of awards. If these are a list of pointers to a number of objects representing an award they might contain an image, a colour, text etc. I assume that award would again be an entity I have to design and rather than Badge storing an array I would have a 1 to many relationship from it to the Award class.

Am I getting any of this right, or going in the compete opposite direction? All the examples I see operate on vanilla objects like String or int so want to make sure I have this right in my head before implementing a bunch of stuff.

Kind regards,

Bryn

Answer 1

You have it spot on. I'd put this as a comment, but I don't have that ability yet.

Answer 2

This is the relevant documentation: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/Articles/cdNSAttributes.html but essentially, you have to provide a way for Core Data to translate between your non-standard properties and the kinds of things it can store. There are two ways to do it. Either use transformable attributes and value transformers, or use transient properties and do the conversion only when the managed object context is going to be saved.

I think in most cases, what you describe (defining custom entities to store the components of something like a CGRect) is overkill.

Answer 3

Specifically regarding CGRect you can use NSStringFromCGRect store a CGRect as NSString. Then use CGRectFromString to convert it back:

CGRect rect = CGRectMake( 5, 5, 40, 30 );
NSString* rectAsString = NSStringFromCGRect( rect );
CGRect original = CGRectFromString( rectAsString );

This allows you to easily store it in a NSManagedObject. You can then add a custom accessor in your implementation to convert it:

- (CGRect)realRect {
    return CGRectFromString( self.rectAsString );
}