Core Data not returning a custom concrete class

Ever had a problem when you’re fetching something from an NSManagedObjectContext, and you’ve set a concrete class in your model, only to find that it is an NSManagedObject? Me too.

I read this post at StackOverflow, which suggested that you have to create the subclass using Xcode, from within the modeler. OK, I thought. I’ll try that.

I deleted my old .h and .m files. I went into the modeler. I created a new Managed Object class. And put my custom code back in.

And it didn’t work!

But never fear. I did a Clean, and it worked.

Temporary NSManagedObjectIDs

I’ve run into a problem where I insert a managed object into a managed object context, in a separate thread, and then return the object ID to the main thread and then retrieve the object from the main thread’s context using that ID.

It didn’t always work. It is because I saved the first managed object context after I took the object ID. And the object ID was temporary because the object hadn’t been persisted. And the temporary object ID became invalid after the context was saved.

It didn’t always happen because my code will either insert or update when doing the JSON deserialisation. So if the object already existed in my persistent store, it would retrieve a proper object ID.

So the moral of the story is that you should always save your managed object context before getting the newly inserted object’s ID.

binding not implemented for this SQLType 7: Core Data and iPhone OS 3

*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'binding not implemented for this SQLType 7'

That’s not something you want to read. And it doesn’t make much sense. And there’s not a lot out there on that problem, either.

I am adding Core Data to Zoopcast (the people-powered local search app). The first few releases just took data from the JSON web service, and put it into unmanaged objects. (As it turns out, I probably should have gone with Core Data from day one. Despite what the docs say, it’s not that difficult. In fact, probably easier than what I was doing.)

I read that SQLType 7 is the REAL storage class in SQLite. And that storage class can handle different types of data. And I thought to myself… perhaps I am putting floats instead of doubles, somewhere in my code (which is permitted in C, and my managed objects have NSNumber properties anyway) and it’s that mapping that is getting the Core Data/SQLite layer confused.

So I had a look.

The NSDictionaries that were being decoded from JSON with JSON Framework had NSNumber objects that were NSDecimal (one of the private subclasses of NSNumber). I’m not sure if they were all NSDecimal, but they probably were: they’re stored as double precision floating point numbers in the service, and obviously have to be rounded for JSON transport, so decimal makes the most sense.

So I thought… why not force these to all be doubles, like so:

double doubleValue = [(NSNumber *)value doubleValue];
value = [NSNumber numberWithDouble:doubleValue];

And guess what? It fixed it.

This wasn’t a problem on iOS 4. It was only a problem on an iPod touch first generation running iPhone OS 3.1.3. But it’s not longer a problem for me.

It was this post on Stack Overflow that lead me on the right track, and Brian King’s answer actually makes perfect sense to me now that I’ve re-read it after figuring it for myself and explaining it in long form.

Width of grouped UITableViewCell

I am working on some iPhone development at the moment. I have built a cell for a UITableView in Interface Builder. The cell was a bit too wide for the cell in my table view, and I realised it was because the cell in the NIB is full width but I am loading it into a grouped table view.

I didn’t want to have to measure it myself so I searched for the width. Couldn’t find it. So I measured it myself. And put it here. So maybe I will start getting a few more visits to this page from now on!

The magic number is…

300

The width of a grouped UITableViewCell is 300 pixels.