Question

We’re using Phonegap to develop our mobile app, and we borrowed code from here to remove the black next/prev/done bar from the keyboard:

https://stackoverflow.com/a/9276023/35364

What that code does is it finds the black bar, as a UIView object, and calls ‘removeFromSuperview’ on it.

We’re not familiar with the iOS SDK/API. So while we can look at the code and get an idea of what it’s doing, we can’t tell if it’s doing it properly, or how to improve it.

The specific problem we’re running into:

We have a text field for writing a message, and we’re manually controlling the placement of this field to be exactly above the keyboard, similar to the native sms app. In other words, we’re putting it where the black bar was supposed to be.

When we focus/type in the message field, the system pushes the view up. It seems like this is a mechanism to make sure the text field is not invisible when the user types in it.

This is happening even though the text field is visible.

I noticed that by putting the input field right above where the black bar would normally be (as oppose to behind it), the view doesn’t scroll.

So it seems the system somehow thinks the black bar is still there!

(To double check: when the black bar is not removed, and we put the text field right above it, we can focus and type in it, and the view would not scroll).

So the question is:

Why does the “system” push the content up when editing a text-field that’s place right “behind” where the black bar is supposed to be? Is it because the black bar is not completely removed yet? Do we need to do something to “completely” remove the black bar? Do we need to force iOS to recalculate the size of the keyboard? or what exactly?

Is this mechanism (pushing up the view) implemented by iOS’s UIWebView, or by Phonegap?

Is there any phonegap app that has solved this problem?

Answer 1

replace

[subviewWhichIsPossibleFormView removeFromSuperview];

with

UIScrollView *webScroll = [webView.subviews lastObject];
CGRect newFrame = webScroll.frame;

float accesssoryHeight = subviewWhichIsPossibleFormView.frame.size.height;
newFrame.size.height += accesssoryHeight;

[subviewWhichIsPossibleFormView removeFromSuperview];
[webScroll setFrame:newFrame];

it resize the content scroll view for the amount of missing accessory space. It is as far using “private API” as the other code. In detail it isn’t using private API directly but if Apple decide to change how a view appears (in this case Keyboard and WebView) then it will crash.
For example if they rename UIWebFormAccessory, your code will not work anymore.

EDIT:
on iOS 5.0+ you can call webView.scrollView directly. So you can split the code to have a pre iOS 5 fallback:

UIScrollView *webScroll;
if ([[[UIDevice currentDevice] systemVersion] floatValue] >= 5.0) {
    webScroll = webView.scrollView;
} else {
    webScroll = [webView.subviews lastObject]; // iOS 2.x (?) - 4.x
    // make sure this code runs appropriate on older SDKs
}