UIScrollView.contentInset is conceptually a very simple API: it extends the scrollable range beyond that implied by the
contentSize property. (The objc.io magazine has a great article on
UIScrollView that explains
contentInset in terms of simple arithmetic.) Its two main use cases are avoiding the keyboard and correctly underlapping iOS 7+’s translucent bars. But if you want to get more complicated than a navbar and a keyboard, the simple nature of
contentInset makes things difficult.
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.
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!
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.