Phonegap:彻底去除 iPhone 键盘上的黑条 [英] Phonegap: completely removing the black bar from the iPhone keyboard

查看:32
本文介绍了Phonegap:彻底去除 iPhone 键盘上的黑条的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们正在使用 Phonegap 来开发我们的移动应用程序,我们从这里借用了代码来从键盘上删除黑色的 next/prev/done 栏:

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

该代码的作用是找到作为 UIView 对象的黑条,并在其上调用removeFromSuperview".

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

我们不熟悉 iOS SDK/API.因此,虽然我们可以查看代码并了解它在做什么,但我们无法判断它是否正确执行,或者如何改进它.

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.

我们遇到的具体问题:

我们有一个用于编写消息的文本字段,我们正在手动控制该字段的位置,使其正好位于键盘上方,类似于本机短信应用程序.换句话说,我们把它放在了黑条应该在的地方.

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).

所以问题是:

为什么系统"在编辑位于黑条后面"的文本字段时会向上推内容?是不是因为黑条还没有完全去除?我们是否需要做一些事情来完全"去除黑条?我们需要强制iOS重新计算键盘的大小吗?或者究竟是什么?

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?

这个机制(推视图)是由iOS的UIWebView实现的,还是Phonegap实现的?

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

有没有解决这个问题的phonegap应用程序?

Is there any phonegap app that has solved this problem?

推荐答案

替换

[subviewWhichIsPossibleFormView removeFromSuperview];

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

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

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

它根据缺少的附件空间量调整内容滚动视图的大小.它与其他代码一样使用私有 API".详细地说,它没有直接使用私有 API,但如果 Apple 决定更改视图的显示方式(在本例中为键盘和 WebView),那么它就会崩溃.
例如,如果他们重命名 UIWebFormAccessory,您的代码将不再起作用.

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.


在 iOS 5.0+ 上你可以直接调用 webView.scrollView.因此,您可以拆分代码以获得 iOS 5 之前的回退:


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
}

这篇关于Phonegap:彻底去除 iPhone 键盘上的黑条的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