-
Changes Coming in BlocksKit 1.0
Just over seven months ago, I made the first commit to a little project I called BlocksKit. Depending on what method you’re using to read this post, the announcement might be just below you; a prolific blogger I am not. I am truly proud of the outpouring of support I’ve seen. BlocksKit is going places: commercial apps, trending repository lists, blogs the Internet over, university courses, and package managers. And now, over half a year on, BlocksKit is finally making the transition towards the big one-oh.
I’ll accept my trophy now
People like Igor Evsukov have helped us move from “just” array categories to truly useful delegate alternatives. Indispensable in this move towards 1.0 has been Alexsander Akers; in fact, he’s almost completely what this post is about. Hopefully, he won’t let it go to his head, landing on this massively popular blog and all.
Zen and the Art of Swizzling
I’ve spoken before about the overlap between delegates and block handlers, and where BlocksKit falls on that continuum. For a while now, BlocksKit’s implementation of block handlers on classes was a piecemeal mess of custom properties, delegate emulation, just generally a huge ordeal. Thanks to Alex’s brilliant work, we’ve managed to replicate what BlocksKit does in an automated way without impeding on classes themselves. Of course, it’s still a mess of swizzling, but case it’s a manageable and predictable one.
Alex and I have worked hard together to make the move in BlocksKit 1.0 and have every bit of parity with current BlocksKit. We no longer clash with
self.delegate = selfbecause we dynamically outsource a delegate implementation to an invisible, safe object. Classes that implement normal delegation also continue to work flawlessly. There will be syntax changes, however. The syntax of block handlers must match that of the delegate it is substituting. For example, BlocksKit provides thedidStartLoadBlockon UIWebView, which parallels the-webViewDidStartLoad:UIWebViewDelegate method. The block used to have the syntax ofvoid(^)(void), used like^(void){ }. Because we must use the delegate method in its entirety, the block type is nowvoid(^)(UIWebView *), written as^(UIWebView *view){ }. This is an easy change to make that massively helps in preventing retain cycles under ARC.Other minor changes
- BlocksKit 1.0 will remove all previously deprecated methods to start out fresh in its first stable release
- 1.0 will also include better safety checks for blocks and will fail predictably instead of crashing in random places.
- A new collection method similar to
-each:, called-apply:, has been introduced. Enumeration of objects will be done concurrently. The order of block execution under-apply:is not predictable; the block will not always be called in the same order as objects (or indexes) exist in the collection, and will not necessarily be executed on the same thread. - Some minor methods are renamed to be more consistent with Apple conventions, i.e.
+sheetWithTitle:is now+actionSheetWithTitle:. - UIActionSheet and UIAlertView can now also classical delegation as well as block handlers.
- On UIView, the family of whenTouchedDown block setters is now a family of onTouchDownBlock properties to better clarify their usage.
The changes planned for 1.0 will be coming soon to a beta release. Please do both us and yourselves a favor; give it a try before it’s released and help us iron out any issues so that an errant
git pullin the future won’t mess up your entire codebase. -
-
pandamonia liked this
-
zwaldowski posted this
-