-
BlocksKit 1.0.0 Released
The first release of BlocksKit out of beta, version 1.0.0, is now available on GitHub.
- Get the framework.
- View the source.
- Integrate it using CocoaPods.
- View the documentation.
If you are upgrading from any previous version of BlocksKit, review my previous post for API changes in this release.
Thanks once again to the community for their support. I look forward to seeing all the amazing things produced using BlocksKit.
-
Changes Coming in BlocksKit 1.0
I’ll accept my trophy now
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.
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. -
–Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes.
The ones who see things differently. They’re not fond of rules. And they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them.
About the only thing you can’t do is ignore them. Because they change things. They invent. They imagine. They heal. They explore. They create. They inspire. They push the human race forward.
Maybe they have to be crazy.
How else can you stare at an empty canvas and see a work of art? Or sit in silence and hear a song that’s never been written? Or gaze at a red planet and see a laboratory on wheels?
We make tools for these kinds of people.
While some see them as the crazy ones, we see genius. Because the people who are crazy enough to think they can change the world, are the ones who do.
It’s a creedo, if nothing else. It is an idea, a love of the intelligent, of the rational, of the sane. It is the audacity to keep hoping past hope, when the chips are down and when you’re out of the game. It is the drive, the stubbornness, that keeps us pushing ahead, time after time. As an industry. As a society. As a race. As a planet.
I’m a terrible blogger, probably a mediocre coder, but hell if I’m not opinionated. Steve Jobs was a visionary. If not for him, the computer industry would be nothing like it is today. Nothing. He was an terrible person. A stubborn one. But a driven, creative, wonderful one. He will be missed, but not just for that enigmatic, paternal, dictatorial influence. But because there’s nobody else like him.
-
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.
-
Make Old Apps Roar on Lion with FullSteam →
A friend and I were discussing the fullscreen feature in OS X Lion. Despite what many have said, we came to the conclusion that it is, in fact, useful; it’s just a different take on the Spaces mechanism, that uses less physical desktop space on the whole.
Games on OS X have often glitchy handling of their fullscreen status, usually due to the previously-poor handling the OS did of it. There’s pop-in of windows, losing your game, not having the game in Exposé or Mission Control, and so on. The one true solution to this is in Lion, which handles fullscreen apps handle perfectly. It’s great. But, sadly, most developers (if they’re even still maintaining the app) won’t do it for a long time. So, I wrote FullSteam. It’s a simple hack that kindly tells and app to shut up and go fullscreen, natively, beautifully, and just a little bit sexily (that’s a joke, for newcomers to my writing style).
Simply download the DMG and follow the 2-step instructions on it, which involve clicking, dragging, and double-clicking. Really difficult stuff.
Currently, the only apps supported by FullSteam are Source games (Half-Life 2, Portal 2, L4D, etc.) and Minecraft. No, it currently doesn’t do Steam, but who can give up such a punny name? Adding support for other apps is trivial.
If you know one you’d like to add, get the bundle identifier (right-click app, Show Package Contents, Info.plist, CFBundleIdentifier) or the executable name (Show Package Contents, MacOS, name of the hacky-looking black boxy thing). Tweet me @zwaldowski or communicate with me in some other fashion. For the more technical folk, this code is open source! Find it on GitHub.
