Yesterday I wrote some code to hide the Trash location in our document picker when it’s empty. Today, I got a bug report that attempting to add or remove a cloud storage location in the document picker would now crash with an exception thrown by
UITableView. These didn’t sound all that related other than timing and both involving the document picker.
And at first, all the evidence told me they were not related. But thanks to a combination of overlapping bugs it took me over an hour, a fair bit of disassembly, and some moral support from my coworker Jake to track down the origin of the bug.
Updated: It turns out that UIKit likes to set the first responder to
nil. At that point, my technique for finding the first responder winds up returning the
UIApplication instance, which nullifies the technique. I’ve rolled back this change from our codebase; I’ll leave the blog post here, but I can’t advise anyone adopt this technique.
One of the best patterns that UIKit inherited from its older brother is the responder chain. It is a fantastic way to decouple UI controls from their targets and enables the same control to perform its function even as the user interface or controller layer changes around it.
On iOS, like on the Mac,
UIApplication plays a central role in dispatching events to the responder chain:
-[UIApplication sendAction:to:from:forEvent:] starts with the first responder and walks up the chain to find an object that can handle the provided action. But what if you just need to know whether such a responder exists, or you need to ask it further questions before you dispatch the action?
iOS 8 brings a new and welcome class to UIKit:
UIPresentationController, which reifies the presentation of view controllers in a configurable object whose lifetime can also be used to more cleanly manage auxiliary UI elements associated with that presentation.
Conceptually, popovers are a form of presentation, so they are now managed via a subclass of
UIPresentationController, logically named
UIPopoverPresentationController. Unfortunately, the actual API design surrounding this class leaves a lot to be desired.
-[UIViewController targetViewControllerForAction:sender:] method (and its related methods,
-showDetailViewController:sender:) in iOS 8 takes a clever responder chain-based approach to showing view controllers in a size-class-adaptable way.
UIViewController instances respond to
-showDetailViewController:sender:, but their implementations use
-targetViewControllerForAction:sender: to find the appropriate view controller to actually do the showing. In the case of
-showViewController:sender:, this is likely an enclosing
UINavigationController, and in the case of
-showDetailViewController:sender:, this is likely an enclosing
(I recently posted this thread to Apple’s
objc-language mailing list. I welcome feedback there or here.)
A recent Twitter conversation spurred me to think about how we use
super in Objective-C.
Recently my coworker Tom was having a hard time with converting a Mac NIB to Auto Layout. The NIB contained a split view; on the left was an instance of
OACalendarView, and on the right was a scroll view. The holding priorities of the left and right panes were 251 and 250, respectively, and the scroll view had a required width constraint of greater-than-or-equal-to 150.
For some reason, the left pane insisted on being as wide as possible, squeezing the right pane down to 150 points wide. Dragging the splitter had no effect. How do we figure this one out?
Up until three months ago, my time at the Omni Group had been spent programming solely for the Mac—I hadn’t written any iOS code professionally, and I’d only dabbled the slightest bit on the side.
That all changed when iOS 7 was announced, and I’ve now spent a solid three months as an iOS developer. For the most part, it was an easy transition; I’d picked up quite a bit of iOS knowledge peripherally, and I learned a lot more very quickly through hands-on experience. But one thing bedeviled me:
On Thursday, January 10, I gave a talk at Seattle Xcoders about Auto Layout, explaining the benefits and workings of this new technology and sharing some tips learned from our adoption of auto layout.
I’ve uploaded the slides from my talk.
I’ll upload the video once I’ve found a place to put it.
Update: Thanks to Paul Goracke of Seattle Xcoders, the video of my talk is now available as well. Unfortunately, for some reason the cursor got disassociated from the actual mouse position during the demos, and I don’t have any way to fix it. Sorry! (rdar://problem/13011198)
So WWDC 2012 was announced at early o’ clock and sold out in less than two hours. New restrictions on multiple purchases didn’t do anything to stave the ever-shortening window. As compensation for all the interested developers who won’t get to go to WWDC this year, Apple has promised to quickly post the session videos online (as they’ve done in the past few years).
Which leads me to ask: why is WWDC still worth attending? WWDC’s allure has always been the exclusive combination of three features: the sessions, the labs, and the social interaction with the worldwide Cocoa community. Now that the sessions can be gotten online mere days after the conference (and have lately been repeated locally during the Tech Talk series), and much of the community wasn’t even awake to purchase tickets, the only remaining feature of WWDC is the direct access to Apple engineers provided by the labs.
Maybe it’s time to think of a post-WWDC world. Or perhaps a world in which an event named WWDC still exists but bears no resemblance to the event we currently know.
Adding namespaces to Objective-C is a non-trivial problem. This proposal is a working draft; it may have bugs. (In particular, the definition of
@namespace blocks and the
@using directive is incomplete, but it’s analogous enough to other languages that the intent should be obvious.) This draft will certainly need updates; I welcome comments at optshiftk [at] optshiftk [dot] com.
UPDATE September 11th, 2012: You can now find this proposal on GitHub. Further development will occur there.
UPDATE April 18th, 2012: Fixed a problem with the
FwkProto example. The
@implementation directive was all sorts of screwy. Thanks to Greg Parker for catching it.