This is a topic that I have considered writing about for some time now; in fact, I have a draft post from 2011, right after I finally decided to start using blocks. That post touched on a few areas of nuance in block memory management, but it basically all boiled down to: Memory Management and Blocks Can Be Tricky. I thought most of its talking points were tired, old news at this point — it seems I was wrong.

Last night I saw a flurry of tweets linking to a blog post about NSNotificationCenter’s block based API being ‘harmful’. I use this API fairly heavily, and was interested to see what kind of trouble I was in for. Drew Crawford does a great job of providing a narrative very similar to my first WTF moments from the early days of familiarizing myself with blocks. That said, I feel like the article’s title would be more accurate as: NSNotificationCenter with blocks considered harmful, unless you understand how self is captured.

Drew did a great job of putting together a simple test to illustrate that his notifications were firing more often than he’d expect (seriously, I love the test driven breakdown of the problem), and made the project available on a GitHub repo. Unfortunately, you have to wade through 700 words, all setting the stage for the takedown of the block based API, before it’s made clear that the culprit is actually a bug in the code that removes his block as a notification center observer. And this is where we veer a bit off course.

Blocks Hate Selfies

Capturing self is a fairly well known “sharp corner” of using blocks. Avoiding it is also generally well understood. I have this defined as a code snippet, and use it regularly.

__weak typeof(self) wSelf = self

I thought the dangers of directly accessing ivars in a block was also well understood; but possibly not. Here’s a reminder: ^{ _myIvar; }; is actually like writing ^{ self->_myIvar; };. In this form, it’s easy to see why self is captured/retained. Is _myIvar an object? Guess what, the block doesn’t even retain it at all, just self.

Harmful API

I didn’t set out to write this as a takedown piece, but as a correction of facts, and encouragement of philosophy. Drew plainly states that -[NSNotificationCenter addObserverForName:object:queue:usingBlock:] is banned from his codebases, but to get there, had first had to cite a litany of tenuously linked data points. Sometimes documentation is wrong, file a bug report. Macros are sometimes tricky, blog about them. New syntax is sometimes confusing, learn about it.

Blocks can be hard; I suggest really learning about their memory implications, rather than dismiss API which uses them. Lots of API can be hard to use, LOTS of API does bad things when used incorrectly. Hell, even BOOL has some gotchas.

Remember that the root of this discussion was the importance of deregistering an observer, which is still a problem without block based notifications! Admittedly, retain loops can be challenging to debug. You know where else I see a lot of accidental retain loops? Classes implementing a delegate. I’ve seen many (mostly new) cocoa developers accidentally cause retain loops when they retain their delegate, but so far I haven’t seen anyone calling for a banishment of the delegate pattern.

Don’t Run With Knives

Since they were introduced, I’ve been commenting on (and bitten by) the vast amount of rope that blocks provide a developer with. But try to understand the common patterns and pitfalls of the tools!

With blocks, always tread lightly with self. With blocks that have a lifetime scoped to their parent’s lifetime tread really fucking lightly with self. Stop thinking about your long lived blocks as snippets of code, and start thinking of them as 3rd party objects — apply memory management rules accordingly.

I want to love UICollectionView, I really do. But it continues to give me reasons to complain about it instead. I was working on some iOS 7-ish UI in our yet-to-be-announced project and trying to use the backgroundView property of a few collection views. To make the app feel more “alive”, I started occasionally updating this backgroundView to better reflect the current state of the app. Except, it just wasn’t working!

I went round and round for quite some time trying to figure out where my code was broken; then ultimately concluded that setting the backgroundView property simply would not be reflected once it had been set a single time. If I did something like the following, the result would always be a collection view with a red background, not the blue background I was expecting.

UIView *redView = [UIView new];
redView.backgroundColor = [UIColor redColor];
collectionView.backgroundView = redView;

UIView *blueView = [UIView new];
blueView.backgroundColor = [UIColor blueColor];
collectionView.backgroundView = blueView;

I had accepted that backgroundView was broken, and planned to just put my own view behind the collection view (one that did what I asked it to), but I couldn’t get past wondering how this property could possibly be so broken. In my initial Googling, I had stumbled on an old GitHub issue for PSTCollectionView; the issue suggested that the backgroundView property had always acted odd when adding the provided view to the view hierarchy. How could this property just not work!?

The Big Reveal

I wish could say I did this part on purpose. I had Reveal open from some previous troubleshooting (Have you bought Reveal yet? If you haven’t, you should — it’s insanely useful), and lo and behold, right there in the exploded view I could see all the background views I had been adding. They were all just in the wrong place! The UICollectionView had been adding my provided backgroundView to the view hierarchy, but was never removing the old one.

Given our code above, the results in Reveal might look something like this:

Hilariously, if not completely expected, the collection view will stack as many backgroundViews, in reverse order, as you are willing to give it.

The Solution

