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 just sent an e-mail to Tim Cook about his company’s decision to include a series of Christian holidays on their built-in “U.S. Holidays” calendar, and to configure them with alerts to ensure their visibility:
If you’re going to WWDC, and prefer to avoid chain restaurants, Irish pubs, and Starbucks coffee, I’ve assembled a Foursquare list of personal recommendations. I might add to this list over time, so saving the list to your own Foursquare account will keep it up to date.
And if I personally know you, please friend me on Foursquare and share your suggestions with me. I’ll add your recommendations to my list of suggestions from others!
(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.
Here’s the letter I just sent to America’s Test Kitchen, informing them of why I canceled my trial membership and my complete lack of faith in their offerings.
The documentation for
+[CATransaction flush] is woefully inadequate. It spends one sentence on providing an incomplete description of the method’s effects, and two subsequent paragraphs describing when the framework automatically calls this method.
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?