Under the Bridge

Selection FAIL

Hey, looks like we’ve starting a continuing series of FAIL for your amusement and edification. Today’s exhibit is the proper selection behavior of your UITableView. Specifically,

Your application cannot be submitted to the App Store because of a Table View issue. Applications must adhere to the iPhone Human Interface Guidelines as outlined in iPhone SDK Agreement section 3.3.5.

According to the Table Views, Text Views, and Web Views section of the iPhone Human Interface Guidelines:

“Table views provide feedback when users select list items. Specifically, when an item can be selected, the row containing the item highlights briefly when a user selects it to show that the selection has been received. Then, an immediate action occurs: Either a new view is revealed or the row displays a checkmark to indicate that the item has been selected. The row never remains highlighted, because table views do not display persistent selected state.”

In your application, tapping on an item in the Table View results in the item becoming highlighted, and a new view is displayed. However, upon returning to the Table View, the item remains highlighted. Once the action has occurred, the Table View should no longer be highlighted when the user returns.

In order for your application to be reconsidered for the App Store, please resolve this issue and upload your new binary to iTunes Connect.

Sheesh. Somehow, we had completely managed to miss that there needed to be some active intervention there, we’d just kinda assumed that normal behavior would get taken care of by default. Ah, assumptions.

So, in case you happen to be submitting your first UITableView selecting app, here’s what we did to sort this out. In the appropriate UIViewController class, override:

// deselect selected row if any -- otherwise we GET REJECTED!
- (void)viewWillAppear:(BOOL)animated
{
   (void)animated;

   NSIndexPath *selection = [self.libraryTableView indexPathForSelectedRow];
   if (selection)
   [self.libraryTableView deselectRowAtIndexPath:selection animated:YES];
}

… and then we display the same animating out the selection when returning behavior that the iPod app for instance does. We trust that’s correct behavior.

2
  • http://www.benzado.com/ Benjamin Ragheb

    Technically, you should pass viewWillAppear:’s animated parameter along to deselectRowAtIndexPath:animated:, since (in theory) your view may be appearing but the transition may not be animated.

    Also, you seem to have a stray “(void)animated;” floating in your code.

  • http://www.alexcurylo.com/ Alex

    “Technically, you should pass viewWillAppear:’s animated parameter…”

    Nope, I specifically intend this to happen no matter how it’s getting back to that list. If Apple doesn’t like that I’ll be sure to note so above.

    “Also, you seem to have a stray “(void)animated;” floating in your code.”

    Cast to void is the One And Only True Way of cleaning up unused argument warnings (or errors, if you’re really hardcore with your compiling). See how efficiently it cuts off for instance this thread.

    http://discuss.fogcreek.com/joelonsoftware3/default.asp?cmd=show&ixPost=92559