I’ve spent much of my career writing apps that store objects locally that come from the web — and that may change on the web, and then need to be updated locally.
This kind of code can be tedious to write. Given a local object and an objectified version of some JSON or XML or whatever, I’d write something like this (translated to Swift for fun):
if localObject.foo != serverObject.foo {
localObject.foo = serverObject.foo
changeDictionary[fooKey] = serverObject.foo
}
if localObject.bar != serverObject.bar {
localObject.foo = serverObject.bar
changeDictionary[barKey] = serverObject.bar
}
// multiply above a dozen times and for several different classes
return changeDictionary
Maybe you spotted the bug in the above, and maybe you didn’t — and that’s part of my point. I’d write this code using copy-and-paste, and then go over it visually, line-by-line, to make sure it’s right, and sometimes I’d miss something anyway.
If foo and bar are both strings, for instance, the above would compile and all would be well. Except that I’ve written a bug where localObject.foo = serverObject.bar.
Eventually I found a better way — some code that I can write once, and that can’t have the bug I wrote above. See this gist.
* * *
The solution is pretty simple. You have two objects — which may or may not be the same class but where the properties have the same names — and then loop through an array of mergeable property names. (The two objects don’t have to have the exact same list of property names. They just have to have the mergeable property names and types in common, since those are the ones we care about.)
Then there’s a method that compares the local and server objects. For each property name in the list, it gets the localValue and serverValue using valueForKey:, and then compares them (via isEqual:).
When they’re not equal, then it uses setValue:forKey: on localObject to give it the serverValue. It also adds the property name and new value to a change dictionary. (That dictionary could be useful for efficient database updating, sending notifications, etc.)
There are places this could go wrong, and where the compiler wouldn’t complain. In the gist there’s this line:
static let mergeablePropertyNames = ["dog", "cat", "zebra", "numberOfAnimals", "fedTheTigers", "attendingDoctors"]
Obviously that line has to be maintained, and it has to be true that both local and server objects have those properties and those properties have to be of the same type. Yes.
However, you’re going to notice any error at runtime pretty quickly, since you’ll get an exception — while you may not notice the localObject.foo = serverObject.bar bug from the manual version any time soon.
Best thing: you can reuse that updateLocalObjectWithServerObject method for all the various local/server object updating you need to do in all your apps.
* * *
Even though we’re writing in Swift here, the solution uses the Objective-C runtime and KVC.
KVC is both awesome and to be used sparingly. Most of the time you want to write standard code that the compiler can better check — you want to write foo.bar = true. Absolutely.
But there are those occasional critical cases where KVC creates more reliable code that’s easier to maintain, debug, and reuse. This is one of those.
