Learning iPad Programming, 2nd edition, by the excellent Kirby Turner and myself, is finally available. This project has been in the works for a while and now it's finally actually shipping and in print and stuff instead of just being preorderable. If you order now you can probably have your copy before I get mine. (It's also available in electronic formats for Kindle and iBooks and as a PDF).
Not many books have a single project that lives and evolves through the entire narrative. The reason not many books do this is because it is difficult to do well. Important toolkit features get shoehorned in weird places because the author didn’t do enough up-front design time. This book, though, takes you from design, to a prototype, to the Real Deal. And then it goes further.
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…
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.…
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?