Question

I’ve been doing iOS now for about two years and mostly by consequence of simple data layers (no real need for ID’s, joins, complex queries, etc), I’ve always managed persistence manually by extending NSObject, conforming to NSCoder, and saving my data in flat files.

However, now I am in a position where I need to start doing more complex query work and I am digging into CoreData.

My hangup right now is with NSManagedObject. It’s a pretty intimidating class and I am wondering if there are any unwritten gotchas I should be aware of that might restrict my freedom while building a sophisticated application.

For example, things like @dynamic getter/setters are not to clear to me, etc

So:

1) Are there any features of NSManagedObject that would prevent me from handling instances of custom classes just as I would with NSObject?

2) Does NSManagedObject have any unusual behavior when objects are handled WITHOUT the presence of a ManagedObjectContext?

3) Can I supplant a @dynamic property declaration with my own custom getter/setter without too much pain? I use a lot of custom setters to enforce business logic.

and so on, and so on.

Thanks

Answer 1

Beware!

Core Data is not lightweight. It will require a lot of changes to the way your objects work, unless they are very basic.

1) Are there any features of NSManagedObject that would prevent me from handling instances of custom classes just as I would with NSObject?

Faulting and the lifecycle of managed objects are a little tricky to understand. Your objects can be “faulted” almost at any time (each iteration of the event loop anyway), which makes them lose any non-persistent state. When they get “un-faulted”, they don’t have access to anything outside the managed object context to restore their state. It’s very hard for managed objects to access anything outside the managed object context.

Transient properties are possible, but are pretty much limited to things that can be computed from the persistent properties, since their state will be lost if the object is ever faulted. You also have to formally declare that you’re using a transient property in the data model. Trying to just set up instance variables will run into problems.

So basically managed objects properties all must be persistent or related to persistent properties. Look at the objects you’re planning to make managed. Are all their instance variables feasible and desirable to put into a persistent store? If not things will not be straightforward. You probably set up your instance variables in your init. There is no init that gets called every time your program runs for managed objects. There are awakeFromInsert and awakeFromFetch, but those don’t work exactly like init. Your code calls init and can pass arguments. The framework calls awake and it gets no parameters.

Threading is another issue to consider. A managed object context, and therefore the managed objects in it, are recommended to be used only by a single thread. If you have multiple threads, and they need to access your model, you need to create duplicate managed object contexts containing duplicates of your managed objects. Core Data is designed to handle that without putting too much strain on memory, disk I/O, and processor, but it isn’t lightweight from a coding perspective.

2) Does NSManagedObject have any unusual behavior when objects are handled WITHOUT the presence of a ManagedObjectContext?

You cannot have a managed object without a managed object context.

That’s not usually an issue. Managed objects carry a pointer to their managed object context. It can be a little limiting though. If something outside your model needs to create a model object as an input to your model, it needs to have access to the managed object context to do that. Hopefully that would be through some kind of abstraction layer so it doesn’t need to know it’s dealing with Core Data, but you can’t just give it a class and have it alloc/init. It is also a bit of work to move managed objects between different managed object contexts.

3) Can I supplant a @dynamic property declaration with my own custom getter/setter without too much pain? I use a lot of custom setters to enforce business logic.

Yes. It’s a bit complicated but doable. You write your own accessors. In addition to your business logic, they must call key-value observing methods like willChangeValueForKey:. Then you access the data using primitive accessors.