Core Data’s attributes type may be the “standard” ones (strings, numbers, dates.). For the “less standard” attributes there are built-in transformers (images, attributed strings). I’m not sure about arrays, so I have to serialize it myself: I’m using NSArchiver/NSUnarchiver to transform the color reference NSMutableArray into/from NSData. The attribute type is “Binary Data”.
It works well, but it has a smell of “Do It Yourself” coding. I’m not really satisfied with this solution.
A more proper way would be a subclass of a unique NSManagedObject, which could initialize on demand, store and deliver the data into the “awakeFromFetch” and “willSave” methods.
An even better solution would be to “connect” the two properties (entity attribute and NSView NSMutableArray), either by addObserver or via a NSValueTransformer, I don’t know how for the moment. Or maybe the built-in transformers of Core Data would do this job for me. the docs are still unclear for me.
Anyway, I’m still looking for the best (read: elegant) solution for implementing this design. I’ll keep you informed.
You’re certainly right. I’m now moving ever more “intelligence” into specific subclasses, and my app looks a bit better object-oriented that my former ASOC version (where my BASIC-looking appDelegate was doing all the job). I have now objects that talk to each others, and everything is KVO compliant.
It’s particularly handy to give my subclasses Outlet properties and interconnect them in IB: it saves a lot of code (testing if an object is the good one, setting and getting variables, of accessing values with ugly code like [[[[myController arrangedObjects]lastObject]setValue: newValue to key:@myKey], using observers, and so on.)
Thank you for having supported me in this way.
Core Data lends itself particularly to do so: because the framework manages the “basic” housekeeping like instantiating, reading and saving the files, and multi-level undo, the document delegate is very, very. empty. A lot of things is updated “magically” by bindings, so the real work (which cannot be avoided) is made “internally” by the subclasses, which operate directly on themselves, as it should be in OO programming.
And of course, without talking about reusability, you may be confident that “ok, this piece of code works, leave it alone and concentrate on something else.”
EDIT: Yes, built-in transformers DO the job: an NSMutableArray may be automatically serialized if the attribute type is set to “Transformable”. Great.
Now for the connection. Without this connection, the NSMutableArray transferred to the NSView is not KVO.