为什么UIViewController是UIResponder的子类？

Question

使UIViewController成为UIResponder的子类的目的是什么？它只是为了传递旋转事件吗？

我在文档中找不到任何明确的信息。

更新

我理解如果某事物是UIResponder，那么这个东西应该包含在响应者链和处理事件中。但我有两个疑惑。

1. 据我所知，UIViewController在其view之后立即被放入响应者链中。为什么我们需要响应者链中的视图控制器？它的view已经存在，那么我们为什么不让视图处理其子视图未处理的事件呢？
2. 好的，我准备同意我们可能需要这个。但我希望看到一些真实的例子，当真正需要在视图控制器中处理事件时，这是最好/最简单/最合适的做事方式。

Answer 1

我认为你的问题可能只是面向对象思维的失败。

根据文档：

  

响应者链是响应者对象的链接系列   应用事件或操作消息。

在UIKit中，视图控制器位于其视图和控制器被推入的视图之间的响应链中。因此，它提供了其观点无法处理的任何事件或动作。

最顶层的视图控制器的下一个响应者是窗口，窗口的下一个响应者是应用程序，应用程序的下一个响应者是应用程序委托，应用程序委托是降压停止的地方。

你的问题“它是否只是为了通过轮换活动？”应用不正确的测试;这意味着在某些时候响应者链已经完全被设计并且有人认为'哦，等等，旋转怎么样？最好将视图控制器放入链中。

最初的问题是：如果视图控制器无法处理事件或操作，它是否有用？答案显然应该是“是” - 即使在触摸屏设备上 - 也会有与视图无关的事件或动作。

最明显的例子是与屏幕以外的物理输入相关的例子。因此设备轮换是一个。按键在蓝牙键盘上是另一个。遥控器是第三个。加速度计是第四个。

下一个最明显的例子是任何系统生成的事件或动作应该发送给单个最本地的参与者而不是每个人。在iOS中，通常会请求更具体的actor，例如最本地的撤消管理器或输入视图的标识，以显示焦点是否来自你。

一个稍微不那么明显的例子是UIMenuController示例 - 一个弹出视图，它发布了一个用户输入事件，该事件可能需要遍历多个视图控制器才能到达应该对其执行操作的视图控制器。 iOS 5的子视图控制器极大地增加了可能性;通常情况下，你会有一个父视图控制器，其逻辑可以执行一系列操作，并且孩子们希望将消息传递给任何知道如何处理它们的消息，而无需对层次结构进行硬编码。

所以，不，视图控制器没有添加到响应器链只是为了处理旋转事件。添加它们是因为逻辑上它们属于响应者链的初始定义。

Answer 2

这听起来像一个滑稽的答案，但事实并非如此。 UIViewController是UIResponder的子类，因此可以响应用户操作（例如触摸，动作等）。

如果某个视图没有响应某个事件，那么它会向响应者链传递，从而为更高级别的对象提供处理它的机会。因此，视图控制器和应用程序类都是UIResponder

的子类

您可以在Apple开发者网站的Cocoa Application Competencies for iOS: Responder Object中找到有关响应者链的更多详细信息。

Answer 3

UIViewController位于响应程序链中，允许它处理任何事件。还有更多你想到的（触摸）事件通过这个链。运动事件通过链传递，触摸特定视图无法处理的事件，您还可以使用[UIApplication sendEvent:...]以零目标强制通过响应者链。

您可能注意到的另一件事是UIApplication也是UIResponder的子类。所有未处理的事件都将在那里结束。

Answer 4

在MVC概念中，视图中发生的事件处理应该执行控制器。

有一个功能，将“nil”设置为 - [UIControl addTarget：action：forControlEvents：]的“target”参数，以便在响应者链中搜索愿意响应该动作的对象。

也就是说，由于搜索选项，UIViewController是UIResponder的子类。

因此，您可以以相同的方式发送自定义控件事件，以获得“搜索”选项的好处。