Question

I’ve got a fairly basic interface that normally looks like this:

Fairly uninspired, but that’s what the spec says to build. In any case, part of the issue is that when the onscreen keyboard pops up, this happens:

Now that’s not a big issue by itself; I’ve got everything inside of a UIScrollView, and am using the following code to handle the keyboard showing and hiding:

- (void) moveTextViewForKeyboard:(NSNotification*)aNotification up: (BOOL) up{
    NSDictionary* userInfo = [aNotification userInfo];

    // Get animation info from userInfo
    NSTimeInterval animationDuration;
    UIViewAnimationCurve animationCurve;

    CGRect keyboardEndFrame;

    [[userInfo objectForKey:UIKeyboardAnimationCurveUserInfoKey] getValue:&animationCurve];
    [[userInfo objectForKey:UIKeyboardAnimationDurationUserInfoKey] getValue:&animationDuration];


    [[userInfo objectForKey:UIKeyboardFrameEndUserInfoKey] getValue:&keyboardEndFrame];


    // Animate up or down
    [UIView beginAnimations:nil context:nil];
    [UIView setAnimationDuration:animationDuration];
    [UIView setAnimationCurve:animationCurve];

    CGRect newFrame = referrerInfoView.frame;
    CGRect keyboardFrame = [self.view convertRect:keyboardEndFrame toView:nil];

    newFrame.size.height -= (keyboardFrame.size.height - 71) * (up? 1 : -1);
    referrerInfoView.frame = newFrame;
    referrerInfoView.contentSize = CGSizeMake(703, 633);

    //FIXME:  doesn't play nice with rotation when the keyboard is displayed
    if (up && UIInterfaceOrientationIsLandscape([UIApplication sharedApplication].statusBarOrientation)) {
        UIView* focusedField = [referrerInfoView findFirstResponder];
        if (focusedField && focusedField.frame.origin.y > 340.0) {
            referrerInfoView.contentOffset = CGPointMake(0.0, focusedField.frame.origin.y - 200.0);
        }
    }
    else {
        referrerInfoView.contentOffset = CGPointMake(0.0, 0.0);
    }

    [UIView commitAnimations];
}

Not the most robust thing in the world, but it does well enough for now. That gets me to here:

Now that’s fine, except none of the elements in the shaded boxes respond to user interaction while the keyboard remains onscreen. The UIScrollView responds to interaction, as do all the other controls in the view. But all the ‘address’ fields stop working.

Essentially it seems that all the controls that were being hidden behind the keyboard before I scrolled them back into view still think that they’re being hidden behind the keyboard. Any ideas on how to fix this?

Answer 1

I found the solution to this. Basically the layout that I originally had was like this:

UIScrollView
    UIView
        <Components>

The container view inside of the scrollview wasn’t strictly necessary, but it didn’t seem like it should hurt anything either. That assumption, it turns out, was incorrect. Long story short, I changed the interface so that it is structured like this:

UIScrollView
    <Components>

And that solved the problem. Can’t say I really understand why, but hopefully this information will help the next person who happens to run into this issue.