The Results

So last week I laid down the gauntlet that I was going to use this down week from work to rework Pain Logger to use the Realm database engine instead of CoreData and sync it all with CloudKit. Here are the results:

Monday

So I started looking at the existing code and I realized I needed to reorganize it a bit. In order to make it easy to manage and maintain, my idea was to create a single DataService class and have all persistence requests go through that.

The original Pain Logger code had a fairly standard CoreData stack being stood up in the AppDelegate (capturing the MOC on the way) and then it used helper classes for each of the managed objects. These helper classes isolated persistence logic away from the managed object instances and out of the AppDelegate. There was one managed object type per table and therefore one helper class per object type.

So my first order of business was to move all the helper methods and the CoreData stack initialization to the new DataService class.

I actually decided to concentrate on one UIViewController (VC) at a time, and move just the persistence methods it used. That way I could see progress.

After moving the methods for my first VC, I tested and found everything was still working.

The first VC just shows a list of the top level objects in my database so it wasn’t that hard.

Now I needed to install Realm. My idea was when the DataService stood up it would not only configure it’s existing CoreData stack, but it would also stand up the Realm database in order to migrate all the records.

I installed Realm for Swift 2.1 per the documentation Realm provides when you download their code.

I also installed the other tools, such as the Realm plugin for XCode and the Mac app Realm browser.

The only catch was after adding the “Run Script” (per Realm’s documentation) and trying a build, the build failed because the “strip-frameworks.sh” script didn’t have execute permission. So I opened up terminal and added execute permission to that file and all was good. Note: after you make this permission change, you next need to do a project clean so you won’t be using a cached version of the script.

My next hurdle was I needed to create Realm representations of the managed objects. So for example my Category class (which extends NSManagedObject) got a sister class called PLCategory (which extends Object).

Here was my first dilemma (and opportunity for improvement). CoreData doesn’t support enums, so all the enums in my data objects had to be converted back and forth between NSNumber objects. In Realm the answer to this is to overide the variable’s getter/setters. For example in the CoreData model assume you have this variable:

@NSManaged var line_color:NSNumber

I have an enum for this variable called LineColorType, so in the Realm object this becomes:

private dynamic var line_color = LineColorType.LINE_COLOR_GREEN.rawValue
var lineColor:LineColorType {
    get {
        return LineColorType(rawValue:line_color)!
    }
    set {
        line_color = newValue.rawValue
    }
}

The big change here is the application code will use the more standard camel case variables while Realm will store the raw value variables in it’s database.

My guess is I probably could have done this same thing with CoreData, but I’m not on that right now.

Delimma: There is a lot of boiler plate code left around to support CoreData and now adding Realm, although the new code is tighter, it is still MORE code. When do I get rid of the boiler plate code? I think the best approach is to finish all the changes and submit an update to the app store then after about 6 months (once I feel confident all existing users have upgraded and opened the app so the database has been migrated) I’ll remove the old CoreData code.

Day 1 Progress:
At the end of the day I have the model migrating to Realm. A good start I think. Tomorrow, I’ll start on the CRUD operations.

I ran into two issues for the day. First, how do I browse my Realm database. This StackOverflow link shows how to do that.
Second, my computed fields showed up in the database as well. It turned out I needed to mark them as non-persistent.

Delimma: Do I need a unique id on my objects? I decided I did, but I couldn’t just use an int because Realm currently doesn’t have an autoincrementing id scheme (it supposedly is coming). Anyway I choose to use NSUUID.UUIDString in the interum. We’ll see how that goes.

Tuesday

For today, my goal was to flesh out the persistence layer. My idea was to, along with the default Realm, set up a Realm for caching data when the user is offline, and a Realm to simulate the eventual online CloudKit support.

For testing purposes I plan to have a flag that I can turn on and off to simulate the app being in offline mode. Eventually this will be replaced by real code to check the availability.

As usually happens for plans like these, I ran into a snag.

I needed to add some test data, so I started using the app and realized there were parts of the UI that after the conversion to Swift didn’t functionally work, although they did compile.

It turns out I had used a automated conversion program to convert some of the original Objective-C code so that I didn’t have to type as much and it didn’t convert it as well as I would have liked.

So I spent most of the day fixing those issues.

By the end of the day I was able to add records as before, with them getting saved both to the CoreData database and the default Realm.

Wednesday

Today was a short day due to the preparations for the Thanksgiving holiday. My plan was to regroup and get more of the things I had planned to accomplish the previous day working.

One of the nagging issues I had was I feel the need to keep the old CoreData code active, while also adding the new Realm support. That way my existing ViewControllers can consume the old model objects until I am ready to make the transition to the new model objects. But this has turned out to be more problematic than I had hoped.

Another issue is parent-child relationships. In the existing code, when adding a new child, the child object would first be added to the database and then some updates were done on some computed values on the parent object and it would be saved.

This caused me to have multiple completion handlers that “chained” the updates. With Realm I can do all of that in one write transaction which is very helpful, but untangling the mess I created in the old code will take a bit of time.

Side note: Argghh! I’ve been “working” for about 3 hours and only got about 30 minutes of work in. I need to fill all these people up with tryptophan and me with caffeine. Unfortunately that won’t happen till tomorrow.

One thing that I don’t understand right now is should I cache the Realm’s I create? Are they expensive to stand up. Reading the documentation it feels like they are not. So to be thread safe right now I will make the Realm accessors in my DataService be computed attributes like this:

private var defaultRealm:Realm {
    get {
       return try! Realm()
    }
}

Is this a bad idea? I’m not sure.

Thursday - Thanksgiving

Not sure I will get much done today. Too much food, family and football!!

Friday - Saturday - Sunday

Well as expected, too much family time and not enough development time. I’ll have to continue this effort next week.

I didn’t quite make the goal I had originally started out to do, although now, I am much more comfortable with using Realm and I think this will be a very fruitful effort. I’ll make another post in a couple weeks to update my progress.

Till next time,