Over the past month or so I've been diving into Swift, after many years of working with Objective-C on Macs and iOS. It's been a change but, gradually, I'm learning the Swift way of doing things. On the way I've run into a few bumps in the road when dealing with Core Data, and I thought would be useful to share how I got past them. Xcode Generated Subclasses Considered Harmful This is the main impetus for this post. Most other stuff I would expect people to work around eventually, but this one is kind of big. Xcode's generated NSManagedObject subclasses are limited but useful in their own way. If you don't need much, they'll do. Everyone else would use mogenerator. That's if you're using Objective-C, though. With Swift there's a decent…read more →
Category Archives: Core Data
This week was DBX, Dropbox's first ever developer conference. The big news as far as I'm concerned is their new Datastore API. In a break from their file-oriented past, Dropbox now has an API for syncing structured data between devices. I've long been a happy Dropbox user and I've lately been a frustrated iCloud developer. So the question is, should I care? Should you? Some of the hype has suggested that the new API is an "iCloud killer". As I've previously discussed, the term "iCloud" covers a lot of ground. Some of it, like file syncing, Dropbox already does. The new API is being compared to Core Data's iCloud integration, hence my interest. Here I'm going to run through the Datastore API with an eye toward seeing how it compares to…read more →
In this latest installment of my iCloud series I'll be taking a look at real world iCloud. Not in the sense of how you should write code to make effective use of iCloud, but in the sense of finding out how people are actually using it in real shipping apps. This was one of my primary purposes in writing momdec, my Core Data model decompiler, and I'll use it here to see what turns up. I included a rough date in the title of this post because I hope it will be worth revisiting one day. Who's using iCloud with Core Data? Possibly, some apps you already have are already using iCloud with Core Data in at least a limited sense. You could look in Settings (on iOS) or System Preferences (on Mac OS X) and try to guess which apps are using this…read more →
In today's installment of my continuing series on using iCloud with Core Data I'm going to discuss how factors beyond your control may render iCloud unusable, even if everything is working normally. Even if everything is working correctly, the current API can still require complex workarounds to get decent app performance. Through this, keep in mind that as with my previous post, I'm sticking to how the API is designed to work in the absence of bugs in the implementation. Bringing up iCloud with Core Data The basic approach to getting Core Data working with iCloud is something like: When you create your Core Data stack, tell it where to save data in iCloud. Listen for incoming change notifications and update your app to reflect new data.…read more →
From the README on github:
momcom is a command-line tool for Mac OS X that takes an uncompiled Core Data model created with Xcode and compiles it to produce a compiled
.momdsuitable for use at run time.
Please note that momcom is experimental. Although it is intended to be at least as as functional as compiling a data model using Xcode's built-in model compiler, it is not mature enough to recommend as a replacement. It was written mostly as an experiement to see if it could be done.
After writing momdec I realized I could probably compile models as well as decompile them. So, I wrote some code to do so. Twitter comments by John "Wolf" Rentzsch about how hard it might be may have spurred me on a bit. The code also fixes a bug I found in Xcode's model compiler (rdar://problem/13677527 and http://openradar.appspot.com/radar?id=2948402).
Fixing a bug wasn't the real reason, though. Once I realized this was probably possible, I had to find out. It was!
I also added a fork of mogenerator that uses
momcom's internal classes.
mogenerator normally uses Xcode's model compiler to get a working model and then uses that to generate class files. In this fork
momcom code to compile the model directly when possible.