Core Data Failed Banks Model Diagram
Of all of the ways to persist data on the iPhone, Core Data is the best one to use for non-trivial data storage. It can reduce the memory overhead of your app, increase responsiveness, and save you from writing a lot of boilerplate code.
However, the learning curve for Core Data can be quite large. That’s where this tutorial series comes in – the goal is to get you up to speed with the basics of Core Data quickly.
In this part of the series, we’re going to create a visual data model for our objects, run a quick and dirty test to make sure it works, and then hook it up to a table view so we can see a list of our objects.
In the second part of the series, we’re going to discuss how to import or preload existing data into Core Data so that we have some good default data when our app starts up.
In the final part of the series, we’re going to discuss how we can optimize our app by using NSFetchedResultsController, to reduce memory overhead and improve response time.
Before proceeding with this tutorial, I recommend checking out my tutorial series on SQLite for iPhone Developers first. On the iPhone, the backing store for Core Data is SQLite, so it helps to have an understanding of how that works first. Plus, the app we’re making is the same app we made in that tutorial – just with Core Data this time!
Creating a Core Data Project
So let’s get started! Create a new Window-based Application, and choose “Use Core Data for storage”, and name the project “FailedBanksCD.”
Before we begin, let’s take a quick look at the project. First expand Resources and double click on FailedBanksCD.xcdatamodel. You’ll see a visual editor will pop up – this is what we’ll be using in a minute to diagram our model objects. Go ahead and close it for now.
Then take a look at FailedBanksCDAppDelegate.m. You’ll see that there are several new functions in here that are implemented for us, to set up the Core Data “stack”. One creates a managed object context, one creates a managed object model, and one creates a persistent store coordinator. Huh??
Don’t worry. The names sound confusing at first, but once you get a “mental shortcut” for what they’re all about they are easy to understand.
- Managed Object Model: You can think of this as the database schema. It is a class that contains definitions for each of the objects (also called “Entities”) that you are storing in the database. Usually, you will use the visual editor you just peeked at to set up what objects are in the database, what their attributes, and how they relate to each other. However, you can do this with code too!
- Persistent Store Coordinator: You can think of this as the database connection. Here’s where you set up the actual names and locations of what databases will be used to store the objects, and any time a managed object context needs to save something it goes through this single coordinator.
- Managed Object Context: You can think of this as a “scratch pad” for objects that come from the database. It’s also the most important of the three for us, because we’ll be working with this the most. Basically, whenever you need to get objects, insert objects, or delete objects, you call methods on the managed object context (or at least most of the time!)
Don’t worry too much about these methods – you won’t have to mess with them much. However, it’s good to know that they are there and what they represent.
Defining Our Model
When we created our database tables in the SQLite tutorial, we had a single table containing all of the data for a failed bank. To reduce the amount of data in memory at once (for learning purposes), we just pulled out the subset of the fields we needed for display in our first table view.
So we might be tempted to set up our model the same way with Core Data. However, with Core data you cannot retrieve only certain attributes of an object – you have to retrieve the entire object. However, if we factor the objects into two pieces – the FailedBankInfo piece and the FailedBankDetails piece – we can accomplish the exact same thing.
So let’s see how this will work. Open up the visual model editor (expand Resources and double click FailedBanksCD.xcodedatamodel).
Let’s start by creating an object in our model – referred to as “Entity” in Core Data speak. In the top left pane, click the plus button to add a new Entity like the following:
Upon clicking the plus, it will create a new Entity, and show the properties for the Entity in the right panel like the following:
Name the Entity FailedBankInfo. Note that it currently lists the class as a subclass of NSManagedObject. This is the default class for Entities, which we’ll use for now – later we’ll come back and set up custom objects.
So let’s add some attributes. First, make sure that your Entity is selected by either clicking on the Entity name in the left panel, or the diagram for the entity in the diagram view. In the middle panel, click the plus button and then click “Add Attribute” like the following:
In the property pane on the right, name the attribute “name” and set the Type to “String” like the following:
Now, repeat this to add two more attributes, “city” and “state”, also both strings.
Next, we need to create an entity for FailedBankDetails. Create an Entity the same way you did before, and add the following attributes to it: zip of type Int 32, closeDate of type Date, and updatedDate of type Date.
Finally, we need to associate these two types. Select FailedBankInfo, and click the plus button in the middle pane, but this time select “Add relationship”:
Name the relationship “details”, and set the destination as “FailedBankDetails.”
Ok, so what did we just do here? We just set up a relationship in Core Data, which links up one entity to another entity. In this case, we are setting up a one-to-one relationship – every FailedBankInfo will have exactly 1 FailedBankDetails. Behind the scenes, Core Data will set up our database so that our FailedBankInfo table has a field for the ID of the corresponding FailedBankDetails object.
Apple recommends that whenever you create a link from one object to another, you create a link from the other object going back as well. So let’s do this.
Now add a relationship to “FailedBankDetails” named “info”, set the destination to “FailedBankInfo”, and set the inverse to “details”.
Also, set the delete rule for both relationships to “cascade”. This means that if you delete one object with Core Data, Core Data will delete the associated object as well. This makes sense in this case because a FailedBankDetails wouldn’t mean anything without a corresponding FailedBankInfo.
Testing our Model
Believe it or not, that was probably the most important thing we needed to do. Now it’s just a matter of testing out using Core Data and making sure it works!
First, let’s test out adding a test object to our database. Open FailedBanksCDAppDelegate.m and add the following to the top of applicationDidFinishLaunching:
NSManagedObjectContext *context = [self managedObjectContext]; NSManagedObject *failedBankInfo = [NSEntityDescription insertNewObjectForEntityForName:@"FailedBankInfo" inManagedObjectContext:context]; [failedBankInfo setValue:@"Test Bank" forKey:@"name"]; [failedBankInfo setValue:@"Testville" forKey:@"city"]; [failedBankInfo setValue:@"Testland" forKey:@"state"]; NSManagedObject *failedBankDetails = [NSEntityDescription insertNewObjectForEntityForName:@"FailedBankDetails" inManagedObjectContext:context]; [failedBankDetails setValue:[NSDate date] forKey:@"closeDate"]; [failedBankDetails setValue:[NSDate date] forKey:@"updatedDate"]; [failedBankDetails setValue:[NSNumber numberWithInt:12345] forKey:@"zip"]; [failedBankDetails setValue:failedBankInfo forKey:@"info"]; [failedBankInfo setValue:failedBankDetails forKey:@"details"]; NSError *error; if (![context save:&error]) { NSLog(@"Whoops, couldn't save: %@", [error localizedDescription]); } |
In the first line, we grab a pointer to our managed object context using the helper function that comes included with the template.
Then we create a new instance of an NSManagedObject for our FailedBankInfo entity, by calling insertNewObjectForEntityForName. Every object that Core Data stores derives from NSManagedObject. Once you have an instance of the object, you can call setValue for any attribute that you defined in the visual editor to set up the object.
So we go ahead adn set up a test bank, for both FailedBankInfo and FailedBankDetails. At this point the objects are just modified in meomry – to store them back to the database we need to call save on the managedObjectContext.
That’s all there is to it to insert objects – no SQL code necessary!
Before we try this out, let’s add some more code in there to list out all the objects currently in the database:
NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init]; NSEntityDescription *entity = [NSEntityDescription entityForName:@"FailedBankInfo" inManagedObjectContext:context]; [fetchRequest setEntity:entity]; NSArray *fetchedObjects = [context executeFetchRequest:fetchRequest error:&error]; for (NSManagedObject *info in fetchedObjects) { NSLog(@"Name: %@", [info valueForKey:@"name"]); NSManagedObject *details = [info valueForKey:@"details"]; NSLog(@"Zip: %@", [details valueForKey:@"zip"]); } [fetchRequest release]; |
Here we create a new object called a fetch request. You can think of a fetch request as a SELECT clause. We call entityForName to get a pointer to the FailedBankInfo entity we want to retrieve, and then use setEntity to tell our fetch request that’s the kind of Entity we want.
We then call executeFetchRequest on the managed object context to pull all of the objects in the FailedBankInfo table into our “scratch pad”. We then iterate through each NSManagedObject, and use valueForKey to pull out various pieces.
Note that even though we pulled out just the objects from the FailedBankInfo table, we can still access the associated FailedBankDetails object by acessing the details property on the FAiledBankInfo entity.
How does this work? Behind the scenes, when you access that property Core Data notices that it doesn’t have the data in the context, and “faults”, which basically means it runs over to the database and pulls in that data for you right as you need it. Pretty convenient!
Give this code a run and take a look in your output window, and you should see a test bank in your database for every time you run the program.
Seeing the Raw SQL Statements
I don’t know about you, but when I’m working on this kind of stuff I really like to see the actual SQL statements going on to understand how things are working (and make sure it’s doing what I expect!)
Once again Apple has provided an easy solution to this. Open the Executables drop-down in XCode and find your FailedBanksCD executable. Right click on that and click “Get Info.” Navigate to the Arguments tab and add the following argument: “-com.apple.CoreData.SQLDebug 1″. When you’re done it should look like the following:
Now when you run your code, in the debug output you should see useful trace statements like this showing you what’s going on:
SELECT Z_VERSION, Z_UUID, Z_PLIST FROM Z_METADATA
SELECT Z_MAX FROM Z_PRIMARYKEY WHERE Z_ENT = ?
UPDATE Z_PRIMARYKEY SET Z_MAX = ? WHERE Z_ENT = ? AND Z_MAX = ?
INSERT INTO ZFAILEDBANKDETAILS(Z_PK, Z_ENT, Z_OPT, ZINFO,
ZUPDATEDDATE, ZZIP, ZCLOSEDATE) VALUES(?, ?, ?, ?, ?, ?, ?)
INSERT INTO ZFAILEDBANKINFO(Z_PK, Z_ENT, Z_OPT, ZDETAILS, ZNAME,
ZSTATE, ZCITY) VALUES(?, ?, ?, ?, ?, ?, ?)
SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZNAME, t0.ZSTATE, t0.ZCITY, t0.ZDETAILS
FROM ZFAILEDBANKINFO t0
SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZUPDATEDDATE, t0.ZZIP, t0.ZCLOSEDATE,
t0.ZINFO FROM ZFAILEDBANKDETAILS t0 WHERE t0.Z_PK = ?
So here we see things are working as we expect. The first two selects and update are Core Data doing some bookkeeping work keeping track of what the next ID for the entity should be.
Then we have our inserts into the details and info tables. After that, we select the entire bank info table in our query. Then as we iterate through the results, each time we access the details variable, behind the scenes Core Data faults and issues another select statement to get the data from the ZFAILEDBANKDETAILS table.
Auto Generating Model Files
So far, we’ve been using NSManagedObject to work with our Entities. This isn’t the best way to do things, because it’s quite easy to make a mistake and type an attribute name incorrectly, or set data using the wrong type, etc.
The better way to do things is to create a Model file for each entity. You can do this by hand, but XCode makes this quite easy with a class generator.
Let’s try it out. Open up FailedBanksCD.xcdatamodel, click on the FailedBankInfo entity, and go to File\New File. Select “Cocoa Touch Class”, and you should see a new template for “Managed Object Class.” Select this and click Next, and then click Next again on the following view.
In the third view, XCode will allow you to select the Entities to generate classes for. To save time, make sure BOTH FailedBankInfo and FailedBankDetails are checked, and click Finish.
You should see some new files added to your project: FailedBankInfo.h/m and FailedBankDetails.h/m. These classes are very simple, and just declare properties based on the attributes you added to the entities. You will notice that the properties are declared as dynamic inside the .m files – this is because Core Data handles wiring the properties up automatically.
I did notice one problem with the autogenerated classes that I had to fix. If you look at FailedBankDetails.h, you’ll notice that the info variable is correctly declared as a FailedBankInfo class, but in FailedBankInfo.h the details variable is defined as an NSManagedObject (but it should be a FailedBankDetails object). You can fix this by adding a predeclaration of FailedBankDetails to the top of the file:
@class FailedBankDetails; |
And then changing the details property declaration to the following:
@property (nonatomic, retain) FailedBankDetails * details; |
Also, take a peek back in FailedBanksCD.xcdatamodel. When you look at the properties for the entities, you’ll notice that the classes have now been set automatically to the names of the autogenerated classes:
Now, let’s tweak our test code in the app delegate to use our new subclasses of NSManagedObject. First add the headers we’ll need up top:
#import "FailedBankInfo.h" #import "FailedBankDetails.h" |
Then change the code as follows:
NSManagedObjectContext *context = [self managedObjectContext]; FailedBankInfo *failedBankInfo = [NSEntityDescription insertNewObjectForEntityForName:@"FailedBankInfo" inManagedObjectContext:context]; failedBankInfo.name = @"Test Bank"; failedBankInfo.city = @"Testville"; failedBankInfo.state = @"Testland"; FailedBankDetails *failedBankDetails = [NSEntityDescription insertNewObjectForEntityForName:@"FailedBankDetails" inManagedObjectContext:context]; failedBankDetails.closeDate = [NSDate date]; failedBankDetails.updatedDate = [NSDate date]; failedBankDetails.zip = [NSNumber numberWithInt:12345]; failedBankDetails.info = failedBankInfo; failedBankInfo.details = failedBankDetails; NSError *error; if (![context save:&error]) { NSLog(@"Whoops, couldn't save: %@", [error localizedDescription]); } // Test listing all FailedBankInfos from the store NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init]; NSEntityDescription *entity = [NSEntityDescription entityForName:@"FailedBankInfo" inManagedObjectContext:context]; [fetchRequest setEntity:entity]; NSArray *fetchedObjects = [context executeFetchRequest:fetchRequest error:&error]; for (FailedBankInfo *info in fetchedObjects) { NSLog(@"Name: %@", info.name); FailedBankDetails *details = info.details; NSLog(@"Zip: %@", details.zip); } [fetchRequest release]; |
This is pretty much the same code we had before, except instead of using NSManagedObject directly, we use our new subclasses. Now we have type safety and cleaner code!
Creating a Table View
Right click on Classes and click “Add\New File…” and pick “UIViewController subclass”, making sure “UITableVIewController subclass” is checked and “With XIB for user interface” is NOT checked. Name the class FailedBanksListViewController.
Open up FailedBanksListViewController.h and add a two member variables:
- A member variable/property for the failedBankInfos which we’ll retrieve from the database, just like we used last time.
- A member variable for the managed object context to use. Note we could retrieve this from the application delegate, but it’s better practice to have it passed in as a member variable to avoid interdependence.
So when you’re done it should look like the following:
#import <UIKit/UIKit.h> @interface FailedBanksListViewController : UITableViewController { NSArray *_failedBankInfos; NSManagedObjectContext *_context; } @property (nonatomic, retain) NSArray *failedBankInfos; @property (nonatomic, retain) NSManagedObjectContext *context; @end |
Switch over to FailedBanksListViewController.m and add some imports, your synthesize statement, and your cleanup code:
// At very top, in import section #import "FailedBankInfo.h" // At top, under @implementation @synthesize failedBankInfos = _failedBankInfos; @synthesize context = _context; // In dealloc self.failedBankInfos = nil; self.context = nil; |
Then uncomment viewDidLoad and modify it to look like the following:
- (void)viewDidLoad { [super viewDidLoad]; NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init]; NSEntityDescription *entity = [NSEntityDescription entityForName:@"FailedBankInfo" inManagedObjectContext:_context]; [fetchRequest setEntity:entity]; NSError *error; self.failedBankInfos = [_context executeFetchRequest:fetchRequest error:&error]; self.title = @"Failed Banks"; [fetchRequest release]; } |
This code should look pretty familiar to our test code from earlier. We simply create a fetch request to get all of the FailedBankInfos in the database, and store it in our member variable.
The rest of the mods are exactly like we did in the SQLite tutorial. For quick reference, I’ll list the remaining steps here again:
Return 1 for numberOfSectionsInTableView:
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView { return 1; } |
Replace numberOfRowsInSection with the following:
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section { return [_failedBankInfos count]; } |
Modify cellForRowAtIndexPath to look like the following:
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { static NSString *CellIdentifier = @"Cell"; UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier]; if (cell == nil) { cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleSubtitle reuseIdentifier:CellIdentifier] autorelease]; } // Set up the cell... FailedBankInfo *info = [_failedBankInfos objectAtIndex:indexPath.row]; cell.textLabel.text = info.name; cell.detailTextLabel.text = [NSString stringWithFormat:@"%@, %@", info.city, info.state]; return cell; } |
Add an outlet into FailedBanksCDAppDelegate.h for the UINavigationController we’re about to add:
@interface FailedBanksCDAppDelegate : NSObject <UIApplicationDelegate> { NSManagedObjectModel *managedObjectModel; NSManagedObjectContext *managedObjectContext; NSPersistentStoreCoordinator *persistentStoreCoordinator; UIWindow *window; UINavigationController *_navController; } @property (nonatomic, retain, readonly) NSManagedObjectModel *managedObjectModel; @property (nonatomic, retain, readonly) NSManagedObjectContext *managedObjectContext; @property (nonatomic, retain, readonly) NSPersistentStoreCoordinator *persistentStoreCoordinator; @property (nonatomic, retain) IBOutlet UIWindow *window; @property (nonatomic, retain) IBOutlet UINavigationController *navController; - (NSString *)applicationDocumentsDirectory; @end |
Open up Resources and double click on MainWindow.xib. Drag a Navigation Controller from the library into the MainWindow.xib. Click on the down arrow on the Navigation Controller that you just added, click on the View Controller, over in the attribute panel switch to the fourth tab, and switch the “Class” to “FailedBanksListViewController.”
Finally, control-drag from “FailedBanksCD App Delegate” in MainWindow.xib to “Navigation Controller”, and connect it to the “navController” outlet. Save the xib and close.
Now all we need to do is add a few lines to our FailedBanksCDAppDelegate.m:
// At top #import "FailedBanksListViewController.h" // Under @implementation @synthesize navController = _navController; // In applicationDisFinishLaunching, before makeKeyAndVisible: FailedBanksListViewController *root = (FailedBanksListViewController *) [_navController topViewController]; root.context = [self managedObjectContext]; [window addSubview:_navController.view]; // In dealloc self.navController = nil; |
Compile and run the project, and if all looks well you should see the sample banks we added earlier!
Where to Go From Here?
Here’s the sample code for the project so far.
So far so good – except we’re missing the actual data from the failed banks. So next in the tutorial series we’ll cover how to preload/import existing data!
Category: iPhone
Ray, thanks for a very helpful tutorial!
I do have a problem, though – I got to the end and when I ran the program, I couldn’t see the TableView at all – just a blank screen.
Any ideas?
@Markk – Hm, that is odd! I just ran through the tutorial from scratch to make sure I wasn’t missing any steps, and the table view showed up for me.
Two things to try: first I just uploaded the sample code to the project – take a look and see if there are any differences between your project and that.
Second, based on what you’re describing I suspect it’s probably to do with the way the navigation controller and table view controller are hooked together. Double check that the navigation controller you added to the MainWindow.xib is hooked into the outlet on the app delegate, and that the root view controller in the navigation controller is set to FailedBanksListViewController.h.
If you have any further problems, drop me an email :]
Hi Ray,
I found a few changes to make in your sample code, but the main thing I needed to add was a connection between File’s Owner and the app delegate. After that it worked fine!
Thanks again for an excellent tutorial.
Thanks for a really clear and well paced tutorial. I have done some Core Data work but never really understood why it worked. I even have hand crafted SQLite data correctly and transplanted into my app as prefilled and now with your help I can start to understand how to make it all work.
I have an application to write that needs data relationships coupled with drill down table views to 4 levels. The data is related by integer ID’s similar to INNER JOIN SQL statements.
Using SQL would be a cinch. But attempting through the ORM esque nature of Core Data is certainly challenging.
Have you got any plans to cover how to achieve similar query filtering and displaying in Core Data?
Thanks again. Really good tutorial.
@GS: Cool, thanks! Yeah I agree, I really like to understand how a technology like this works rather than treating it like “magic”, helps me understand it much better.
I hadn’t really thought about future Core Data tutorials that much yet, but that one definitely sounds like a good idea! I added it to my potential idea list.
Very good tutorial, just learned Core Data this week but wish I would have found this tutorial first. Not an extremely easy concept to grasp and Apple’s own documentation is almost useless unless you already understand how it works.
Great tutorial. I opened up the Apple Core Data docs a few weeks ago and thought, “I know this has got to be easy, but I can’t see how at this moment.”
You’re tutorial definitely proved my thoughts were right. I just needed the right teacher.
My donation should be in your PayPal account. I hope the others who enjoy this tutorial also back up their opinion with a donation.
@Tom: Thank you so much! I really appreciate it. Also, I just checked out your blog and I love it! Added to my RSS reader :]
Thanks again!
Good example, Thanks.
I really would like to see you extend the tutorial to add new data by input and save it.
Just ran into a problem while playing around with this. How do you actually access the FailedBankDetails ?
I added a DetailViewController to display all infos and I can get all FailedBankInfo, but as soon as I try to access the details, i get a EXC_BAD_ACCESS.
FailedBankDetails *details_ = bankinfo.details;
Thanks
@Sebastian: Hmm, I’m not quite sure. I updated the sample project to include an example of accessing the bank details (check out didSelectRowAtIndexPath and you’ll see an NSLog statement), and I didn’t get an exception.
Check it out and let me know if you’re still having any issues!
Thanks for looking into it. I actually found my MISTAKE and it had nothing todo with how I access the details at all.
Stupid me released the details, so it had to run into an Exception.
There is still one question remaining, how do I migrate to a new structure by adding a new attribute or another Entity when I update the app ?
Doing it and updating the Managed Object Class does not seem to be enough.
@Sebastian: You can do this in Core Data with migrations (lightweight migrations and standard migrations). You can read up on these in the Core Data guides.
Excellent tutorial, Ray. Regarding migration and version, there is a good tutorial on migrating and versioning from Tim Isted. You can find it here:
http://www.timisted.net/blog/archive/core-data-migration/. One gotcha to remember is to ‘Build->Clean All Targets’ after creating a new model version to clean out the old model. This will eliminate errors when two models exist.
@Alan: Cool Alan, thanks for the tip on the migration tutorial, that looks great!
Thanks so much for tutorials! I went through the Apple tutorial and it just didn’t do it for me. Yours are great! (BTW, there’s a tiny typo near the beginning where you have “DeleteMe” in a couple of places, which were meant to be “FailedBanksCD.”)
@James: Oops, nice catch! Post updated with that fix.
Hi Ray-
I have to add my voice to this being a really wonderful tutorial. The way you build from the simplest possible things that work is very helpful, and I’ve learned a lot about developing iOS apps in addition to Core Data.
I went through and built the project for 3.2 and the iPad, and all went well. Some small niggles I discovered:
1) You need to return 1 in numberOfSectionsInTableView.
2) You have to init UITableViewCell with UITableViewCellStyleSubtitle to get what’s shown in your last screenshot.
3) You probably should refer to “FailedBanksCDAppDelegate.m” in the line toward the end: “Now all we need to do is add a few lines to our FailedBanksAppDelegate.m”
But these are all on the level of typos.
Thanks agin, and keep ‘em coming!
Best wishes, Charles
Hi Ray,
It looks great! I got it working and it looks like a worthwile alternative for SQL. The only problem is I get a warning I am not comfortable with after having defined my second object: linking the second object to the first works fine. But when I link the first to the second, I get the warning ‘ìncompatible objective-C types ‘struct Struct2*’, expected ‘structNSSet*’ when passing argument 1 of ‘setStruct2:’ from distinctive Objective-C type’.
I am not sure what to do with this warning.
Please let me know your thoughts on this.
@Charles: Awesome, thanks for pointing out those typos! I have updated the tutorial with the fixes.
@JJEnden: Hm without seeing the code I’m not sure what’s going on, but from the compiler warning it sounds like something is expecting to see a NSSet pointer, but instead has a Struct2 pointer instead.
Ray, thank you. Unquestionably the best CoreData tutorial around, particularly because I finally understand how to handle multiple entities with relationships.
I reached the point where you run it for the first time (just before ‘Seeing the Raw SQL Statements’). It crashes with the following error:
Terminating app due to uncaught exception ‘NSUnknownKeyException’, reason: ‘[ setValue:forUndefinedKey:]: the entity FailedBankDetails is not key value coding-compliant for the key “updatedDate”.’ I have no idea how to fix it. Please help. Thanks!
@neil: Thanks for the kind words!
@Alex: Hm, I haven’t had that error myself, but here’s a guide that might help you track down the cause:
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaBindings/Concepts/Troubleshooting.html
Hi Ray,
thanks for the tutorial, it’s invaluable.
However, I’ve got the question: how did you find out about the “-com.apple.CoreData.SQLDebug 1″ argument? I’m willing to wager that source has a LOT of other information I’d be interested in :D
@Kheidar: If I recall, I got it from the Core Data Performance section of the Core Data Programming Guide:
http://developer.apple.com/iphone/library/documentation/cocoa/conceptual/CoreData/Articles/cdPerformance.html
People seem to be missing the tutorial that’s part of Apple’s documentation at http://developer.apple.com/iphone/library/documentation/DataManagement/Conceptual/iPhoneCoreData01/Articles/01_StartingOut.html#//apple_ref/doc/uid/TP40008305-CH105-SW1
@mmaic: Yeah that’s a great tutorial, thanks for pointing it out. Another one I really liked was the following, which is great for understanding how things fit together:
Core Data Command Line Utility Tutorial
Very good and clear tutorial.
One question, I already developed an iPhone app, and I am now in need of writing some way of persisting and retrieving objects. Do you think it’s possible to add Core Data on such existing project, and convert already developed classes in Entity ?
thanks
@Leonardo : Here is a good tutorial I found on adding CoreData to an existing project
http://wiresareobsolete.com/wordpress/2009/12/adding-core-data-existing-iphone-projects/
hi , and thank you for your helpful tutorial , i do my project as you explain in this article but i have this problem:
*** Terminating app due to uncaught exception ‘NSInternalInconsistencyException’, reason: ‘+entityForName: could not locate an NSManagedObjectModel for entity name ‘phoneBook”
*** Call stack at first throw:
thank you
@Adam: Thanks for helping out Leonardo!
@Ali: Looks like you might not have set up the phoneBook entity? Check capitalization too.
Thanks for the tutorial. I was stuck with some problems and your walk-through helped me a lot.
Saludos
Hi Ray, first thank u for your useful tutorial very helpfull but i had a following errors while executing the project hope that u sorted out
Thanks
srikanth
/Users//Desktop/srikanth/FailedBanksCD/FailedBanksCD.xcdatamodel:0:0 FailedBanksCDAppDelegate.navController — attribute must have a defined type
/Users/Desktop/srikanth/FailedBanksCD/FailedBanksCD.xcdatamodel:0:0 FailedBanksCDAppDelegate.persistentStoreCoordinator — attribute must have a defined type
/Users//Desktop/srikanth/FailedBanksCD/FailedBanksCD.xcdatamodel:0:0 FailedBanksCDAppDelegate.managedObjectModel — attribute must have a defined type
/Users//Desktop/srikanth/FailedBanksCD/FailedBanksCD.xcdatamodel:0:0 FailedBanksCDAppDelegate.window — attribute must have a defined type
/Users//Desktop/srikanth/FailedBanksCD/FailedBanksCD.xcdatamodel:0:0 FailedBanksCDAppDelegate.managedObjectContext — attribute must have a defined type
/Users//Desktop/srikanth/FailedBanksCD/FailedBanksCD.xcdatamodel:0:0 FailedBanksListViewController.context — attribute must have a defined type
/Users/krithik/Desktop/srikanth/FailedBanksCD/FailedBanksCD.xcdatamodel:0:0 FailedBanksListViewController.failedBankInfos — attribute must have a defined type
@srikanth: I just downloaded the sample project and tried it out, and didn’t get any errors like that. Try comparing your project to the sample project and see if there is any differences.
Hi Ray,
I am implementing one application with core data.I get error : Terminating app due to uncaught exception ‘NSInternalInconsistencyException’, reason: ‘Invalid update: invalid number of rows in section 0. The number of rows contained in an existing section after the update (2) must be equal to the number of rows contained in that section before the update (2), plus or minus the number of rows inserted or deleted from that section (2 inserted, 0 deleted).’
Please help me.
@apoorv: I’ve seen that error before when my data model did not match the table view’s data model. Make sure that if you’re deleting anything from your model that you also remember to call [tableView delete/insertRowsAtIndexPaths:...] etc.
As others in the comments have stated, great tutorial! I’ve been running through the tutorials on Apple and in Dudney and Adamson’s “iPhone SDK Development” on CoreData and I’ve been able to get the tutorials to work, but it all seemed rather mystical and I was never successful in applying the concepts to my own project. Your tutorial gave me a bare-bones understanding of CoreData I was missing from the other tutorials. I especially liked simply using the console to checked that it worked. (I’m pretty new to objective-C and working with Apple’s SDKs and not a heavy coder besides, so the console idea was a new one for me.)
Couple questions I have just related to coding practices (if you don’t mind answering):
a) What’s the difference between doing memory cleanup with say “property = nil” versus something like a “[property release]” statement I generally see in Apple’s example dealloc methods.
b) When do I use “_property” instead of “self.property?”
In case anyone else ran into the same question, here’s a pretty thorough discussion of my question “a” above referring to the use of self.property=nil vs. [property release] in -dealloc (oh, and from other sources I’ve found that property=nil is a big no-no):
http://www.iphonedevbook.com/forum/viewtopic.php?f=25&t=3009
@Robert: Thanks for the kind words! Yeah I know the feeling, the way I like to learn is go to from the bare-bones on-up so I completely understand what’s going on…
Great read in that post, by the way, thanks for sharing! I didn’t realize that you shouldn’t call self.property = nil in dealloc due to the object already being dealloced – good to know. Weird I’ve never seen any problems with it though. I don’t know why it would be a problem to use self.property = nil in other places, though, since it’s basically equivalent to [_property release], _property = nil.
@Ray: Yeah, the gist I got from the forum discussion above was exactly as you say: self.property = nil is good every where else, but I guess what they were getting as is that on rare occasions one could run into problems calling self.property = nil in -dealloc simply because that infers the call [self property:nil] and, as they say, it’s generally bad form to call methods on an object once that object’s gotten a -dealloc call.
Thank you! you save me