Question

I’ve read many of the SO questions on NSManagedObject, the Apple docs, and more, but I still don’t really get what subclassing NSManagedObject is for – what role does it play?

In the Apple docs it talks about how I can’t override a bunch of methods, shouldn’t use custom instance variables, blah and blah (I don’t understand some of it yet), and so forth – so what can I do with NSManagedObject? What are the restrictions, must-follow guidelines, and what aren’t restrictions?

I’m trying to make a little box drawing program to learn Core Data, and I’m thinking of adding “draw” methods to a subclass of NSManagedObject so that a view can just tell them to draw for itself – is this permitted?

So, my question in one sentence would be, what’s the “real” difference between subclassing NSManagedObject and any other class – what does Core Data do with it?

If this is too broad, I’ll try to narrow my question down or something.

Answer 1

I still don’t really get what subclassing NSManagedObject is for – what role does it play?

Convenience for the developer – in terms of CodeSense, shorter syntax, and some compile-time checks that help thwart misspellings of keys.

so what can I do with NSManagedObject? What are the restrictions, must-follow guidelines, and what aren’t restrictions?

The UI built into Xcode will make the NSManagedObject subclasses for you – you really don’t need to do it by hand – but, basically, they are just NSManagedObjects with some properties tacked on. Instead of using @synthesize or such, you use @dynamic and Apple takes care of the rest for you – hooking up those properties to getters/setters which mimic what you would normally do with a “bare” NSManagedObject.

I’m trying to make a little box drawing program to learn Core Data, and I’m thinking of adding “draw” methods to a subclass of NSManagedObject so that a view can just tell them to draw for itself – is this permitted?

You could…. but I wouldn’t. This sounds like bad design – try to keep your Model and Controllers separate.

Model objects shouldn’t contain business logic / drawing code. Use the model simply as the “state” of your application. Make something else responsible for the drawing. Plus, while I can’t say this with absolute authority, I believe there is some overhead if you’re dealing with updating / retrieving info from an NSManagedObject.

(Basically, it’s like dealing with an NSDictionary… sorta. It’s less efficient to grab items out of a dictionary than it is to access an ivar.)

For an app that does things like drawing – you’ll probably want to avoid that overhead by making a structure for your in-memory things, and possibly a second, similar structure for persistence/serialization (like to CoreData).

So, my question in one sentence would be, what’s the “real” difference
between subclassing NSManagedObject and any other class – what does
Core Data do with it?

I would say – don’t subclass NSManagedObject by hand at all – use what Xcode gives you. If you want more (other than maybe a custom constructor) then you’re probably barking up the wrong tree.

EDIT:

I think there might have been some confusion about what I meant when I said “don’t subclass NSManagedObject by hand at all”

To elaborate, and incorporate one of the responses:

Start with the data model designer in Xcode, create your models, and use the following menu option:

Then, you could modify the generated class to include custom:

• Constructors
• Data Conversion Methods
• Validation
• Formatting
• Sort Descriptors
• Filters

If your use case doesn’t fit in that list, you should really seriously think about putting it somewhere else (as in your example with the “Draw” method).

All of those things mentioned above could be tacked on to an NSManagedObject subclass which was created for us by Xcode (we didn’t create “by hand”) – and they all revolve around dealing with the data directly (formats / conversions / etc) and/or around pulling the data out of Core Data (filters / sorting).

They don’t add iVars, they don’t perform any complicated operations outside of the scope of data storage and retrieval.