用于在iOS中实现完全自定义的containerViewController的类体系结构
我目前正在尝试构build自己的Custom ContainerViewController。
我非常熟悉iOS ViewController包含API（在iOS 5中引入）和新的iOS7 ViewController Transition API。
在实现我的容器时，我试图使用相同的模式UINavigationController和UITabBarController正在使用。
我的容器目前运行良好，正确使用animation和交互式转换。
问题是，我将大量的逻辑打包到我的UIViewController容器子类中。 它符合<UIViewControllerContextTransitioning>并使用iVars来存储该协议方法返回的所有值。
animation和交互逻辑已经在另一个类中分离了，第三方也可以使用类似于UINavigationControllerDelegate和UITabBarControllerDelegate的委托来提供自己的转换。
我现在要做的是将UIViewControllerContextTransitioning外包给一个单独的类，以创build苹果公司为它的containerVCs创build相同的模块性。 Apple为UIViewControllerAnimatedTransitioning和UIViewControllerInteractiveTransitioning方法提供了一个UIViewControllerOneToOneTransitionContext （私有API），用于传递给UIViewControllerAnimatedTransitioning对象的id<UIViewControllerContextTransitioning>对象。 所以他们不使用他们的UIViewController子类。 （这就是我现在所做的）
我当前的结构非常适合在转换逻辑在上下文中调用[updateInteractiveTransition:] ， [completeTransition:]等方法，这些调用直接在我的containerController上进行，然后可以通过更新其他元素在它的视图。 （和UINavigationController一样，当你调用[updateInteractiveTransition:]并且它正在更新NavigationBar（交叉渐变）的内容）。
在另一个类中外包上下文转换逻辑意味着：
- 提供视图控制器和框架等等，这些视图保存在容器的堆栈中，从容器到上下文对象，因为上下文需要将它们提供给转换逻辑。
- 从容器上的上下文对象调用transition-callbacks，因为上下文对象是从转换逻辑接收它们的那个对象。
正如苹果使用这种阶级关系，我想一定有一些优势。 目前，我不知道是否应该继续我的实现，或者尝试使它像苹果提供的容器一样模块化。
也看到这个- 问题 ，我问同样的事情。 （更像是一个回答问题，对不起：/）
虽然我们在这个话题：是否有可能使我的容器与UIPercentDrivenInteractiveTransition工作？ 该文件说，它在关键帧中剪切transitionAnimator执行的animation并自动“重放”animation过渡，所以我怀疑它可以与自定义容器一起使用。
谢谢你的帮助 ！
苹果公司使用许多符合特定协议的小型程序来交付工作。 分而治之。 看看例如UITableView操作或收集视图的方式。 他们把事情分成了几个小块，并为每个小块提供了一些通用的对象。 这些对象只符合某些协议。
- 不要强迫人子类。
- 创build满足特定angular色的类必须符合的协议。
- 在那里你要创build准备使用的对象，将执行某些操作 – 返回idtypes的对象，而不是类对象。 这是保持简单和足够灵活的唯一方法。 即使NSObject，这是一个类和协议，苹果做到这一点。 在创build自己的协议时，请记住使其符合NSObject *协议。
你的问题是相当长的，并没有问任何具体的问题，所以我希望这回答你的一些担心。 如果没有，请随时发布一个回应。