Mac OS X Leopard - ARCAism

Figure 24-3. Core Data modeling in Xcode
Of course, Core Data is best known for persistence. When the user clicks the Save button,
you’ve got to decide if that data is going to be written out in some binary format, converted to
human-readable XML, or stored in a relational database. Each has its advantages and disadvantages,
but choose wisely, for once you pick a persistence model, you’re stuck with it.
Well, that’s not entirely true. Nothing is going to stop you from throwing out your XML
code and rewriting the whole thing to use relational database. Nothing, that is, except time,
money, and a tremendous amount of wasted effort.
With Core Data, changing your persistence model is as simple as changing your mind. You
haven’t written any code to read and write data, nor to communicate with any database. Core
Data handles all that dirty business for you, so if you want to develop with easily debugged
XML, and then switch to a database for performance, you can.
And if you do decide to use a database, you don’t have to worry about installing a database
management system onto your users’ machines, because all that stuff is already built into
Mac OS X. Oh yeah, and you don’t have to write, think in, or even be aware of the existence
of SQL.
Image Kit
CHAPTER 24 MAC OS X DEVELOPMENT: THE APPLICATION FRAMEWORKS 425
Sometimes an application’s functionality becomes so beloved that it finds itself being copied, in
whole or in part, in all kinds of other places. Consider photo management, once synonymous
with iPhoto. Now you can take pictures in iChat, apply filters in Photo Booth, and view
slideshows in Mail.
When this happens, Apple may factor out that functionality into a “kit” framework. Think
of it as an application without an interface that you can embed into your own application. With
Leopard’s new Image Kit, you can embed all the photo management functionality of iPhoto in
your own application, as shown in Figure 24-4.