Understanding the Value of Core Data When Creating Apple iPhone Applications

Ray Kiddy

(The following is an excerpt from iPhone Advanced Projects, published by APress)

The iPhone is an amazing device for getting information at a moment's notice. Whether I am waiting for a train, waiting in line for coffee, or waiting on hold for someone to pick up the phone, thoughts come to me, and I may need to answer a question quickly in order to do something useful with the thought. If I wait until later, when I have more time, then I have often forgotten the idea or question.

The iPhone has a lot of data applications suited to whatever particular task you have. And if you have that niche market idea or that odd situation where people want to organize information in some particular way, you can create your own data application for them. The iPhone has tools that make it surprisingly easy to design these apps so that you can let users use your interface and reuse their data in interesting ways.

The key to designing a good data application for the iPhone is simplicity. For most data people, this cuts across the grain. Every time I create a data application, I want the application to know everything, do everything, hold the users in its hands, and make them feel comfortable because absolutely everything is taken care of by the application. The iPhone interface is constrained, though. You absolutely cannot do everything, no matter how much you want to. You must do just what your users need at that moment and nothing more.

Making your application responsive and flexible is more important than handling every situation. So, how can the tools that we have available help us create the right kind of application? It turns out that if you want to focus on the user experience and not on the database and if you want to think about the user workflow and not tables and columns and joins, then Core Data will be your friend.

Where Did Core Data Come From?

It turns out that Core Data did not just leap, fully grown, out of someone's head in Cupertino. Core Data is not even new with Mac OS X 10.4, where it first appeared within Apple. Core Data has a long, interesting history, and, really, you never know when you will need an extra acronym or two to put on your resume.

Core Data was first added to the iPhone SDK with version 3.0. Core Data appeared in Mac OS X in Tiger (Mac OS X 10.4), but it actually has a much longer history than that. It was first developed at NeXT Computer as the DBKit framework in 1992, which then became the Enterprise Object Framework (EOF) in 1994. EOF was used to develop flexible applications on NeXT's operating systems, NeXTStep and OpenStep. You could build these applications for NeXT systems, Windows NT or Solaris. Realizing that objects can be displayed via HTML as easily as via a custom application interface, the engineers at NeXT added WebObjects as a display layer for EOF.

EOF is an object-relational mapping (ORM) framework. It is well designed, is robust, encourages Model View Controller (MVC) design patterns, and was the conceptual forerunner of much later work in the industry. When I was at Apple, I heard that Sun attempted to purchase EOF and, when it could not, decided to create the JDBC library. And this may even be true. Additionally, Microsoft has been trying to create tools that match what is provided in WebObjects and EOF and has hired many of the software designers who worked at NeXT.

EOF and WebObjects were ported to Java in 1997 so that applications could run on any platform on which a Java VM was available. This got Apple out of the job of supporting, for example, an HP/UX version of the framework. It was very successful, it generated sales of Mac OS X Server machines, and there were active discussion groups among users of EOF and WebObjects that were more active than with almost any other Apple technology. Apple has never been comfortable with the enterprise market, though, and WebObjects has the stigma of being an 'enterprise technology.' WebObjects and EOF entered a long period of ... quiet. The online store still used it, so Apple depended on it for money but was not sure about how to market it to other businesses. Personally, I believe that Steve Jobs will be comfortable talking about 'the enterprise' when Pixar is making a Star Trek movie, and not one day before.

The Client Is King

Core Data is, in a way, the step backward that was needed to make a step forward. From when I was at Apple, I know the company has always been about making shiny, pretty applications. It wants the 'Wow!' in everything it does. It was never clear how EOF fit into that. It organizes your data for you? Really? That's nice. Yawn....

EOF had a history, with the EOF Application of the OpenStep days, as a client-access technology, so performance had been tuned for that usage. But it was ported to Java and then was used for very large applications at Apple and in companies such as Bell South and Deutsche Bank. The Apple Store still uses it, and the iTunes Store is a WebObjects application modified to push out XML instead of HTML. So, it was also tuned for long-running processes, large data sets, and a long mean time between failures (MTBF).

Tuning for both quick and agile client access and for long-running server processes is a contradiction. This contradiction was never been resolved in WebObjects/EOF. With Core Data, though, Apple ported EOF back to Objective-C. Objective-C is a very flexible dynamic language and runtime, and this helped bring back the old efficiencies. It was now clear where the goal of the performance tuning should be. Core Data is only about the client. Many Mac OS X applications do not track MTBF in their testing, for example, and it is even less of a concern on the iPhone.

Core Data provides very deep classes for very little effort. You do not need to think about tables but rather entities, which are just 'things.' You do not need to think about columns or joins but rather attributes and relationships. And these attributes and relationships are abstractly defined, in much the same way you see attributes defined in Eiffel. A join between two tables in a database has to follow some rules and be defined in a certain way, but a relationship in a Core Data entity may merely be a method that returns a collection of multiple...things. These things can be described in different ways. Key-Value Coding (KVC) and Key-Value Observing (KVO) are protocols for tracking or retrieving data from an object. As long as an object responds to the protocols, it can do almost anything it wants.

Apress is a technical publisher devoted to meeting the needs of IT professionals, software developers, and programmers, with more than 700 books in print and a continually expanding portfolio of publications. Apress provides high-quality, no-fluff content in print and electronic formats that help serious technology professionals build a comprehensive pathway to career success.

Add Comment      Leave a comment on this blog post

Post a comment





(Maximum characters: 1200). You have 1200 characters left.




Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.