views:

5797

answers:

3

I've been asking a question or two over the past few days of working on an application that keeps a custom toolbar aligned to the top of the iPhone keyboard. I'm using the method described by Josh in this question; basically, I have the view controller listen for the UIKeyboardWillShowNotification and add the toolbar as necessary.

The view controller itself manages a table view whose cells all contain a UITextField. The keyboard and toolbar being presented are editing these text fields. The only issue I'm still having is this: when the keyboard and toolbar are presented for a cell more than about halfway down the table, it scrolls to be visible above the keyboard, but not above the toolbar.

The cells and text fields are still editable, but about half the cell is hidden under the toolbar. If I disappear the toolbar (don't add it in the notification responder), the entire cell becomes visible, but obviously I lose the functionality the toolbar provides.

Is there a way to change the location the text field gets scrolled to? I've tried playing around with the UITableView method scrollToRowAtIndexPath:atScrollPosition:animated:, but it tends to give weird results when toggling through several cells.

What's the best method for scrolling a table view cell to a visible position above a custom keyboard toolbar?

A: 

Maybe you could resize the UITableView to be the height between the navigation bar and the toolbar above the keyboard, and then scroll the row into view?

Fraser Speirs
I gave that a try - the table view seems to resize OK, then chokes pretty badly if you try to scroll a cell that was in the area that got resized away back onto the screen.
Tim
+4  A: 

I do exactly what you are describing in my app. This is the code I use, verbatim. It's very nicely animated, and seems to work wonderfully.

Two disclaimers:

  1. I pass in parentView as part of a custom initialization.
  2. I did not write this code, I'm not taking credit for it. I got it from Matt Gallagher's truly wonderful blog Cocoa With Love.


static const CGFloat KEYBOARD_ANIMATION_DURATION = 0.3;
static const CGFloat MINIMUM_SCROLL_FRACTION = 0.2;
static const CGFloat MAXIMUM_SCROLL_FRACTION = 0.8;
// adjust this following value to account for the height of your toolbar, too
static const CGFloat PORTRAIT_KEYBOARD_HEIGHT = 216;


- (void)textFieldDidEndEditing:(UITextField *)textField
{
  CGRect viewFrame = self.parentView.frame;
  viewFrame.origin.y += animatedDistance;

  [UIView beginAnimations:nil context:NULL];
  [UIView setAnimationBeginsFromCurrentState:YES];
  [UIView setAnimationDuration:KEYBOARD_ANIMATION_DURATION];

  [self.parentView setFrame:viewFrame];

  [UIView commitAnimations];
}

- (void) textFieldDidBeginEditing:(UITextField*) textField {
  CGRect textFieldRect = [self.parentView.window convertRect:textField.bounds fromView:textField];
  CGRect viewRect = [self.parentView.window convertRect:self.parentView.bounds fromView:self.parentView];
  CGFloat midline = textFieldRect.origin.y + 0.5 * textFieldRect.size.height;
  CGFloat numerator = midline - viewRect.origin.y - MINIMUM_SCROLL_FRACTION * viewRect.size.height;
  CGFloat denominator = (MAXIMUM_SCROLL_FRACTION - MINIMUM_SCROLL_FRACTION) * viewRect.size.height;
  CGFloat heightFraction = numerator / denominator;

  if (heightFraction < 0.0) {
    heightFraction = 0.0;
  }else if (heightFraction > 1.0) {
    heightFraction = 1.0;
  }

  animatedDistance = floor(PORTRAIT_KEYBOARD_HEIGHT * heightFraction);

  CGRect viewFrame = self.parentView.frame;
  viewFrame.origin.y -= animatedDistance;

  [UIView beginAnimations:nil context:NULL];
  [UIView setAnimationBeginsFromCurrentState:YES];
  [UIView setAnimationDuration:KEYBOARD_ANIMATION_DURATION];

  [self.parentView setFrame:viewFrame];

  [UIView commitAnimations];
}
mmc
I'm assuming you're referring to this blog post at http://cocoawithlove.com/2008/10/sliding-uitextfields-around-to-avoid.html - I've seen it too, and it doesn't really deal with UITableViews, only static views with UITextFields. The issue with this approach is that the animatedDistance may change as the user scrolls through the table view.
Tim
I'm using it inside a UITableView with no issue whatsoever.
mmc
I implemented this, but on closer inspection of the code and results all it does is move the origin of the table view up off the screen. It has the effect described in the blog post, but makes it impossible for the user to see the top few table view cells when editing a cell near the bottom of the table.
Tim
I guess I don't understand the question then. There is only so much screen space. I'm not sure how you can show the cells at the top, edit the cells at the bottom, *and* show the keyboard.
mmc
Maybe I'm implementing something slightly off - what view do you pass in for parentView in your initializer? I'm using self.tableView in lieu of parentView, but that might be messing with it.
Tim
The UITableView I have set up has a number of unique rows, each with a different setup, ala a settings screen or input form. I'm also using Matt's GenericTableViewController code. I added a custom initializer to my *cell controller* classes. When I initialize them (inside constructTableGroups) I pass in "self.view" (so, this is the view of the UITableViewController). The code I posted is in my CellController class (inherits NSObject, implements CellController [part of GenericTableViewController] and UITextFieldDelegate)
mmc
So it would be reasonable, if I had UITextFieldDelegate be implemented by the table view controller rather than the cell controller, to place this code in the table view controller and replace instances of parentView with self.view?
Tim
That does seem reasonable to me. I assume that's what you have done, and it's not working?
mmc
It's working, and the currently editing cell always stays visible on the screen. I was hoping for a solution that would allow users to deliberately scroll the editing cell off the screen if necessary. I'll also have to play around with the contentSize of the table view to fix how the scrollbar appears on the screen. Nevertheless, thanks - this has been tremendously helpful!
Tim
Keep in mind that what you desire MAY not be possible. UITableViewCells that scroll off the screen are queued up for reuse. I certainly COULD be wrong, but I don't think it is possible to have a firstResponder that is off-screen, because that cell could be recycled at any time.
mmc
You make a very good point, and in that light, I think the solution you present here may be the best. I had forgotten about cell reuse :) Thanks again.
Tim
Tried it, and works great, just don't forget to add the controller as the delegate of all textfields.
Miha Hribar
A: 

Since all UITableViews are also UIScrollViews, you can call all of the standard scroll methods on them.

Something like this will do:

- (void)scrollTableView:(UITableView *)tableView toIndexPath:(NSIndexPath *)indexPath withBottomPadding:(CGFloat)bottomPadding
{
    CGRect rectForRow = [tableView rectForRowAtIndexPath:indexPath];
    CGRect bounds = [tableView bounds];
    CGPoint contentOffset = [tableView contentSize];
    if (rectForRow.origin.y + rectForRow.size.height > contentOffset.y + bounds.size.height - bottomPadding)
        [tableView setContentOffset:rectForRow.origin.y + rectForRow.size.height - bounds.size.height - bottomPadding animated:YES];
    else
        [tableView scrollToRowAtIndexPath:indexPath atScrollPosition:UITableViewScrollPositionNone animated:YES];
}

Note: I'm not at a Mac with Xcode at the moment. I will test this code when I am

rpetrich