Where Does Core Data on the Apple iPhone Come From?

Dave Mark and Jeff LaMarche

(The following is an excerpt from More iPhone 3 Development: Tackling iPhone SDK 3, published by APress.)

Core Data is a framework and set of tools that allow you to persist your application's data to the iPhone's file system automatically. Core Data is a form of something called object-relational mapping, or ORM, which is just a fancy way of saying that Core Data takes the data stored in your Objective-C objects and translates (or maps) that data into another form so that it can be easily stored in a database, such as SQLite, or into a flat file.

Core Data can seem like magic when you first start using it. Objects are simply dealt with as objects, and they seem to know how to save themselves into the database or file system. You won't create SQL strings or make file management calls-ever. Core Data insulates you from some complex and difficult programming tasks, which is great for you. By using Core Data, you can develop applications with complex data models much, much faster than you could using straight SQLite, object archiving, or flat files.

Technologies that hide complexity the way Core Data does can encourage 'voodoo programming'-that most dangerous of programming practices where you include code in your application that you don't necessarily understand. Sometimes, that mystery code arrives in the form of a project template. Or, perhaps, you downloaded a utilities library that did a task for you that you just don't have the time or expertise to do for yourself.

That voodoo code does what you need it to do, and you don't have the time or inclination to step through it and figure it out, so it just sits there, working its magic until it breaks. Though this is not always the case, as a general rule, if you find yourself with code in your own application that you don't fully understand, it's a sign you should go do a little research, or at least find a more experienced peer to help you get a handle
on your mystery code.

The point is that Core Data is one of those complex technologies that can easily turn into a source of mystery code that will make its way into many of your projects. Although you don't need to know exactly how Core Data accomplishes everything it does, you should invest some time and effort into understanding the overall Core Data architecture.

A Brief History of Core Data

Core Data has been around for quite some time, but it just became available on the iPhone with the release of iPhone SDK 3.0. Core Data was originally introduced with Mac OS X 10.4 (Tiger), but some of the DNA in Core Data actually goes back about 15 years, to a NeXT framework called Enterprise Objects Framework (EOF), part of NeXT's WebObjects web development tool set.

EOF was designed to work with remote databases, and it was a pretty revolutionary tool when it first came out. Although there are now many good ORM tools for almost every language, when WebObjects was in its infancy, most web applications were written to use handcrafted SQL or file system calls to persist their data. Back then, writing web applications was incredibly time- and labor-intensive. WebObjects, in part because of EOF, cut the development time needed to create complex web applications by an order
of magnitude.

In addition to being part of WebObjects, EOF was also used by NeXTSTEP, which was the predecessor to Cocoa. When Apple bought NeXT, the Apple developers used many of the concepts from EOF to develop a new persistence tool called Core Data. Core Data does for desktop applications what EOF had previously done for web applications: It dramatically increases developer productivity by removing the need to write file
system code or interact with an embedded database.

Add Comment      Leave a comment on this blog post
Jan 7, 2010 4:01 PM Jay Godse Jay Godse  says:
I have seen many ORMs for many years. If you have never seen a SQL database or designed an application around one, you'll know that ORMs make you feel good because data "objects" look and feel like common programming objects. However, SQL is a very powerful language for data manipulation, and most ORMs do not easily support all powerful SQL concepts such as join tables, joins with "ON" clauses, database triggers, views, nested queries etc. In many cases, you have to jump down to SQL to use these features, or you have to write dozens of lines of code in your imperative programming language (e.g. Objective C, Python, Ruby, C, C#, Java) to do what a 2 line SQL query could have done. ActiveRecord is an amusing ORM. With each iteration over the last few years, it has included more and more constructs in its API that make ActiveRecord look more and more like SQL. (I can't wait until Rails 3 comes out with the relational algebra features in ActiveRecord). Over time, ActiveRecord is just starting to look like Ruby-flavoured syntactic sugar over SQL. (Which is just fine by me). Of course, that makes me wonder why we need the ORM in the first place. Jump into SQLite and learn it. Then when you find your ORM inadequate, you will know how to jump down and really make it work. Check out my page at http://www.squidoo.com/sqlitetutorial to get started. Reply
Jan 10, 2011 8:01 AM John Son John Son  says:
The article is really awesome, and I got lots of valuable information from the article, it�s really very helpful for the visitors. Reply
Jan 10, 2011 8:01 AM isabel de los rios isabel de los rios  says:
It is great that Apple shipped the core data framework with iPhone OS 3.0 but a lot of the performance and debugging tools are still missing from Xcode and Instruments. This makes trying to fine tune a slow running core data operation extra difficult on the iPhone OS Reply

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.