Under the Bridge

My, we do seem to be writing a lot about UITableView recently, don’t we? But this is a particularly good one — how to implement multiple-row selection and actions:

UITableView does not support multiple selection. We will use the method tableView:didSelectRowAtIndexPath: to detect touches in rows but the selected state will need to be stored separately (we cannot rely on the UITableView‘s selection).

We will also need a background view for displaying the selection color and a UIImageView for displaying the not-selected/selected indicator. Since the UIImageView will be hidden while not editing and the label for the row needs to move left or right when it is shown or hidden, we will also need to implement some form of layout for the UITableViewCell.

Other required behaviors include switching the “Edit”/”Cancel” buttons between modes, showing/hiding the toolbar at the bottom and tracking the number of selected rows to display in the button in the toolbar…

Mighty handy stuff, that. Code can be downloaded here. And from quickly flipping around, looks like the entire CocoaWithLove blog this comes from is worth your perusal, there’s quite a number of nifty pieces of esoterica therein.

h/t: iPhoneKicks!

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.

Over at iPhoneSDKArticles.com they’ve been running a series on how to work with UITableView. The latest one is definitely worth your attention; it goes into step by step detail on how to manage the entire experience of allowing the user to refine the list with a search field.

When the user begins searching by clicking the search text box, we will do the following:

1. Set the “searching” variable to YES.
2. Set the “letUserSelectRow” variable to NO, since we do not want the user to select a row when the search box is empty.
3. Display a done button on the right bar.
4. Start searching as the user starts typing, this time allowing the user to select a row.
5. Use a different data source to bind the table, which display’s the search reults.
6. Search results are displayed in a single list and they are not grouped.
7. Hide the keyboard and finish searching, when the user clicks on done.

Source code link doesn’t seem to be working for us at the moment … but most of it’s in the article anyways, and the missing bits can’t be hard to fill in, we’re sure.

h/t: iPhoneKicks!