Question

I have a Tableview where the user can enter values into a textField as one of the custom cells

Apple have some documentation about how to adjust view content by repositioning the view clear of the keyboard’s vertical dimension ( Here ) but it relies upon one placing that view into a UIScrollView. I cant do this with a tableview.

I could redesign the app so that the entry gets done in a separate detail view using the usual navigation controller, but i’d rather the user not have to perform an extra touch ( and be ferried off into yet another screen ) if possible. I like the idea of doing the deed “right where we are”

so my workaround to have a few extra tableview cells at the bottom containing a %20 or so, normal usage shouldn’t register the oddity, as they are only focussed on what is visible.
I’d have to store the spaces in my datasource array and then sort descending, but that’s OK

the question is, is this good practice? and even more possibly, could it be against Apple’s HIG sufficient for refusal?

Answer 1

You don’t need the extra cells or anything fancy.

Since your text fields are inside the table view cells, you can use the following:

- (BOOL)textFieldShouldBeginEditing:(UITextField *)textField
{
    UITableViewCell *cell = (UITableViewCell *)textField.superview.superview;
    NSIndexPath *indexPath = [self.tableView indexPathForCell:cell];
    [self.tableView scrollToRowAtIndexPath:indexPath atScrollPosition:UITableViewScrollPositionMiddle animated:YES];
    return YES;
}

This means that the keyboard will scroll appropriately each time a text field becomes first responder. This takes advantage of the table view being a scroll view subclass.

Note that this assumes:

• Your (table) view controller is the text fields’ delegate.
• Your text field is a subview of the cell’s content view, not the cell itself.
  • If the text field is a subview of the cell, the first line of the method above should reference only one superview (i.e., textField.superview).