CoreData. It’s one of those looming technologies of Cocoa that people put off. I did, most coders I know did. Mainly because it’s thought of as a big looming technology. If you’re not sure if you need to learn CoreData, take the following quiz:
- Are you writing a Cocoa app?
- Do you need to save any data between launches of your app?
If you answered no to either of the above questions, you probably don’t need CoreData. Otherwise, you most definitely should start learning it now.
When I say now, I mean now. Right now. Not tomorrow. Yesterday. It may not be the right fit for what you’re doing 100% of the time, but you won’t be able to make that decision until you’re informed. If you do decide to use it and you have a large set of model objects already written, you’re going to spend a lot of time re-implementing them afterwards. Just like I did. Then you’ll be grumpy. Maybe after that, slightly hungry. Go get a snack.
On Difficulty
It’s not hard. Get that out of your head. In fact it’s easier, because you build the data models and you can see them visually. That is until you have a marginally complex object model, then Xcode kind of shits the bed on the visual portion. That shouldn’t really be the end of the world, I never found much use for the visual part anyways. No more writing pages of SQL inserts, updates and migration code. It’s so easy it falls into the scary as shit realm (that’s the technical term).
On Autogenerated Code
A lot of tutorials simply use NSManagedObject directly. I don’t like that personally. Subclassing NSManagedObject is trivial and you let XCode remember how to spell things properly while you focus on more important details. One thing I would suggest is to not modify the auto generated code. Now before you get all hot and bothered, I’m not suggesting you not add to the code in any way, just those files. To add modifications, write a category. Have I mentioned I love categories before? The reason here is that as you augment your data model, you’ll want to regenerate the code. By adding supplementary code as a category, you don’t have to constantly be copying code from older revisions forward manually.
On Boilerplate Code
Mike Nachbaur has an excellent post on better organization of CoreData management code, including moving the stack to a singleton, instead of embedding all of the magic sauce in the AppDelegate as auto generated & tutorial code all seem to do. Go read his post now. For serious. This perturbed me when reading up on CoreData, it’s good to see I’m not alone. Mike’s code works great and pretty much drops right in. The only modification I made was to change:
- (NSManagedObjectModel*)objectModel {
// ...
NSBundle *bundle = [NSBundle mainBundle];
if (kDataManagerBundleName) {
NSString *bundlePath = [[NSBundle mainBundle]
pathForResource:kDataManagerBundleName ofType:@"bundle"];
bundle = [NSBundle bundleWithPath:bundlePath];
}
// ...to:
- (NSManagedObjectModel*)objectModel {
// ...
NSBundle *bundle = [NSBundle bundleForClass:[self class]];
// ...This is simply because I was implementing it in a framework bundle, so it was easier that way.
But is it relational? (or some other DBA question)?
Who cares? You can do fetch requests, they’re fairly easy. You probably want to avoid Abstract Entities if you ever intend to look at the SQLite, or if the abstract portion of the entity is minimal (say you have 4 shared attributes, and 50 attributes independent to each implementation). The reason I say this is that abstract entities are denormalized. Whether or not this bothers you or is exactly what you want, it is something you should be aware of. If you’re developing for a device with limited storage, like a phone, data denormalization makes for big tables. In a simple example with PlanuKit, my three test games took up double the space when I was using Abstract Entities.
Final thoughts
When I first had the inkling to actually learn this, I did what I normally do for pretty much any technology. Ask Mark. I’m sure you have your own Mark, the guy who no matter what technology you’re about to jump into has done it himself years ago. Our conversation went something like this:
Cameron: Is there a good rule of thumb as to when to use Core Data?
mhp: Do you need persistent data in any way?
Cameron: Yeah.. but…
mhp: Just learn it.
… weeks later …
Cameron: So.. when you told me to just learn Core Data, I kinda put it off, retrofitting is a bitch.
mhp: When will you learn that everything I say is golden?
Cameron: Learning is for chumps. Fact.
Always do what Mark tells you to do.