iOS Table View Cells & The Responder Chain

[open star field]

One may be tempted, when created a custom table view cell, to wire up the action of various buttons it contains to the First Responder. This is a horrible idea. Please, don’t do that.

The rational behind this is that the First Responder

… [and break] …

… [cut to a calm Carl Sagan against the Cliffs of Dover] …

The responder chain works by finding the “first responder” along a chain of objects that have opted in to this system. They can be views or controllers on iOS. The limit of the message passed along this chain is that it has exactly one parameter — the sender.

… [cut to an irritated Joe Pesci leaning against a bar] …

So, you see, as you get higher up the responder chain the less context the responder has to act on. Doing this requires an understanding of the context. If I find a UIButton tossing some message up the responder chain, documented nowhere else except in the Interface Builder UI? That sucks. Do you think I’m being funny? You’re chuckling! Yeah. It’s funny. Very funny.

… [cut to the Death Star Throne Room] …

Without the context of an action one can never satisfy the request. Simply sending a message up the responder chain that some sub-item of a view has been tapped doesn’t help make the user’s intention clear except under the most superficial or specifically co-ordinated conditions.

For each step up that chain there is an expectation of implementation that has been overly abstracted by the idea that one can simply toss this decision someplace else. Sometimes that can work. Eventually it falls apart.

Action verbs are cheap. Context is key.

PUNCH! I dare you. PUNCH! You’ve got no idea what or where to punch but, hell! PUNCH!

… [cut to the edge of the Death Star Throne Room Pitfall Railing] …

See how I set up the context?

PUSH.

Context, then action. Action without context is meaningless.