Can't set member variable twice (NSManagedObject) - iphone

I am getting the EXC_BAD_ACCESS error when trying to set a value inside a subclass of NSManagedObject for the second time.
I am using zombies but nothing is showing up in the console. Printing out the object using GDB I see that the object has the same memory address both times I try to set the value - not sure why though.
Situation:
I have a view (A) that, when a QR code is scanned, adds a subview (B) which in turn downloads XML that is then saved into a subclassed NSManagedObject.
Inside the subview (B) I navigate back (removeFromSuperView is called)
Back in the original view (A)
Next time, when the same QR code is scanned, it (A) finds the NSManagedObject from the database and attaches that to an instance variable on a new view (same type as B) that it then adds as a subview to the original (A).
In view B's viewDidLoad i always try to set the current date in order to track when a user "saw" that object. This is where I get the EXC_BAD_ACCESS error:
self.currentPiece.piece_last_viewed = [[NSNumber alloc] initWithDouble:[[NSDate date] timeIntervalSince1970]];
Where self.currentPiece is the instance of a subclassed NSManagedObject that was attached in A when that object existed in the database.
I know that it is being released somewhere but I don't know where since managed objects take care of much of that on their own. The error only occurs the second time around that I try to set the value.
I have tried to make this clear. Please tell me if you want me to clarify it even more.
Thanks for the help (have worked on this for some hours now)
UPDATE:
Declaring the piece_last_viewed in HubPiece.h:
#interface HubPiece : NSManagedObject {
}
// ...
#property (nonatomic, retain) NSNumber *piece_last_viewed;
HubPiece.m:
#dynamic piece_last_viewed;
//...inside init method:
self.piece_last_viewed = [[NSNumber alloc] initWithDouble:[[NSDate date] timeIntervalSince1970]];
UPDATE 2:
It is not due to the switching of subviews, that is ruled out. I then realized that I didn't save my changes either, so I introduced save: inside the subclassed NSManagedObject. I then got an earlier error the first time I try to save the entity instance (which saved during an app session, but the data vanishes if I quit the app entirely and then open it up again). So I thought using [context save:&error] would be a good idea :) ...but now that doesn't work and give me a EXC_BAD_ACCESS error.
The HubPiece itself is initialized from another class HubPieceView.m :
self.currentPiece = [[HubPiece alloc] initWithXML:pieceXML];
self.currentPiece is a class variable of type HubPiece and it first declared in .h file and then synthesized in .m file.
Then inside HubPiece.m the initializer looks like this:
-(id)initWithXML:(TBXMLElement *)pieceXML
{
// Setup the environment for dealing with Core Data and managed objects
HenryHubAppDelegate *appDelegate = [[UIApplication sharedApplication] delegate];
NSManagedObjectContext *context = [appDelegate managedObjectContext];
NSEntityDescription *entityHubPiece = [NSEntityDescription entityForName:#"HubPiece"
inManagedObjectContext:context];
// STORING values
self = [[HubPiece alloc] initWithEntity:entityHubPiece insertIntoManagedObjectContext:context];
// ...setting variables with normal assignment: self.var = value;
NSError *error;
// Save fails
if (![context save:&error] ){
NSLog(#" ERROR: %#", [error localizedDescription]);
}
return self;
}

I just realized my problem. I had been assigning values to the entity through with normal '=' assignment:
self.currentPiece.piece_last_viewed = [[NSNumber alloc] initWithDouble:[[NSDate date] timeIntervalSince1970]];
When it should have been done:
[self setCurrentPiece.piece_last_viewed:[[NSNumber alloc] initWithDouble:[[NSDate date] timeIntervalSince1970]] ];
This is because it is a managed object which creates it's own accessors at runtime through the #dynamic compiler instruction.

Related

Core Data Persistent Store Coordinator NSURL error

I've been working on an app that takes user ratings about mood. I am using Core Data to store this data. Initially, I am trying to store ratings and strings of "accomplishments". I've set up an entity in Core Data called "Day" with attributes date (of type Date), dailyRating (of type Int16), dailyAccomp (of type String), and dailyAccompRating (of type Int16). My app crashes within my app delegate's Core Data persistentStoreCoordinator method at the following stmnt:
NSURL *storeURL = [[self applicationDocumentsDirectory] URLByAppendingPathComponent:#"SelfEsteemBldr.sqlite"];
The error that I'm given is
[NSPathStore2 URLByAppendingPathComponent:]: unrecognized selector sent to instance 0x4d6f440.
Maybe a little background about how the error comes about might be helpful.
My Main window has a tab bar controller as the rootViewController. Within the tab for the CD model (LogViewController), I've set up a tableView Controller within a navigation controller. The nav bar has an add button, that pushes a new view that basically has textfields so the user can enter the relevant data. Within that view, there is a nav bar with a Done button. When the user is done, the Done button changes to a Save button. When I tap the Save button, the app crashes. The Save button is a UIButtonItem within ViewDidLoad. Here's the code for the save button:
UIBarButtonItem *newSaveButton =
[[UIBarButtonItem alloc]
initWithTitle:NSLocalizedString(#"Save", nil)
style:UIBarButtonItemStylePlain
target:self
action:#selector(performAddNewDay:)];
self.saveButton = newSaveButton;
[newSaveButton release];
The performAddNewDay method within the UIButtonItem looks like this:
- (void) performAddNewDay:(id)paramSender{
SelfEsteemBldrAppDelegate *delegate = (SelfEsteemBldrAppDelegate *)
[[UIApplication sharedApplication] delegate];
NSManagedObjectContext *context = delegate.managedObjectContext;
NSLog(#"Past init point in PerformAddNewDay");
// Get the values from the text fields
NSInteger dailyRatingAsInteger = [self.textFieldDailyRating.text integerValue];
NSNumber *ddailyRating = [NSNumber numberWithInteger:dailyRatingAsInteger];
NSLog(#"Daily Rating Entered is %#", ddailyRating);
NSString *ddailyAccomplishment = self.textFieldAccomplishment.text;
NSLog(#"Daily Accomplishment Entered is %#", ddailyAccomplishment);
NSInteger dailyAccompRatingAsInteger = [self.textFieldAccomplishmentRating.text integerValue];
NSNumber *ddailyAccompRating = [NSNumber numberWithInteger:dailyAccompRatingAsInteger];
NSLog(#"Daily Accomp Rating Entered is %#", ddailyAccompRating);
// Create a new instance of Day
Day *newDay = [NSEntityDescription
insertNewObjectForEntityForName:#"Day"
inManagedObjectContext:context];
if (newDay != nil){
// Set the properties according to the values we retrieved from the text fields
newDay.dailyAccomp = ddailyAccomplishment;
newDay.dailyRating = ddailyRating;
newDay.dailyAccompRating = ddailyAccompRating;
NSError *savingError = nil;
// Save the new day
if ([context save:&savingError] == YES){
// If successful, simply go back to the previous screen
[self.navigationController popViewControllerAnimated:YES];
} else {
// If we failed to save, display a message
[self
displayAlertWithTitle:NSLocalizedString(#"Saving", nil)
message:NSLocalizedString(#"Failed to save the context", nil)];
}
} else {
// We could not insert a new Day managed object
[self
displayAlertWithTitle:NSLocalizedString(#"New Day", nil)
message:NSLocalizedString(#"Failed To Insert A New Day", nil)];
}
}
I've commented out most of the code to try to find the offending statement, and it seems to be
**NSManagedObjectContext *context = delegate.managedObjectContext;**
That is, if I comment everything below and including this stmnt, app doesn't crash. It doesn't do anything, it just "waits" (as expected). If I uncomment this stmnt, app crashes. SelfEsteemBldrAppDelegate is also imported using the #import "SelfEsteemBldrAppDelegate.h' stmnt.
Again, the error that I'm getting is in the Core Data Stack persistentStoreCoordinator method within SelfEsteemBldrAppDelegate.m. The crash occurs at the following:
NSURL *storeURL = [[self applicationDocumentsDirectory] URLByAppendingPathComponent:#"SelfEsteemBldr.sqlite"];
The error that I'm given is
[NSPathStore2 URLByAppendingPathComponent:]: unrecognized selector sent to instance 0x4d6f440
So, after all that, any ideas as to why I might be getting this message, and what I can do to resolve it? From what I understand, I'm not supposed to interact with the Core Data Stack methods, so I don't want to fool around with that code. Any help would be greatly appreciated. Also, if I've left out any info you may need, please let me know. Thanks.
Normally, I faced this problem and encountered that this error comes when managedObjectContext is nil... To solve this i have used below code and worked fine for me..
if (managedObjectContext == nil) {
managedObjectContext = [(iBountyHunterAppDelegate *) [[UIApplication sharedApplication] delegate] managedObjectContext];
}

IPhone autoreleasing a returned NSMutableArray

I'm still relatively new to iPhone development but thought I understood the basic principals of memory management. I have a class method that returns an NSMutableArray, I'm calling alloc and init on the object therefore know I'm responsible for releasing it. However because I'm returning the array I assumed I was supposed to use autorelease when creating the object instead of releasing it.
+(NSMutableArray *)getStations:(int)stationType {
if(database == nil){
[self openDataBase];
}
// Create a temporary array to hold the returned objects
NSMutableArray *holder = [[[NSMutableArray alloc] init] autorelease];
// Check if the statement has been defined
if(select4 == nil) {
const char *sql = "SELECT station_id, station_name, AVG(test_percent) FROM stations LEFT JOIN tests USING (station_id) WHERE station_type = ? GROUP BY station_id ORDER BY station_name ASC";
if(sqlite3_prepare_v2(database, sql, -1, &select4, NULL) != SQLITE_OK){
NSLog(#"Error while creating detail view statement. '%s'", sqlite3_errmsg(database));
}
}
sqlite3_bind_int(select4, 1, stationType);
// Check if the statement executed correctly
while(sqlite3_step(select4) == SQLITE_ROW) {
NSInteger primaryKey = sqlite3_column_int(select4, 0);
Tests *station = [[Tests alloc] initWithPrimaryKey:primaryKey];
station.station_name = [NSString stringWithUTF8String:(char *)sqlite3_column_text(select4, 1)];
station.average_score = [NSNumber numberWithDouble:sqlite3_column_double(select4, 2)];
[holder addObject:station];
[station release];
}
// Reset the detail statement.
sqlite3_reset(select4);
// Return the holder array
return holder;
}
There's the basic code - XCode no longer indicates a potential memory leak but it crashes everytime that code executes saying message sent to deallocated instance. Any help would be appreciated I've spent ages googling and can't see what's wrong with the code. I did find this thread but it doesn't appear to be the answer to my question - crash happens when NSMutableArray is returned?
The code you've posted appears to be managing memory correctly – you've got a one-to-one relationship between retains and (auto)releases, and you're making a textbook use of autorelease – so the problem is probably that the code calling this method needs to retain the resulting array before the autorelease pool kicks in and yanks the rug out from under you.
If your code is assigning the NSMutableArray to an ivar you've declared with #property, that ivar needs to be declared as
#property (retain) NSMutableArray *myStations;
If you're doing something else to store the array, you may need to call [myStations retain]. Your table view code will also need to release the array, probably in its dealloc method.
If you want to use the returned NSMutableArray as a data source to fill in rows in a table view, then you're going to need to retain it in your UITableView class (or your UITableViewDataSource delegate class). It's going to be called repeatedly whenever the view is scrolled or otherwise needs updating.
Easiest thing to do is make it a retained property in that class.
#property (nonatomic, retain) Tests * stationArray;
Then, say, if you want to get your data in your viewDidLoad method:
self.stationArray = [self getStations: self.stationID]; // property retains
Access it in numberOfRowsInSection:
return self.stationArray.count;
Access it in cellForRowAtIndexPath:
Tests *station = [self.stationArray objectAtIndex:indexPath.row];
And, of course, in dealloc...
[stationArray release];
The autorelease in the method is correct (not an init or copy method), but the class will need to retain it if it wants to use it later on, after the current event.

How to release an object in a forin loop?

I'm new to cocoa / objective-c and i'm struggeling with the releases of my objects. I have the following code:
gastroCategoryList = [[NSMutableArray alloc] init];
for (NSDictionary *gastrocategory in gastrocategories) {
NSString *oid = [gastrocategory objectForKey:#"id"];
GastroCategory *gc = [[GastroCategory alloc] initWithId:[oid intValue] name:[gastrocategory objectForKey:#"name"]];
[gastroCategoryList addObject:gc];
}
The analyzer shows me that the "gastrocategory" defined in the for is a potential memory leak. But i'm not sure if i can release this at the end of the for loop?
Also at the following code:
- (NSArray *)eventsForStage:(int)stageId {
NSMutableArray *result = [[NSMutableArray alloc] init];
for (Event *e in eventList) {
if ([e stageId] == stageId) {
[result addObject:e];
}
}
return result;
}
The Analyzer tells me that my "result" is a potential leak. But where should I release this?
Is there also a simple rule to memorize when i should use assign, copy, retain etc. at the #property ?
Another problem:
- (IBAction)showHungryView:(id)sender {
GastroCategoriesView *gastroCategoriesView = [[GastroCategoriesView alloc] initWithNibName:#"GastroCategoriesView" bundle:nil];
[gastroCategoriesView setDataManager:dataManager];
UIView *currentView = [self view];
UIView *window = [currentView superview];
UIView *gastroView = [gastroCategoriesView view];
[window addSubview:gastroView];
CGRect pageFrame = currentView.frame;
CGFloat pageWidth = pageFrame.size.width;
gastroView.frame = CGRectOffset(pageFrame,pageWidth,0);
[UIView beginAnimations:nil context:NULL];
currentView.frame = CGRectOffset(pageFrame,-pageWidth,0);
gastroView.frame = pageFrame;
[UIView commitAnimations];
//[gastroCategoriesView release];
}
I don't get it, the "gastroCategoriesView" is a potential leak. I tried to release it at the end or with autorelease but neither works fine. Everytime I call the method my app is terminating. Thank you very much again!
In your loop, release each gc after adding it to the list since you won't need it in your loop scope anymore:
gastroCategoryList = [[NSMutableArray alloc] init];
for (NSDictionary *gastrocategory in gastrocategories) {
NSString *oid = [gastrocategory objectForKey:#"id"];
GastroCategory *gc = [[GastroCategory alloc] initWithId:[oid intValue] name:[gastrocategory objectForKey:#"name"]];
[gastroCategoryList addObject:gc];
[gc release];
}
In your method, declare result to be autoreleased to absolve ownership of it from your method:
NSMutableArray *result = [[[NSMutableArray alloc] init] autorelease];
// An alternative to the above, produces an empty autoreleased array
NSMutableArray *result = [NSMutableArray array];
EDIT: in your third issue, you can't release your view controller because its view is being used by the window. Setting it to autorelease also causes the same fate, only delayed.
You'll have to retain your GastroCategoriesView controller somewhere, e.g. in an instance variable of your app delegate.
BoltClock's answer is spot-on as to the first part of your question. I'll try to tackle the rest.
Assign is for simple, non-object types such as int, double, or struct. It generates a setter that does a plain old assignment, as in "foo = newFoo". Copy & retain will, as their names imply, either make a copy of the new value ("foo = [newFoo copy]") or retain it ("foo = [newFoo retain]"). In both cases, the setter will release the old value as appropriate.
So the question is, when to copy and when to retain. The answer is... it depends. How does your class use the new value? Will your class break if some other code modifies the incoming object? Say, for example, you have an NSString* property imaginatively named "theString." Other code can assign an NSMutableString instance to theString - that's legal, because it's an NSString subclass. But that other code might also keep its own reference to the mutable string object, and change its value - is your code prepared to deal with that possibility? If not, it should make its own copy, which the other code can't change.
On the other hand, if your own code makes no assumptions about whether theString might have been changed, and works just as well whether or not it was, then you'd save memory by retaining the incoming object instead of unnecessarily making a copy of it.
Basically, the rule, which is unfortunately not so simple sometimes, is to think carefully about whether your own code needs its own private copy, or can correctly deal with a shared object whose value might be changed by other code.
The reason you can release gc after it is added to the gastroCategoryList is that when an object is added to an array, the array retains that object. So, even though you release your gc, it will still be around; retained by the gastroCategoryList.
When you are returning a newly created object from a method, you need to call autorelease. This will cause the object to be released only after the runtime leaves the scope of the calling method, thereby giving the calling method a chance to do something with the returned value.
Note that if your method starts with the word copy or new, then you should not autorelease your object; you should leave it for the calling method to release.
As for copy vs retain vs assign... as a general rule, copy objects that have a mutable version, such as NSArray, NSSet, NSDictionary, and NSString. This will ensure that the object you have a pointer to is not mutable when you don't want it to be.
Otherwise, use retain whenever you want your class to be ensured that an object is still in memory. This will apply to almost every object except for objects that are considered parents of your object, in which case you would use assign. (See the section on retain cycles here).
Also note that you have to use assign for non-object types such as int.
Read through the Memory Management Programming Guide a bit; it's quite helpful.

Add an instance of NSManagedObject to NSManagedObjectContext ok, updating the same instance failed

I am using core data in my iPhone app. I have created a simple class Friend, which derives from NSManagedObject and which uses the following property:
#property (nonatomic, retain) NSString *name;
I am able to add and delete instances of this class to my context and my changes are persistent also.
Now I want to update/modify a Friend-instance and make it persistent again.
But this seems not to work.
Here is piece of code which shows my problem:
// NSManagedObjectContext *context = < my managed context>
// NSFetchedResultsController *nsfrc= < my fetched result controller>
NSEntityDescription *entity = [nsfrc entity];
NSManagedObject *newManagedObject = [NSEntityDescription
insertNewObjectForEntityForName:[entity name] inManagedObjectContext:context];
Friend *f = (Friend *) newManagedObject;
f.name = #"name1";
//1. --- here context.hasChanges == 1 --- ok
NSError *error = nil;
if (![context save:&error]) { ... }
//2. --- here context.hasChanges == 0 --- ok
f.name = #"name2";
//3. --- here context.hasChanges == 0 --- nok?
if (![context save:&error]) { ... }
At comment 1 everything is fine. I got a new NSManagedObject of the Friend-type and I can change the name property. The context shows me that there is something to save.
After saving the context I see context.hasChanges == 0. Note also that the data is persistent after saving the context.
After comment 2 I change the name property. Now I would expect context.hasChanges == 1 and also after the context save I would expect the new name to be persistent.
But unfortunately It is not. Starting the application again, loads the Friend instance with the name-property = #"name1".
I cannot find any hint or example inside the core data documentation. So what am I doing wrong?
What do I have to do to update/modify an existing Friend-instance and to make it persistent?
The only solution I see is to delete the entry, change it, and add it again. But I don't think that this is the correct way for it.
Thanks!
The failure to recognise changes was possibly due to you using #synthesize instead of #dynamic in your subclass implementation. CD provides its own accessors which you will bypass using #synthesize
Martin
The only thing I can think of is that the context is having trouble observing the Friend object because you've initialized it as a generic NSManagedObject instead an instance of the Friend subclass.
The generic NSManagedObject does not store values in properties like it's subclasses do. Instead, it uses associative storage which is akin to a generic dictionary. In other words, a generic NSManagedObject stores and accesses value in a different location and using a different method of setting and getting than does its subclass. At runtime, this may cause the context confusion.
The first time you check the context, you getting a hasChangess==YES because you've inserted a new object into the object graph. The second time, you're just changing an attribute of an existing object. If the context cannot accurately observe the value of the name key it will not know it has to save the object again on the second pass.
Change:
NSManagedObject *newManagedObject = [NSEntityDescription
insertNewObjectForEntityForName:[entity name] inManagedObjectContext:context];
...to:
Friend *newFriend = [NSEntityDescription
insertNewObjectForEntityForName:[entity name] inManagedObjectContext:context];
... and see if that resolves the problem.
Otherwise, the code looks fine.
Finally found the solution! For my above question I removed all unnessesary code (unfortunately I also removed my problem). So, to complete this thread:
My Friend-class also has a member:
#property (nonatomic) int duration;
In my test environment I also set the duration (whenever I set the name). This seems to be the reason why the context is not able to recognize any change. If I change the property to
#property (nonatomic, retain) NSNumber duration;
everything worked fine. Note that my xdatamodel has a property duration of type Int32.
What I not understand is, why everything worked for the first [context save];. But this is ok for me for now.
To give some good advice here:
Do NOT generate your xdatemodel out of your NSManagedObject-derived class (as I did).
Instead create your xdatemodel and then generate your class out of your model (Xcode->Design->DataModel->Copy Obj-C2.0..)!
(Update 03/2011: Generating the Classes out of the Model works like a charm in XCode 4.0!)
I wish I had known this early on this beautiful sunday morning.
Good evening!

NSInvalidArgumentException: Illegal attempt to establish a relationship between objects in different contexts

I have an app based on the CoreDataBooks example that uses an addingManagedObjectContext to add an Ingredient to a Cocktail in order to undo the entire add. The CocktailsDetailViewController in turn calls a BrandPickerViewController to (optionally) set a brand name for a given ingredient. Cocktail, Ingredient and Brand are all NSManagedObjects. Cocktail requires at least one Ingredient (baseLiquor) to be set, so I create it when the Cocktail is created.
If I add the Cocktail in CocktailsAddViewController : CocktailsDetailViewController (merging into the Cocktail managed object context on save) without setting baseLiquor.brand, then it works to set the Brand from a picker (also stored in the Cocktails managed context) later from the CocktailsDetailViewController.
However, if I try to set baseLiquor.brand in CocktailsAddViewController, I get:
Terminating app due to uncaught exception
'NSInvalidArgumentException', reason:
'Illegal attempt to establish a
relationship 'brand' between objects
in different contexts'
From this question I understand that the issue is that Brand is stored in the app's managedObjectContext and the newly added Ingredient and Cocktail are stored in addingManagedObjectContext, and that passing the ObjectID instead would avoid the crash.
What I don't get is how to implement the picker generically so that all of the Ingredients (baseLiquor, mixer, garnish, etc.) can be set during the add, as well as one-by-one from the CocktailsDetailViewController after the Cocktail has been created. In other words, following the CoreDataBooks example, where and when would the ObjectID be turned into the NSManagedObject from the parent MOC in both add and edit cases? -IPD
UPDATE - Here's the add method:
- (IBAction)addCocktail:(id)sender {
CocktailsAddViewController *addViewController = [[CocktailsAddViewController alloc] init];
addViewController.title = #"Add Cocktail";
addViewController.delegate = self;
// Create a new managed object context for the new book -- set its persistent store coordinator to the same as that from the fetched results controller's context.
NSManagedObjectContext *addingContext = [[NSManagedObjectContext alloc] init];
self.addingManagedObjectContext = addingContext;
[addingContext release];
[addingManagedObjectContext setPersistentStoreCoordinator:[[fetchedResultsController managedObjectContext] persistentStoreCoordinator]];
Cocktail *newCocktail = (Cocktail *)[NSEntityDescription insertNewObjectForEntityForName:#"Cocktail" inManagedObjectContext:self.addingManagedObjectContext];
newCocktail.baseLiquor = (Ingredient *)[NSEntityDescription insertNewObjectForEntityForName:#"Ingredient" inManagedObjectContext:self.addingManagedObjectContext];
newCocktail.mixer = (Ingredient *)[NSEntityDescription insertNewObjectForEntityForName:#"Ingredient" inManagedObjectContext:self.addingManagedObjectContext];
newCocktail.volume = [NSNumber numberWithInt:0];
addViewController.cocktail = newCocktail;
UINavigationController *navController = [[UINavigationController alloc] initWithRootViewController:addViewController];
[self.navigationController presentModalViewController:navController animated:YES];
[addViewController release];
[navController release];
}
and here's the site of the crash in the Brand picker (this NSFetchedResultsController is backed by the app delegate's managed object context:
- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
UITableViewCell *cell = [tableView cellForRowAtIndexPath:indexPath];
cell.accessoryType = UITableViewCellAccessoryCheckmark;
if ([delegate respondsToSelector:#selector(pickerViewController:didFinishWithBrand:forKeyPath:)])
{
[delegate pickerViewController:self
didFinishWithBrand:(Brand *)[fetchedResultsController objectAtIndexPath:indexPath]
forKeyPath:keyPath]; // 'keyPath' is #"baseLiquor.brand" in the crash
}
}
and finally the delegate implementation:
- (void)pickerViewController:(IngredientsPickerViewController *)pickerViewController
didFinishWithBrand:(Brand *)baseEntity
forKeyPath:(NSString *)keyPath
{
// set entity
[cocktail setValue:ingredient forKeyPath:keyPath];
// Save the changes.
NSError *error;
if (![cocktail.managedObjectContext save:&error]) {
// Update to handle the error appropriately.
NSLog(#"Unresolved error %#, %#", error, [error userInfo]);
exit(-1); // Fail
}
// dismiss picker
[self.navigationController popViewControllerAnimated:YES]
}
EVEN MORE
I'm making progess based on Marcus' suggestions -- I mapped the addingManagedObjectContexts to the parent managedObjectContext and wrapped everything in begin/endUndoGrouping to handle cancel vs. save.
However, the object to be created is in an NSFetchedResultsController, so when the user hits the "+" button to add the Cocktail, the (possibly-to-be-undone) entity briefly appears in the table view as the modal add view controller is presented. The MDN example is Mac-based so it doesn't touch on this UI behavior. What can I do to avoid this?
Sounds like you are creating two different Core Data stacks (NSManagedObjectContext, NSManagedObjectModel, and NSPersistentStoreCoordinator). What you want to do from the example is just create two NSManagedObjectContext instances pointing at the same NSPersistentStoreCoordinator. That will resolve this issue.
Think of the NSManagedObjectContext as a scratch pad. You can have as many as you want and if you throw it away before saving it, the data contained within it is gone. But they all save to the same place.
update
The CoreDataBooks is unfortunately a really terrible example. However, for your issue, I would suggest removing the creation of the additional context and see if the error occurs. Based on the code you posted and I assume the code you copied directly from Apple's example, the double context, while virtually useless, should work fine. Therefore I suspect there is something else at play.
Try using a single context and see if the issue persists. You may have some other interesting but subtle error that is giving you this error; perhaps a overrelease somewhere or something along those lines. But the first step is to remove the double context and see what happens.
update 2
If it is crashing even with a single MOC then your issue has nothing to do with the contexts. What is the error you are getting with a single MOC? When we solve that, then we will solve your entire issue.
As for a better solution, use NSUndoManager instead. That is what it is designed for. Apple REALLY should not be recommending multiple MOCs in their example.
I answered a question on here recently about using the NSUndoManager with Core Data but you can also look at some of my articles on the MDN for an example.
Yeah, you definitely don't want to cross context boundaries when setting relationships between objects; they both need to be in the same NSManagedObjectContext. In the old EOF, there were APIs for faulting objects into different contexts, but doesn't look like CoreData has an equivalent.