UITableViewController scrolls too far with large table footer

I have a UITableViewController subclass used for entering settings for my app. I add custom buttons to the table footer by adding them to a view that I return in he call to tableView:viewForFooterInSection:.

- (UIView *)tableView:(UITableView *)tableView viewForFooterInSection:(NSInteger)section 
{
    CGRect viewRect = self.view.bounds;
    float height = _settings.isNew ? 50.0 : 110.0;
    float margin = (viewRect.size.width > 480.0) ? 44.0 : 10.0; 
    UIView *view = [[UIView alloc] initWithFrame:CGRectMake(0, 0, viewRect.size.width, height)];    

    GradientButton* button = [[GradientButton alloc] initWithFrame:CGRectMake(margin, 5, viewRect.size.width - margin * 2, 44)];
    [view addSubview:button];
    [button addTarget:self action:@selector(testConnectionClicked:) forControlEvents:UIControlEventTouchUpInside];
    [button release];

    if (!_settings.isNew)
    {
    // I add another button
    }

    return [view autorelease];
}

- (CGFloat)tableView:(UITableView *)tableView heightForFooterInSection:(NSInteger)section 
{
    return _settings.isNew ? 50 : 110;
}

The whole point of subclassing from UITableViewControlle开发者_运维知识库r is to avoid problems with getting the cells scrolled into view when the keyboard appears.

This works mostly as it should, however when the edit moves to the last cell it seems to try to scroll the table footer into view. This means that it actually scrolls the editing textfield out of view when on iPhone in landscape view.

---

I solved this by adding an extra UIView below the tableview in my tableviewcontroller instead of setting some text in the footer of my last tableview section.

if you want that footer in multiple sections, this does not fix your problem of course.

---

Taking a hint from @ben-packard's answer, I discovered that the UITableViewController auto-scrolling isn't at fault; it's actually UITableView's -scrollToRowAtIndexPath:atScrollPosition:animated: that's causing the view to scroll too far. I have to imagine this behavior is intentional even though it's not documented, but in any case we can fix it by subclassing UITableView and overriding that method:

- (void)scrollToRowAtIndexPath:(NSIndexPath *)indexPath atScrollPosition:(UITableViewScrollPosition)scrollPosition animated:(BOOL)animated {
    if (scrollPosition == UITableViewScrollPositionNone)
        [self scrollRectToVisible:[self rectForRowAtIndexPath:indexPath] animated:animated];
    else
        [super scrollToRowAtIndexPath:indexPath atScrollPosition:scrollPosition animated:animated];
}

---

Did you implement tableView:heightForFooterInSection? It sounds like that could be the problem. If you implement tableView:viewForFooterInSection you must also implement tableView:heightForFooterInSection.

---

I suspect that the problem lies in your implementation of the scrolling on keyboard, but you didn't post any code from it.

Instead of subclassing a UITableView, why don't you do something like scrollToRowAtIndexPath:atScrollPosition:animated: when you do something that displays the keyboard? I found a similar thread here.

---

I found that scrolling to the rect instead (even though it is derived from the same row) seems to work:

CGRect rect = [myTableView rectForRowAtIndexPath:myIndexPath];
[myTableView scrollRectToVisible:rect animated:YES];