Say Hello To BlocksKit

While working on and being generally OCD with my branch of PSFoundation, I came upon a revelation that most Objective-C developers hit at some point in their experiences: blocks are flipping amazing. However, the only issue with blocks to someone obnoxiously obsessive like me is that they aren’t everywhere.

Today I’m introducing BlocksKit, which gathers a number of blocks-based extensions for Foundation and UIKit that I’ve stumbled upon over the last couple of weeks. These class extensions are open source and extensively documented. The (surprisingly simple) code is available on my GitHub. Online documentation is available right here on this site, and you can add a documentation set to Xcode 4 using this feed URL.

Some might not really know what blocks are. Like I said, Apple doesn’t have them ubiquitous quite yet, and the places where it is used are abstracted away by Xcode 4 autocompletion. Blocks are a language extension to C, C++, Objective-C, and Objective-C++ introduced by Apple in 2009 with the release of Mac OS X Snow Leopard. Blocks are, essentially, C functions with the added benefits of “absorbing” the context of whatever function/selector it is executed in and relatively easy storage and use as a variable.

Though the two aren’t completely hand-in-hand, blocks are crucial to the design and implementation of Grand Central Dispatch, which also was introduced in Snow Leopard (and iOS 4.0). GCD is, for all intents and purposes, a library that makes multithreading easy - even downright simple - to execute on multicore processors. The implementation of blocks in the Objective-C runtime makes use of GCD, but blocks do not otherwise depend on GCD. The most obvious upshot of blocks on Mac and iOS is that it’s all asynchronous processing. This allows code to be more flexible, faster, and generally won’t responsive, as you have the potential to not worry about the process freezing of heavily synchronous code.

This move is of huge benefit to iOS, where the delegation pattern and callback design can sometimes be slower, if not just uglier to code with. UIKit doesn’t natively support bindings like AppKit does, and offers few openings for OS X-like KVO. We’re essentially left with just the target/selector form of messaging. While this isn’t necessarily bad or by any means bad design, it’s where Objective-C got a bad reputation for being excessively verbose when outside developers tried their hand at iOS development.

Lots of useless code exists in Objective-C classes, as far as I can see, for holding onto references (ivars or properties) for things that are usually only needed once. Tons of UIGestureRecognizer code, including Apple’s samples, keep a reference around in the form of an ivar just to verify things later on. If this wasn’t necessary, a UIGestureRecognizer could be instantiated, configured, added to a view, and released in an initializer or awakeFromNib:/viewDidLoad:.

iOS 4.0 introduced a number of block mechanisms, most notably for things like much speedier UIView animations. Ideally, a block mechanism should be available everywhere where you would find:

• a callback-based delegate mechanism (UIAlertView)
• a target/selector pattern is used (UIControl, UIGestureRecognizer)
• a common, repeatable, but not contextual utility (NSArray looping)
• an arbitrary selector must be used (NSObject -performSelector:withDelay:)

BlocksKit was developed with this in mind, and I’m constantly trying to imagine better and more ways to throw in blocks. I encourage you to check it out and maybe even add some code to it yourself.

1 year ago / 1 note