Marcus S. Zarra - Core Data: Data Storage and Management for iOS, OS X, and iCloud

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and The Pragmatic Programmers, LLC was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals. The Pragmatic Starter Kit, The Pragmatic Programmer, Pragmatic Programming, Pragmatic Bookshelf and the linking g device are trademarks of The Pragmatic Programmers, LLC.

Every precaution was taken in the preparation of this book. However, the publisher assumes no responsibility for errors or omissions, or for damages that may result from the use of information (including program listings) contained herein.

Our Pragmatic courses, workshops, and other products can help you and your team create better software and have more fun. For more information, as well as the latest Pragmatic titles, please visit us at http://pragprog.com.

It is truly amazing how much has changed since the last time I sat down to write an introductory chapter for Core Data . The last time, in 2009, the iPhone had just been released, and Core Data was not available for it yet; in fact, the SDK had been released only that year. Of course, by the time we were finished with the production of the book, we did have Core Data on the iPhone, but it was in its infancy.

When I began putting together this second edition of the book, Core Data had just received a major update to its API, the first major update to its core API since its initial release for Mac OS X 10.4 Tiger. Now, that update has been out for more than a year, and we are settling into those changes and how they impact our development of applications.

If you plan on writing an application that saves data to disk, then you should take a very long look at Core Data. Whether you are focusing on the desktop or the iPhone, Core Data is the most efficient solution to data persistence.

A good way to confirm that you know enough Cocoa to benefit from this book is to take a look at Appendix 1, . You should find it dense, but every step should be familiar to you.

In the simplest terms, Core Data is an object graph that can be persisted to disk. But just like describing a man as a bag of mostly water, that description hardly does Core Data justice. If you have worked with Interface Builder (specifically on OS X), you know that it effectively removes a third of the coding from the Model View Controller (MVC) design pattern. With Interface Builder, developers do not need to spend countless hours writing and rewriting their user interface to make sure that it is pixel perfect. Instead, they simply drag and drop the elements in the IDE, bind them together, and call it done.

Of course, the problem with Interface Builder is that we still need to code the other two parts! Both the controller and the model need to be developed in code and made to work with the interface we just designed. That is where Core Data comes in. In a nutshell, Core Data deals with a third of that MVC design: Core Data is the model.

It is a common misconception that Core Data is a database API for Cocoa that allows a Cocoa application to store its data in a database. Although that description is factually accurate, Core Data does a lot more. It serves as the entire model layer. It is not just the persistence on disk; it is also all the objects in memory that we normally consider to be data objects. If you have experience working with Java, C#, or some other object-oriented language, the data objects take a lot of time to write, and they are generally very repetitive in nature. Core Data eliminates most, if not all, of that boilerplate code for us and lets us focus on the business logic, or the controller layer, of our application. It does this with an interface that is as easy to use as Interface Builder.

In addition to ease of use, Core Data is also highly flexible. If we need to step in and change the functionality of some portion of the data model, we can. From how a value is handled when it is being accessed to how data is migrated from one persistent store to another, we can choose how little or how much we want to code ourselves and how much we want Core Data to do for us.

When you start to learn Core Data, it is best to think in terms of objects. Core Data is a framework designed to manage your data and data object graph. As a secondary function, it will persist that data to disk. However, its primary function is to manage the objects.

If you have started to flip through this book, you probably noticed that I refer to iOS 6.0 and OS X 10.8 frequently, and I rarely mention iOS 5.0 or OS X 10.7, although the API changes that impacted Core Data the most were introduced in iOS 5.0 and OS X 10.7. There is a reason for this. There are significant, unavoidable issues with these new APIs in their first release. These issues are so significant that I cannot recommend using the new APIs in their first release.

It took me a long time to come to this conclusion, and even now I truly wish I had a better answer. I kept hoping that a new point release would come out for iOS 5 that would address some of these issues; unfortunately, it never did. Now that iOS 6.0 has been released to the public, I do not believe we will ever see another release for 5.0.