有没有人找到使用新的iOS5键盘事件的好方法？
在为我的 iPad 应用程序开发最近的功能期间，我意识到新的 iOS5 键盘对接/拆分行为导致了巨大的问题。我使用 inputAccessoryView 作为键盘，上面有一个文本字段，类似于 Safari 的“在页面上查找”功能。我在可滚动的 UIWebView 上显示键盘，所以我的部分麻烦来自于当键盘停靠时 UIWebview 缩小，而当键盘脱离时有（大部分）全屏 webview。
我在使用该 API 时遇到的主要问题是，新的 UIKeyboardWillChangeFrameNotification 和 UIKeyboardDidChangeFrameNotification 通知充其量只是与之前的 API 相比的退一步，并且包含垃圾数据，使得在许多情况下几乎无法理解键盘真正在做什么。
是否可以在不费力检查通知上返回的开始/结束帧的情况下识别以下任何键盘行为？
- 键盘取消停靠
- 键盘停靠
- 键盘拆分/取消拆分
- 未停靠的键盘显示
- 未停靠的键盘 隐藏
- 视图在键盘未停靠时旋转
我已经提出了一些抽象来识别停靠或屏幕外的框架，但即使如此，我的代码也变得非常难以管理。如果您找到更好的方法来做到这一点，请回答或评论。我希望我在这里遗漏了一些东西。谢谢。
During development of a recent feature for my iPad app, I realized that the new iOS5 keyboard docking/splitting behavior was causing huge issues. I use an inputAccessoryView for the keyboard with a text field on it similar to Safari's find on page feature. I display the keyboard over a scrollable UIWebView, so part my troubles come from having a shrunken UIWebview when the keyboard is docked and having a (mostly) fullscreen webview when it is undocked.
The main issues I have run into with the API are that the new UIKeyboardWillChangeFrameNotification and UIKeyboardDidChangeFrameNotification notifications are a step back from the previous API at best, and have garbage data that makes it nearly impossible to understand what the keyboard is really doing in many cases.
Can any of the following keyboard behaviors be recognized without arduously examining the begin/end frames that come back on the notifications?
- Keyboard Undocks
- Keyboard Docks
- Keyboard Splits/Unsplits
- Undocked Keyboard Shows
- Undocked Keyboard Hides
- View rotates while keyboard is undocked
I've come up with some abstractions to recognize frames that are docked or offscreen, but even with that, my code is becoming very unmanageable. If you've found better ways to do this, please answer or comment. I hope I'm missing something here. Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
问题是不要想太多。任何重要的事情都没有改变。如果键盘进入屏幕底部的停靠位置，您将收到“显示”通知。如果它离开屏幕底部的停靠位置，您将收到“隐藏”通知。这正是 iOS 5 之前发生的情况。
唯一的区别是，它可能会因为用户取消停靠而离开停靠位置，而不是因为它移出屏幕而离开停靠位置。您仍然会得到“隐藏”，因此您可以将界面移回其基本位置。您不需要知道键盘现在已脱离（尽管如果您确实愿意，您可以从 UIKeyboardDidChangeFrameNotification 中发现它并未离开屏幕）。您不需要知道的原因是，当键盘脱离/分离时，如果键盘妨碍了需要看到的东西，用户可以主动移动键盘。
因此，iOS 5 之前的所有旧代码都可以继续正常工作。这一切真的非常聪明......
The thing is not to overthink this. Nothing of any importance has changed. If the keyboard comes into docked position at the bottom of the screen, you will get a "show" notification. If it leaves the docked position at the bottom of the screen, you will get a "hide" notification. That's exactly what happened before iOS 5.
The only difference is that instead of leaving the docked position because it is moving offscreen, it might be leaving the docked position because the user undocked it. You'll still get a "hide", so you can move your interface back into its base position. You don't need to know that the keyboard is now undocked (though you can find out that it is not offscreen from UIKeyboardDidChangeFrameNotification if you really want to). The reason you don't need to know is that when the keyboard is undocked / split, the user can be proactive and move the keyboard if it's in the way of something that needs to be seen.
Thus, all your old code from before iOS 5 continues to work just fine. It's all really quite clever...