views:

36

answers:

2

I have a plain XCode CoreData enabled iPhone/iPad navigation application. In this I have modifed the data it initially defines to represent some categories in the table view with associated images. For example by modifying a Event to Category elsewhere, changing the .xcdatamodel file and altering this call in RootController.m:

- (void)configureCell:(DeliciousCategoryCell *)cell atIndexPath:(NSIndexPath *)indexPath {

    NSManagedObject *managedObject = [self.fetchedResultsController objectAtIndexPath:indexPath];
    cell.categoryLabel.text = [[managedObject valueForKey:@"name"] description];
    NSString *filePath = [[NSBundle mainBundle] pathForResource:cell.categoryLabel.text ofType:@"tiff"];
cell.categoryImage.image = [[UIImage alloc] initWithContentsOfFile:filePath];
}

If I preload the data from an xml file by putting code in:

-(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions

The data gets loaded in fine but the app subsequentially crashes with EXC_BAD_ACCESS. If I take that code out the app loads, my data is present and my categories display fine with the associated local images. I've tried moving the code in question elsewhere such as:

- (NSPersistentStoreCoordinator *)persistentStoreCoordinator

and checking to make sure the data is empty however it still crashes yet loads the data. I can't seem to track down the cause of the EXC_BAD_ACCESS via the debugger as the stack trace is void of useful information. What I would like to know is an answer to the following as I cannot find it in apples documentation:

1) When such a Core Data based application first starts where should the calls to load in an initial data set go? I would ideally do this via the web but am currently just opening a local xml file for testing.

2) Once core data has been loaded I would like to enable the user to update the core data information by merging. Where should such code reside?

I don't have a problem with the logic just the location of the necessary code afaict. If anyone would like a listing of what I'm doing I'll provide but it is rather verbose. The code as implemented is taken straight from two apple tutorials. The latter detailing how to load in data without undue fetches/selects on the data base, however said tutorial doesn't say anything about where it should reside.

A: 

When you see EXC_BAD_ACCESS, you have over-released an object. Here is some troubleshooting advice.

Alex Reynolds
Thanks for the advice, I solved the problem eventually, excuse the personal link but I can't seem to find the post I made on the official mac forums:http://www.thelostsouls.org.uk/2010/07/how-to-populate-coredata-at-runtime-from-a-remote-source/
Diziet
+2  A: 

I think you're to fixated on the location of the code being the problem.

Objective-C, Core Data and the general Apple API are all very encapsulated and modular. You can plug in needed functionality almost anywhere and activate it or not at almost any time. The only critical locations/times are app delegate methods related to the starting and stopping of the app. Everything else is flexible. In your case, you only need to load data before you use it and you only need to merge data after it has changed. The possible configurations of when and where are functionally infinite. Different apps do all this at different places and times.

You should be looking at a more prosaic cause of the EXC_BAD_ACCESS. Under normal conditions, the debugger will show you the line where the crash happens. If it shows nothing, then the debugger itself most likely crashed. More likely, you just missed the display of the crashed line because the line in your code that triggered it is scrolled off the screen of the stack trace. (A lot of beginners make that mistake.)

TechZen
With regards to the debugger (the visual one not the gdb kind which I know, the gdb one displayed zip) it only displayed 2 lines which were pretty deep into apple libraries.I think you're definitely right about me being fixated on that rather than looking at more general causes of the mistake thanks for plain language over view. I must confess I still find myself putting breakpoints into controller functions to check the order in which they load. :)As mentioned in another comment below I solved the problem, albeit in a hackery fashion.
Diziet