Over at the Big Nerd Ranch blog, my friend Mark Dalrymple continues his "Inside the Bracket" series with an article on practical uses of Objective-C's run time introspection.
Last time you saw the parts of the Objective-C runtime API that let you query a bunch of the metadata the compiler keeps around once it’s done building your project. Like most discussions of API, it was pretty abstract. “Look at all the pretty tools! Ooh, we can print out Lists of Stuff! Isn’t that amazing!”
This time around is an actual application of this API for Great Justice. I was working on a client project that consumed blobs of JSON data from a third-party web service.
Converting JSON to Objective-C objects is fraught with some peril, but with the code Mark presents it becomes a lot safer.
Mark's code, incidentally, is an improved version of some code I wrote and discussed on Cocoa is My Girlfriend. Mark's version is better, though.
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…
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.…