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.

The Definitive Ad Campaign

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 crappy 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 asshole. A stubborn one. But a driven, creative, wonderful one. He will be missed, but not just for that enigmatic paternal influence. But because there’s nobody else like him.

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 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.

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.

Download it here.

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.

Okay, yes, there is a new CSS property, [ilc]-webkit-overflow-scrolling[/ilc]. It exists. In the grand scheme of things, it’s minor, which is why I find it fit to mention. However, for web apps on mobile devices, it’s nothing short of revolutionary. While I don’t consider this here blog a webapp (he types while pointing sheepishly at your “Add To Home Screen” button), I do think it’s an important enough change to demonstrate. *cough* Because I can. *cough*

Of course, if you’re going to be OCD like me and say, well, fine, let’s make the whole damn site scrollable, there’s the ever-so-minor of anybody using a mobile device that doesn’t have native overflow scroll support, like any other iOS device on the planet. And, from what I hear, Android support for it is spotty. (I’ll refrain from making a snarky joke about that.) Before this property came out, the world was abuzz with a tiny JavaScript sample by Joe Hewitt (of Facebook fame; would you call it fame? I just recognize his name) called Scrollability. After 4 years, it finally gets an inertial scrolling algorithm right.

I decided to pair these up, both for use in general and here on Dizzy Technology. I’ve made an approximately 15-line change that cancels all the Scrollability stuff if you’re on a platform that supports WebKit overflow scrolling. The results are really cool, and you likely already see them if you’re reading this post. I encourage you to try the site on an iPad, because it’s pretty cool. It’s still pretty neat on a browser without overlay scrolling, too.

The code changes to Scrollability are available at my GitHub. I would also link to a code sample, but this site does it really well (I’m OCD about web semantics, too!); just pull it up in Web Inspector.

In Xcode 4, we got another obnoxious facet to this issue: auto completion, or, in Apple Magic™ terms, Code Sense. Long story short, Code Sense does not like external headers. It really doesn’t. Sometimes it just won’t index those external headers, making the experience for using, say, BlocksKit incredibly annoying. In working on PSFoundation, I ran into a much bigger issue where Xcode decides it just won’t highlight your code at all.

As most can guess, when things are a crapshoot like this, actually being able to compile and use your code was the primary issue over getting autocomplete to work. After weeks of investigation and toying around, I feel like I’ve worked things out.

The most common way to get headers working (without autocompletion) is to have the headers install to a named folder instead of /usr/local/include, so, properly: /Users/zwaldowski/Library/Developer/Xcode/DerivedData/Filemator-<udid>/Build/Products/Debug-iphonesimulator/PSFoundation. A good way to get headers working (with autocompletion, but not always compiling properly) is to jump out of the proper Xcode scheme, e.g., Build/Products/PSFoundation.

Three20 does something like this, and I’ve followed them: in your static library target, set both “Private Headers Folder Path” and “Public Headers Folder Path” to "/../$(PRODUCT_NAME)/$(PRODUCT_NAME)". Now, instruct your users to set their set their header search path to "$(BUILT_PRODUCTS_DIR)/../--project name--". From then on, they use #import "--project name--/--main header--.h", like #import "PSFoundation/PSFoundation.h. Their code will light up like a Christmas tree, things will autocomplete, and it will build.

I had always wanted to have my own company; I suppose its “in the blood.”  …  It was always in the back of my mind that for any technology shift you’d need tools to help out.  I’m really a tools guy, though we tend to call them “apps” nowadays.  I was faced with the decision of continuing to work with the great people on my team on a clearly high impact project, living with the “what if” syndrome, or trying to forge my own path.  ”Regret Minimization” is what should win out in life, so it did.

“Jumping ship,” so to speak, for a startup isn’t always cast in a positive light by society or by people on the Internet.  We in general are very corporation-biased, and a lot of us online take something like leaving Google (after being talented enough to get there in the first place) as some kind of arrogant statement or something against the company itself.  It means a lot to hear positive things about the “independent” lifestyle.

This may or may not be me testing my new linked list system.  Shh.

✔

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.

For web development, I shuffle between Photoshop and Coda. For iOS development, I have an iPhone and iPad usable for testing. I always run the latest and greatest OS available (beta too), preferably jailbroken.

Ask me anything!

Ask me anything