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 .mom or .momd suitable 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.
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 mogenerator uses momcom code to compile the model directly when possible.
momdec is a command-line tool for Mac OS X that takes a compiled Core Data model and decompiles it to produce an equivalent xcdatamodel or xcdatamodeld suitable for use in Xcode. The resulting model file can also be used with mogenerator to produce source code files for Core Data entities which have custom subclasses.
My latest open source project. A compiled managed object model contains enough information to reconstruct an equivalent editable model file. So, I thought, wouldn't it be interesting to actually do that?
Today I'm continuing my series of iCloud/Core Data-related posts with a discussion of duplicate data, how and why it occurs, and what you can do about it in your apps. As with my previous post in this series, today I'm sticking to how things are supposed to work and sometimes actually do. The problem of duplicate data isn't actually specific to iCloud. It can happen in any case where people might create data on different devices and where your app wants to sync that data between the devices. Some sync solutions may try to solve the problem for you, but iCloud does not. Why are Duplicates Possible? In short: Core Data doesn't care if you create multiple objects with identical data fields. You can, if you like, create any number of instances…
iOSDevCamp is an informal un-conference where anyone is welcome and encouraged to present about anything relevant to iOS development. Colorado has a fantastic iOS developer community and these events are a great place to meet people, learn things, and have fun.
Three weeks from today! This is the fourth annual event in Colorado Springs. We held the first one on April 3, 2010, so we dubbed it iPadDevCamp since that was the day the first iPads shipped.
These events are great fun and highly informative. I'll be there (I ought to be, given how much of the planning I do), as will a few other people whose names you might recognize.
If you're in Colorado or would like to be, sign up now! Space is limited (seriously)!
As promised, I'm going to be doing a number posts on using iCloud with Core Data. I'm not sure how many there will be, I'll keep going as long as it takes. Today I'm starting off with some things that, while not actually bugs, may catch a developer off guard. In this post I'm sticking to how iCloud is designed to work, and not getting into the questions of how and when it doesn't work. Some of this is covered here and there in Apple's docs, but I haven't seen it all spelled out. With luck this will save you some trial and error. What have you done for my data lately? Most of the information from Apple covers how to use iCloud in a new application. What if you want to add iCloud to an existing application that already uses Core Data? First…