Theocacao
Leopard
Design Element
Comment on "Cocoa Developers Are Spoiled"
by Scott Stevenson — Feb 17
Surely we've had to give up some of the control that we once had, it's no longer our glue-code. It must now be taken care of Apples black-box. Right?

To address this in broad terms, using a generalized framework always means you're giving up some level control, but control also means responsibility. If you know for sure that you can write a better persistence engine, then don't use Core Data. If you trust Apple's extensive experience with this sort of thing, then you can ride the wave.

Of course, there's a middle ground. It's not as if you stuff data in one end and something mysteriously comes out the other side. There are many opportunties for customizing, tweaking and subclassing along the way. For example, you can use Core Data for change tracking and do your own persistence layer.

And I find it hard to believe that Apple Core Data and Controlling interfaces would be able to handle all my needs. To be sure there will be something that I want for my .app that CD/MOC will not be able to handle?

Only the most simple apps can get away without writing custom code. Anything serious will simply use Core Data as a more evolved base starting point, and build up from there.

Core Data appears to be new to Tiger, right? I guess this immediately locks you into 10.4 if you where to release an .app. I guess this is a individual, or enterprise decision more than anything.

Yes. The reason Apple invested time in Core Data is to encourage developers to create Mac-first and Mac-only apps, increasing the Mac OS X's attractiveness. The developer reaps the rewards of simplified development in return.

Wouldn't you find that perhaps your .app is constantly locked into the latest version of OS X? In the ideal world everyone would upgrade, but we all know this not to be the case. What's your thoughts here?

There's no complex equation here. The frameworks get better with each release, and you support the best version you can. It's also not just a matter of how many users are on a particular version of Mac OS X. Sometimes a new framework or a newer version of an existing framework makes a particular app practical for the first time. In that case, it makes sense to require the newer OS (even if, say, only 10% of your users have it) because otherwise the app doesn't exist at all.

Are you worried that as your .app evolves (during dev. or after release) and as features creep into your system, this (apparently) hard coded Model becomes difficult to maintain?

The model is actually not hardcoded. It can be manipulated with the NSManagedObjectModel API. Model versioning is more difficult than any of us would like, but it is possible and Apple does provide sample code.

From what I've read, if you change your Model you can no longer open your existing XML/Bin/SQL model files/dbs.

That's a vast oversimplification. You have to be aware of the issues, but it doesn't make older files unreadable.

In your opinion with Core Data and the MOC, is this production strength design and .app building? I often see Core Data code floating around Apples developer website, and this makes me wonder if indeed the CoreData/MOC is not flexible enough, and you do often resort to code.

I don't think the Core Data design is as rigid and restricting as you think. I think my earlier answers address most of this, but let me know if you have further questions. The short version is that "real" Core Data applications are not codeless. The point is that you can get basic prototype functionality before writing code, and you don't bog down the project with redudant classes.

For what it's worth, Aperture uses Core Data, and it's obvious not a trivial app.
Back to "Cocoa Developers Are Spoiled"
Design Element

Copyright © Scott Stevenson 2004-2015