Core Data & Multi-Threading, part 1337

So i've made yet another Core Data Discovery, at this rate i might need to write a ebook. Now we all know that the golden rule of using Core Data with different threads is to not share contexts between threads.
So if you need to refer to an object on multiple threads you need to use it's NSManagedObjectID. Thats all well and good, but what if you need to call [NSManagedObjectContext save:] multiple times. Well in short it's gonna suck. Well thats cool you say, i can just use the id anyway ... Not quite. There are two types of ID's, permanent and temporary.
Now in my experience Core Data seems to get confused when you use temporary ID's to look up objects on another NSManagedObjectContext. So really to stop these conflicts we need to get a permanent id, but we need to obtain one of these ID's without saving the NSManagedObjectContext.


Well are you ready for the magic ... Shazam

[NSManagedObjectContext obtainPermanentIDsForObjects: error:]

This awesome method will take an array of managed objects, and give them permanent ID's. From my brief tests the overhead is minimal compared to the traditional save method.

Thats all i've got for today, keep on trucking.

[]'s 4 life

Asynchronous Core Data searches with Blocks

I was recently fortunate enough to be able to drop iOS 3 support on a project. This meant that i could start to play around fully with Blocks on iOS. One thing that has always got on my nerves is that there is no built in support for asynchronous Core Data searches.

Previously i tried to wrap up potentially long operations in a special FRCoreDataOperation a subclass of NSOperation. However this was a pain, as i would then have to subclass it or modify the parent class to provide me with a simple callback when the task was complete.

What i really longed for was the way in which you make Ajax requests in jQuery, that of course requires closures, which are of course provided in the form of Blocks. So after hacking around for a bit i came up with this.

Now this is my first real time using blocks outside of simple things like iteration etc. It means that i can do

Now here's the part where i pat myself on the back. The callbacks are executed on the main thread, after the async fetch request is completed. Plus it gets better, The NSArray, for the onComplete block contains a list of the returned objects that are registered with the NSManagedObjectContext for the main thread, or in other words the NSManagedObjectContext you used to perform the fetch.

Once i touch down in the valley i plan to extend this to manage saves as well, making the basic CRUD operations with Core Data "scroll like butter".