The persistent store, which is sometimes referred to as a backing store, is where Core Data stores its data. By default on the iPhone, Core Data will use a SQLite database contained in your application’s documents folder as its persistent store. But this can be changed without impacting any of the other code you write by tweaking a single line of code. We’ll show you the actual line of code to change in a few moments.

Every persistent store is associated with a single data model, which defines the types of data that the persistent store can store. If you expand the Resources folder in the Groups & Files pane in Xcode, you’ll see a file called CoreData.xcdatamodel. That file is the default data model for your project. The project template we chose gave us a single persistent store and an associated data model. Single-click CoreData.xcdatamodel now to bring up Xcode’s data model editor. As you design your own applications, this is where you’ll build your application’s data model.

Take a look at the data model editor. Notice the single rounded rectangle in the middle of the editing window. That rectangle is known as an entity. In effect, an entity is like a class definition, wrapping your various data elements under a single umbrella. This particular entity has the name Event, and it features sections for Attributes and Relationships. There’s a single attribute, named timeStamp, and no relationships.

Click off the entity rectangle. The title bar should turn a light pink. Click back on the entity, and it will turn blue, indicating the entity is selected.

The entity was created as part of this template. If you use this template to create your own Core Data application, you get the Event entity for free. As you design your own data models, you’ll most likely delete the Event entity and create your own entities from scratch.

A moment ago, you ran your Core Data sample application in the simulator. When you pressed the plus icon, a new instance of an Event was created. Entities, which we’ll look at more closely in a few pages, replace the Objective-C data model class you would otherwise use to hold your data.

Do not change the type of persistent store once you have posted your application to the App Store. If you must change it for any reason, you will need to write code to migrate data from the old persistent store to the new one, or else your users will lose all of their data— something that will likely make them quite unhappy.

Source of Information : Apress More iPhone 3 Development Tackling iPhone SDK 3

• 0 comments »

Like most complex technologies, Core Data has its own terminology that can be a bit intimidating to newcomers. Let’s break down the mystery and get our arms around Core Data’s nomenclature.

A high-level view of the Core Data architectures

There are five key concepts to focus on here.
• Persistent store
• Data model
• Persistent store coordinator
• Managed object and managed object context
• Fetch request


Source of Information : Apress More iPhone 3 Development Tackling iPhone SDK 3

• 0 comments »

Core Data is Apple’s framework for persisting data to the file system. Using Core Data, you deal with your program’s data as objects, and let the framework deal with the gnarly specifics of how to save, find, and retrieve those objects.

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.

Source of Information : Apress More iPhone 3 Development Tackling iPhone SDK 3

• 0 comments »