在 iOS 中实现完全自定义的 containerViewController 的类架构

Question

我目前正在尝试构建自己的自定义 ContainerViewController。

我对 iOS ViewController 包含 API（在 iOS 5 中引入）和新的 iOS7 ViewController Transition API 非常熟悉。

在实现我的容器时，我尝试使用 UINavigationController 和 UITabBarController 正在使用的相同模式。

到目前为止，我的 Container 运行良好，并且可以正确使用动画和交互式过渡。

问题是，我将大量逻辑打包到我的 UIViewController 容器子类中。它符合 <UIViewControllerContextTransitioning> 并使用 iVars 存储该协议的方法返回的所有值。

动画和交互逻辑已经在另一个类中分离，第三方也可以使用类似于UINavigationControllerDelegate 和UITabBarControllerDelegate 的委托提供自己的过渡。

我现在要做的是将UIViewControllerContextTransitioning 外包给一个单独的类，以创建与Apple 为其容器VC 所做的相同的模块化。 Apple 为传递给UIViewControllerAnimatedTransitioning 和UIViewControllerInteractiveTransitioning 方法的id<UIViewControllerContextTransitioning> 对象提供了UIViewControllerOneToOneTransitionContext（私有API）。所以他们没有为此使用他们的 UIViewController 子类。 （这就是我现在所做的）

到目前为止，我目前的结构很诱人，因为当转换逻辑在上下文中调用 [updateInteractiveTransition:]、[completeTransition:] 等时，这些调用直接在我的 containerController 上进行，然后可以通过更新其他响应来响应它认为的元素。 （就像 UINavigationController 在您调用 [updateInteractiveTransition:] 时所做的那样，它正在更新 NavigationBar 的内容（交叉淡入淡出）。

在另一个类中外包上下文转换逻辑意味着：

• 提供视图控制器和框架等，它们保存在我的容器的堆栈中，从容器到上下文对象，因为上下文需要将它们提供给转换逻辑。
• 从容器上的上下文对象调用转换回调，因为上下文对象是从转换逻辑接收它们的对象。

由于 Apple 使用这种类关系，我想它一定有一些优势。 目前，我不知道是否应该保留我的实现，或者尝试使其像 Apple 提供的容器一样模块化。

另请参阅SO - Question 我问了同样的事情。 （更像是一个答案问题，对此感到抱歉：/）

当我们讨论这个话题时：是否可以让我的容器与 UIPercentDrivenInteractiveTransition 一起使用？文档说它会在关键帧中剪切由 transitionAnimator 执行的动画，并逐步自动“重播”动画过渡，所以我怀疑它是否可以与自定义容器一起使用。

感谢您的帮助！

Answer 1

Apple 使用许多符合特定协议的小类来移交工作。分而治之。看看例如 UITableView 操作或集合视图的方式。他们确实将事物分成了尽可能小的块，并为每个块提供了一些通用对象。这些对象仅符合某些协议。

• 不要强迫人们继承子类。
• 创建履行某些角色的类必须遵守的协议。
• 您要在其中创建执行某些操作的即用型对象 - 返回对象的 id 类型，而不是类对象。这是保持事情足够简单和灵活的唯一方法。 Apple 甚至使用既是类又是协议的 NSObject 来做到这一点。 创建自己的协议时，请记住使它们符合 NSObject * 协议。

您的问题比较长，并没有提出任何具体问题，所以我希望这能回答您的一些担忧。如果没有，请随时发布一个来回应这个问题。