Core Data – The unconventional use – Synchronize Data to REST Web Services

My unusual long absence from blogging is caused by picking up Core Data and RestKit at the same time. These two technologies are seriously not for the faint hearted, especially people who is new to Objective-C and trying to do some Data driven application. But, whichever way you take, whatever methodology you choose, you can’t escape the fate of these two giants. Unless, of course you like messing around with SQLLite or PLIST, and handle all the server response yourself, handling timeout, handling request queue canceling manually. Those are some of the daunting task that I faced when I looked at my options when presented the technical requirement of my most recent iOS project. So I chose Restkit, the behemoth for its superiority in support and strong framework for RESTful API calls and Core Data for doing any sort of data writing, retrieving and also deleting. It turns out that my choice has quite a lot of grey areas that I didn’t foresee. Let’s start with Restkit.

First of all, Restkit framework has two types of RESTful calls, one with object mapping, known as RKObjectLoader, RK being Restkit. And the other is RKRequest. While it might seem redundant as to why having two types of methods to do almost the same thing. Well, for starter, RKObjectLoader, as its name suggest, may help developer shorten the time of developing app by automatically map returning object string straight into the object that you can use, out of the box! How nice! But I didn’t use it at all in the end, simply because the developer of Restkit see it fit that this method only can call of GET, which basically limits quite a lot of stuff that I can do. And most of the calls that my app will be calling upon , needs POST, which has zero support in RKObjectLoader. So, I have no choice but to try using RKRequest for Post and RKObjectLoader for GET. But as any developer will tell you, if RKRequest can already handle GET just nice, why on earth would I want to use RKObjectLoader? I could have done away with simple SBJSON for parsing the returning string and still be able to map object out of them. And that’s what I did, I get rid of RKObjectLoader, and use RKRequest and RKRequest only for all API calls. It just makes things much happier and simpler.

That’s not all, apparently Restkit thinks that of all the headers that I will be using, it will be either HTTPForm or encoded form. They totally forgot about application/json! And that’s what I needed for the header if I intend to send over JSON to the API. I did that has to be done, hacked around in the framework and override quite a number of functions before getting all my POST request to have the header of application/json. Reskit developers out there if you hear me, please allow peeps like me to be able to change header with ease.

Now let’s go into Core Data. It’s a nice framework built by Apple engineer on top of SQLLite. It has higher level of abstraction, so you don’t need to code like mad just to get a simple stuff done. It was nice and easy to use. Easy to set up as well! It can do everything that it’s designed to do, perfectly. Which is having one instance of ModelObjectContext at any given time and have an NSFetchedResultsController that update your view in real time! How cool is that! And as I soon found out that, the App that I will be developing, needs synchronization to allow for offline data edit and viewing. And those data can then be used on the web and user can start creating/updating/deleting items and those changes has to be reflected back to the app. So, how do I do that?

There were two solutions that seem very apparent to me. First one is to create a draft Persistent store and store a copy of update from the API and compare them to those in the App and do the update accordingly. But that would actually take me too much time to implement, as I now need to take of two Persistent store and constantly need to make sure that my data don’t corrupt or mixed up! So I thought.

The second solution was quite the obvious. Using more than one ModelObjectContext to do the updating/deleting/creating. And tones of errors and crashes happen when you try to make Core Data something that it’s not. And all of those problems were caused mostly by the NSFetchedResultsController of my app’s main page, that constantly updating the interface with the data in Persistent Store. It kept throwing me errors, Serious Core Data Application error, for goodness’ sake. I wasn’t able to get my mind around why did it crash so often.But later on, I found a solution for the problem, it was quite an elaborate solutions to enable multiple items synchronization. The solutions were not straight forward, nor was it mentioned anywhere else on the internet. But I guess I have to agree with the developers out there that perhaps have tried the things that I do. It was a lot of hair pulling and head banging.

But rule of thumb for me when I am messing around with multiple ModelObjectContext that writes to the same Persistent store. That is, to make sure you update all ModelObjectContext after you programmatically changes something in the Persistent Store.