I came across a new and interesting open source embeddable web server written in Objective-C for Mac and iOS apps called Barista. It’s inspired by the Express web application framework for Node.js and allows you to compose a processing pipeline by connecting middleware components that operate on the HTTP requests and responses being handled by the server. The framework is being developed by Steve Streza, formerly of Pocket, now gone indie and having also recently released Ohai. It’s early days for the project, could use some help, but is definitely interesting and worth a look.
Jon Hocking recently released a simple category on NSDate that generates relative timestamps such as “3 hours ago” or “2 days ago” from an NSDate instance.
The code is available on GitHub at jonhocking/PrettyTimestamp and is available as a CocoaPod as well.
I’ve put together an example project to demo how the code works at stevenhuey/PrettyDates. It makes use of CocoaPods to manage dependencies so make sure to use the .xcworkspace file and run:
before trying to build and run the app.
When you save yourself some time generating some nice relative timestamps in your next app make sure give @jonhocking a mention on Twitter.
Photo by MarcProudfoot, http://www.flickr.com/photos/progressionuk/8395619662/
Migrating between Core Data models is simple – until you need to make changes more complex than adding an entity or attribute. A migration step like deriving data from two columns for a new attribute (such as combining firstName and lastName into normalizedName for faster searches) not only requires a custom migration policy, but prevents a simple invocation of lightweight migration between other models.
- the migration from model 1 to 2 only adds a new attribute, and can therefore use lightweight migration
- the migration from model 2 to 3 requires a custom migration class
- then migrating from model 1 to 3 using a single call to the Core Data API is impossible without a custom migration class from 1 to 3
Writing (n – 1) migrations when creating your nth model is clearly untenable. (more…)
Photo by Gunther Wegner, http://www.flickr.com/photos/gwegner/8157955351
When implementing view state preservation in an iOS app, it’s important to handle the case of restoring state after an app upgrade. The iOS state preservation APIs automatically encode the restoration IDs of view controllers in order to recreate those controllers after an app restart.
However, if in the normal course of developing a new version of the app those restoration IDs are changed or removed, your users will be greeted with multiple app crashes on startup after upgrading. The console log will show an error message like:
‘NSInvalidArgumentException’, reason: ‘Storyboard doesn’t contain a view controller with identifier ‘SomeController’
The state restoration APIs were not written to quietly ignore errors, but at least – after a few crashes in a row – iOS will delete the stored state and allow the app a fresh start.
It’s no secret that Apple’s implementation of iCloud syncing for Core Data has issues. Check out episode 12 of Debug for a great discussion and check out the show notes for a number of links to blogs that go into even more detail.
With WWDC around the corner, we can hope for some fixes in iOS 7 and OS X 10.9, but until then a few interesting alternatives have been released. Here’s a look at four of the most promising frameworks for syncing your app’s data.