-
BlocksKit: A Rationale
Nick Paulson and Tristan O’Tierney, both by far more skilled than myself, introduced BlockKit today. I can’t even pretend to be offended by the similarity to BlocksKit: the things they’ve come up with are brilliant, and get at UIKit and CoreGraphics quite a bit better than we do. (Though, the large-egoed student whines, I would’ve liked to trend on GitHub, too.)
A number of things were introduced by them that are on my internal roadmap for BlocksKit. So, we will soldier on. BlocksKit is a fundamentally open project, and it will continue to expand. I’m going to go ahead, adding and adapting things that are on my list for development, such as the NSURLConnection functionality Igor Evsukov added this morning.
For driving future development of BlocksKit, I set forth the following guidelines for what BlocksKit entails as a project.
Conciseness is key.
BlocksKit isn’t meant to be something that you should need to go through the documentation to figure out (but, unlike many other Foundation extensions, we have documentation!). While many of its operations are just shorter versions of provided Apple methods, this is intentional. Objective-C programming is already pretty easy, and I want BlocksKit to make that easier. No guessing at method names or having to rely on autocompletion to get you there. This will take some work with the more in-depth functionalities in, for example, NSURLConnection, or bringing in something like the the awesome-but-gruesome UIView swizzling hackery done in BlockKit.
The idea of BlocksKit isn’t to move all of your UI interaction code into viewDidLoad. It might just happen that way, but it’s not the goal. There is a balance to be had between making everything a delegate and making everything a block. A UITableViewDataSource utility will not make its way into BlocksKit for a variety of reasons, most of them involving the sheer number of methods required for a proper table view. Miss one and you’re in trouble; protocols make sure you have an implementation that is correct.
Of course, I’ll sheepishly point out that I have a fork of YXModelTableView that does add all the fancy block-based model tables to UITableView. Working on that made it clear to me that that is not what BlocksKit is for.
Delegates aren’t dead.
There is still a good place for delegation in Objective-C. While they cover a good bit of the same bases as blocks, block handlers are not replacements for delegation. Blocks are good for shortening up more common uses of delegates. The logic of dealing with those systems isn’t very difficult. That’s what BlocksKit is for. Likewise, the collection additions take some of the guesswork out of sorting through arrays and dictionaries. By and large, BlocksKit delegate replacement is great for classes where the delegates don’t have too many methods. Those are what are already implemented with, for example, UIWebView.
Having block handlers account for large delegates like NSURLConnectionDelegate and UITableViewDataSource/UITableViewDataSource don’t work for us because they save very little actual code. In fact, this is where the downside to blocks comes out: it’s just a sea of curly braces.
I’ll talk more about UITableView below, but there’s also a reason why I’m keeping (with some modification) Igor’s NSURLConnection additions. His unique implementation allows for simultaneous use of the classic delegation and new delegation - while fixing the annoying part of NSURLConnection where the delegate has to be set in the init method. His method is so clever that I might consider using it in the future with other classes. Though BlocksKit as it is still has block handlers for authentication challenges, I plan on removing them for the pure reason that they save no code at all and, in practicality, make these situations more difficult to program for.
No new public classes.
Whether it’s by swizzling or associated objects, BlocksKit will not create new macros, functions, methods, or classes to use. We purely extend other classes. This doesn’t mean BlocksKit has no classes of it’s own, but it means that you, our user, doesn’t have to learn to use any new classes. We abide by Apple’s naming conventions in order to be concise and, ultimately, more functional for you.
If you need to still subclass something (or utilize someone else’s subclass) to use blocks functionality, something is wrong - it’s wasteful and unnecessary when there are almost always better ways to do it. If your code is all bunched into one method, something is wrong - that’s against the design of Objective-C and is, quite frankly, very ugly. Methods shouldn’t be very long, and blocks shouldn’t be more than a few lines.
There is a fine line between the kind of code that should be within blocks and be within methods.
If you have a block that is long enough to be its own method, it should be. If a delegate callback is only a handful of lines or merely daisy-chains to another method -then you should be using a block. And that’s what BlocksKit (with the ‘s’, I suppose I’ll be saying from now on) is for.
