【问题标题】：Understanding system logic for first responder了解第一响应者的系统逻辑
【发布时间】：2011-09-07 15:02:52
【问题描述】：
我对几个急救人员点感到困惑：
- 如果我调用
- becomeFirstResponder，系统会先调用– canBecomeFirstResponder吗？为什么？
- 为什么
- becomeFirstResponder 和– canBecomeFirstResponder 同时存在？在什么情况下它们可以返回不同的值？
- 应用程序每次都必须有第一响应者吗？如果是这样，当我在某个对象上调用
– resignFirstResponder 时会发生什么？ UIApplication 是立即成为第一响应者，还是在响应者链中的某个点上抛出这个“令牌”？当我想摆脱那个朝圣者令牌时，我可以在 UIApplication 对象上调用 - becomeFirstResponder 吗？
- ...
请有人解释一下，系统如何管理它的第一响应者。当某个对象成为第一响应者时，幕后发生了什么，当第一响应者辞职时会发生什么。系统调用什么...谢谢！
【问题讨论】：
标签：
objective-c
ios
cocoa-touch
first-responder
uiresponder
【解决方案1】：
-
becomeFirstResponder 的默认实现确实调用了canBecomeFirstResponder。这是因为从 canBecomeFirstResponder 返回 NO 的响应者不应成为第一响应者。
-
如果成功，
becomeFirstResponder 将使接收者实际上成为第一响应者。 canBecomeFirstResponder 只是检查接收者是否愿意成为第一响应者，而不实际更改任何内容。如果当前的第一响应者拒绝辞职，becomeFirstResponder 可能会失败。在其他情况下，becomeFirstResponder 也可能失败。
- 您的代码中不必有任何具有第一响应者状态的内容。通过私有 UIResponder 方法
firstResponder 判断，在这种情况下系统没有分配任何特定的默认值。
基本上，当某物想成为第一响应者时，当前的第一响应者（如果有的话）被要求辞职，然后新对象成为第一响应者。这可能会导致系统显示屏幕键盘或采取一些其他操作。当第一响应者辞职时，这同样可能导致系统隐藏屏幕键盘或采取其他一些措施。
当一个非触摸事件进来时，它首先被传递到 UIWindow。 UIWindow 将其传递给第一响应者。该文档似乎没有指定 UIWindow 是否尝试自己处理事件（如果它自己不处理它，则照常将其传递给 UIApplication ）或者如果没有第一响应者则忽略该事件。
详情请见the documentation。