Welcome to ShenZhenJia Knowledge Sharing Community for programmer and developer-Open, Learning and Share
menu search
person
Welcome To Ask or Share your Answers For Others

Categories

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?

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
thumb_up_alt 0 like thumb_down_alt 0 dislike
285 views
Welcome To Ask or Share your Answers For Others

1 Answer

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
}

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
thumb_up_alt 0 like thumb_down_alt 0 dislike
Welcome to ShenZhenJia Knowledge Sharing Community for programmer and developer-Open, Learning and Share
...