Overriding selectable area of UITableViewCell?

Question

I'm trying to avoid putting a button in my UITableViewCell subclass so that I don't unnecessarily lag up the scrolling speed.

The button would push another view onto the navigation stack.

I figured since UITableView already has built-in and optimized methods for managing this, that simply limiting the touchable area of my cells would be the easiest and most effective way of achieving my goal.

I really have no idea how I would implement something like this. I have a feeling I would have to override pointInside:withEvent: or hitTest:withEvent:, but I'm not sure how. Managing touchEvents and the UIResponder stuff still escapes me.

So my question is ultimately, in my rootViewController, how would I implement that selecting a row will only work at lets say 220,10,40,40 ?

Thanks!

Answer 1

A UITableViewCell should have a normal selection style(i.e. not UITableViewCellSelectionStyleNone), generally speaking. You shouldn't have buttons on cells that you are reusing an arbitrary number of times.

If you're using a lot of UIButtons in your UITableView, you may want to rethink how your UI is designed.

You can't easily (to my knowledge) change "selectable" parts of a cell - the whole cell must be selectable no matter what(you can set the style to no selection, but you'll still recieve touch updates).

Answer 2

The behavior you're describing sounds like a job for UITableViewCellAccessoryDetailDisclosureButton, actually. If you're going to be pushing another view onto the stack but don't want to do that when the user selects the cell proper, use a detail disclosure button to maximize your consistency with existing UI convention. It's hard to say without more information.

As for doing the work necessary to detect touches in a sub-region, that may be more trouble than it's worth. True, adding subviews to a cell incurs a compositing cost but if you're only talking about one button, and a button whose background you can set to opaque, you'll probably be just fine. The alternative is reinventing the wheel to recreate button behavior in a subregion of the cell and that doesn't sound like functionality that will be much fun to maintain as the SDK matures.

That said, adding views to a cell doesn't incur a compositing cost per se, it's drawing those views that's the trouble. So if you really wanted to go nuts on the optimization, you could create a pre-rendered cell background image that includes the appearance of a button you want and then place a custom, image-free, see-through UIButton instance right over top of it. Nothing to draw, so no additional compositing cost. Worth a shot.

You didn't come here for a premature optimization speech, so I won't bother with one, but I say just do the cell with a normal button for now, make sure you like how the functionality feels to use then optimize toward the end if you're looking at performance that you're not happy with.