Mac OS X Leopard - ARCAism

424
CHAPTER 24 MAC OS X DEVELOPMENT: THE APPLICATION FRAMEWORKS
• Specialized collections like character sets, index sets, and pointer arrays
• Data loading—local and networked, synchronous and asynchronous
• Data manipulation, conversion, transformation, and formatting
• XML parsing, editing, and transformation
• System functions like run loops, threads, and timers
• Interprocess communications via pipes, ports, and notifications
• Language services like exceptions, garbage collection, and messaging
It’s not called Foundation for nothing. AppKit and the rest of Cocoa are built on top of
Foundation. This follows the general trend in Mac OS X development: Apple creates tools, and
then uses those tools to make easy-to-use frameworks. Then, it gives developers the tools as well,
so they can modify or add as they see fit.
Foundation, while extensive, might not seem so different from any other basic library. In
practice, however, Foundation is designed with the same ease of use and snap-together design as
AppKit. The classes try to maintain similar interfaces, so, for example, if you decide to refactor
an array into a set, there’s very little effort involved.
Since the interfaces are predictable, it’s easy to keep Foundation in your head, despite its
breadth. And since it’s written in Objective-C, it’s extremely easy to figure out how to use a
method without having to constantly go back to the documentation.
As with AppKit, Objective-C also makes Foundation classes customizable via subclassing
and categorization (one of the many tricks outlined in the section on Objective-C), so no matter
what you need to do, you’re rarely, if ever, stuck having to roll your own.
Core Data
A lot of people had a lot of reasons why Apple could never transition their architecture from
PowerPC to Intel. Yet, when they did just that, most of those reasons ended up being non-issues.
For example, the fact that the two architectures read bytes of binary code in opposite directions
(the so-called endianness issue) ended up not affecting most developers at all.
The reason is abstraction. By using high-level frameworks like AppKit and Foundation,
developers are protected from implementation details like byte order. The Core Data framework
takes that idea a step further by abstracting applications from even their own data.
Traditionally, the system is ignorant of an application’s objects and what they’re doing.
Whether you’ve got a word processing document, a photo album, or a dungeon-roaming adventurer
in a mystical land beyond time and space, to the system they’re all just ones and zeros. You
can ask the system to write those ones and zeros to disk, and you can ask it to read them back,
but when it comes to interpreting what they mean and how the user’s actions affect them, you’re
on your own.
Core Data establishes a generalized object model. As long as your objects conform to that
model, the system can tell enough about them to handle many aspects of their lives with little or
no intervention on your part. For example, undo and redo, traditionally one of the harder problems
to deal with, is free in Core Data.
One of the first things you learn in system design is how to plan your objects, their structures,
and their relationships in an entity relationship diagram (ERD). Xcode, Apple’s integrated
development environment, even provides a graphical ERD tool, as shown in Figure 24-3. With
Core Data, drawing an ERD doesn’t just plan your objects, it also implements them. You can
even drag entities out of the ERD into Interface Builder, and Core Data will generate your entire
user interface!