Frankly, I think the best solution is to just ignore the backgroundView property all together. Instead, make the collection view’s background clear, and implement your own backgroundView; just throw a view behind the collection view.

It turns out, not unsurprisingly, the backgroundView property is workable as long as you manually remove it from it’s superview before setting it to a new value. Modifying our code from above, the following works as expected:

UIView *redView = [UIView new];
redView.backgroundColor = [UIColor redColor];
collectionView.backgroundView = redView;

UIView *blueView = [UIView new];
blueView.backgroundColor = [UIColor blueColor];
[collectionView.backgroundView removeFromSuperview];
collectionView.backgroundView = blueView;

But wait, there’s more

Just in case you aren’t yet convinced that backgroundView meets the criteria for horribly broken, I have one more ridiculous example to provide. In preparation for this blog post and a bug report for Apple, I put together a sample project. It simply iterates over a short array of colors and creates colored views to assign as a backgroundView. Initially, I added this code to my viewDidLoad method, and my collection view was oddly — empty.

Of course, once again Reveal made this easy to investigate. And while I still have no hypothesis for how exactly the collection view managed to put itself in this state, you can see in the screenshot below that the cells have somehow been positioned behind my initial backgroundView.

- (void)viewDidLoad
{
    [super viewDidLoad];
	
	NSArray *colors = @[[UIColor redColor],
						[UIColor blueColor],
						[UIColor greenColor],
						[UIColor orangeColor]];
	
	for (UIColor *color in colors) {
		UIView *view = [[UIView alloc] init];
		view.backgroundColor = color;
		self.collectionView.backgroundView = view;
	}
}

Update: View Controller transitions are terribly broken in landscape. I’d advise avoiding this if you need anything other than portrait transitions.

Few will debate the divisiveness of the aesthetics of iOS 7, but what many seem to have only just started talking about is just how API rich this latest release is. I generally hesitate to write about brand new API (it’s just too hard to do it authoritatively without having spent real time with it) but the new flexibility in view controller transition animations is somewhat near and dear to Joel and I.

If you’ve spent any time in the past writing code to do custom animations between view controllers, you likely already know how challenging it was to keep code cleanly isolated; and even when proper encapsulation achieved, there was the tendency towards whole separate tracks of willDisplay/didDisplay logic in parallel with the standard UIViewController flow. The encapsulation of the new UIViewControllerAnimatedTransitioning mechanism is so clean and pluggable that I hope (and expect) to see transition animators popping up all over GitHub. We’d like to help kick off this trend. (skip right to the code)

If you haven’t read up on the new transition API, I recommend first taking a look at Ash Furrow‘s recent post, Custom UIViewController Transitions, it’s a fantastic nuts and bolts guide to quickly getting moving with custom transitions.

SMLBookshelfTransitionAnimator

SMLBookshelfTransitionAnimator provides an easy to use “bookshelf” animation between two view controllers, similar to the well known transition in iBooks. The bulk of the animation code was written by Joel, originally as part of a redesign of my very first (and very old) App Store app, Peg Jump. Truth be told, I’m not even sure this rotating 3D box is a style we’ll see much of in the post iOS 7 world, but it still fits in nicely with a heavily stylized game.

Admittedly, the Core Graphics animation to achieve this effect isn’t the most complex animation in the world. All the relevant views are added to a CATransformLayer with transforms applied such that they are positioned in the form of a “box”, the transform layer is then animated 180° in 3D space. The original code was not terribly elegant, it ripped the backing CALayer out of the UIView for the front and back controllers. This animated superbly, but required some terribly ugly post-animation cleanup. Fortunately, iOS 7 provides some great new view hierarchy rendering API and SMLBookshelfTransitionAnimator uses these to provide the textures for the various sides of the animated bookshelf; no more view hierarchy patching necessary.

Easy Setup

There’s some boilerplate setup required to get the transition animator passed into UIKit (read Ash Furrow’s blog post if you aren’t familiar), but setting up the animator couldn’t be simpler. SMLBookshelfTransitionAnimator provides sensible defaults, you really only need to provide it with views for the left and right sides.

SMLBookshelfTransitionAnimator *animator = [[SMLBookshelfTransitionAnimator alloc] init];
animator.leftView = [[UIImageView alloc] initWithImage:[UIImage imageNamed:@"left.jpg"]];
animator.rightView = [[UIImageView alloc] initWithImage:[UIImage imageNamed:@"right.jpg"]];
animator.dismissing = YES; // Required to automatically handle proper side view presentation

Options, we got em

SMLBookshelfTransitionAnimator allows customization of it’s duration, depth, perspective and rotation direction. Because we often create one off animator instances for presenting and dismissing view controllers, it also provides a couple of conveniences for automatically swapping the left and right sides to help aid in the appearance of a seamless, stateful, 3D transition.

As always, SMLBookshelfTransition is hosted over at the Spaceman Labs GitHub repo; and of course, feedback, suggestions, and pull requests are encouraged!