究竟 willMoveToParentViewController: 和 didMoveToParentViewController: 做什么？答案

【问题标题】：What exactly willMoveToParentViewController: and didMoveToParentViewController: do?究竟 willMoveToParentViewController: 和 didMoveToParentViewController: 做什么？
【发布时间】：2012-10-06 06:18:47
【问题描述】：

我知道从 iOS5 和新的 UIViewController 包含方法开始，您应该将这些方法与 addChildViewController:、removeFromParentViewController: 和 transition 方法一起调用。我也知道在三种情况下调用它们的正确顺序。我不知道这些方法到底是做什么的？

如果这些仅仅是 UIViewController 子类的覆盖点，我想我们在覆盖时不需要调用 super。如果我在删除视图控制器或 didMoveToParentViewController: self 之前不调用 willMoveToParentViewController: nil 会出现什么问题？

【问题讨论】：

标签： objective-c ios uiviewcontroller pushviewcontroller

【解决方案1】：

除了已经说过的，它们确实调用了一些委托方法：

addChildViewController 呼叫[child willMoveToParentViewController:self]

和removeFromParentViewController: 调用[child didMoveToParentViewController:nil]

此外，他们修改了 childViewControllers 属性，该属性包含一组子视图控制器。

【讨论】：

是的，我知道，'add' 和 'remove' 会自动调用一种方法（分别为 willMove... 和 didMove...），并要求您手动调用另一种方法。我想我对理解“添加”和“删除”的作用没有任何问题——这看起来很简单。我只是对“意志”和“做过”实际上做了什么感到有点困惑。
will 和 did 没有特定的实现，你在子控制器上调用它们，如果你没有，那么它们就不会被调用......如果子控制器实现它们并依赖它们，则可能是一个问题。在我的回答中，我错误地将它们称为“委托方法”，但这几乎就是它们的本质，它们充当可选的委托方法，孩子可能会使用它们进行一些设置或清理。任何 UIViewController 子类都可能覆盖它们，如果你实现了一个容器控制器，你应该尊重这种行为并调用它们。
明确地说，UIViewController 的willMoveToParentViewController: 和didMoveToParentViewController: 什么都不做。但是，任何子类都允许它们被覆盖，所以如果你不调用它们，你不会破坏一个裸 UIViewController，但你会破坏依赖它的子类（例如：假设一个子类想要释放一个对象时它从父视图控制器中移除，如果你不调用该方法，那么它永远不会释放对象）。
好的，这很清楚。所以它是一种可选协议。最近我试图在视图控制器层次结构管理中寻找一些错误，发现我忘记在一些地方调用这些错误。那时我开始想知道在这种情况下会出现什么问题。事实证明，只要我不在我添加/删除的 UIViewController 子类中覆盖这些，它就不应该影响任何东西（这并不意味着你不应该调用它们，显然）。非常感谢！
@Guillaume -- 我有一个给你！如果它是您刚刚创建的 NEW 视图控制器（instantiateViewControllerWithIdentifier）怎么办......在这种情况下，不调用 didMoveToParentViewController .. 是否完全安全，因为它没有移动？不调用它的好处是你避免了恼人的 2x viewWillAppear 问题。干杯！

【解决方案2】：

对此有很多答案：

他们在那里，你应该在适用的地方打电话给他们，以始终坚持这种模式。这样，如果您将超类从 UIViewController 更改为您自己的视图控制器，您就不必担心您在哪里遵循了整个模式。
与告诉所有人覆盖 addChildViewController: 相比，它们是更好的挂钩。正如你所说，错误管理willMoveToParentViewController: 听起来不像错误管理addChildViewController: 那样危险，尤其是如果你忘记致电super。
UIViewController 可能取决于您是否坚持这种模式。如果它知道它已收到addChildViewController: 但从未收到其他两条消息，它可能会认为状态不一致。发生这种情况是因为UIViewController 记账以诱使您坚持完整的模式，还是您真的弄乱了它的内部状态，这是一个有趣的猜谜游戏，但在任何 iOS 版本中都可能发生变化。事情可能会很糟糕。这就是为什么存在这种模式的原因，Apple 告诉你，只要你这样做，无论如何我们都会保持工作正常。

质疑一个模式是好的，但试图削减你对模式的一致性会带来许多潜在的负面影响。除非模式被荒谬地涉及，否则通常更容易符合它。

【讨论】：

我并不是要质疑使用这些方法。如果 Apple 文档说“你必须”给他们打电话，那肯定是有原因的。我只是希望对嵌套 UIViewControllers 机制有更多经验和知识的人会比官方文档更详细地解释它，官方文档只说它“通知”子视图控制器有关更改。我的理论是，如果您希望过渡动画化，它允许进行一些准备和清理，但这只是一个猜测。
哦，如果你将UIViewController 子类化，这就是它的用途。我的观点是，即使它什么也没做，知道这不会使您调用super 成为您应该避免的事情。也许最好的总结是“它使它变得不那么混乱，因为你不必覆盖addChildViewController:”（第2点）。