为什么苹果不允许子类化UINavigationController？和我的替代子类化是什么？ [英] Why doesn't Apple allow subclassing of UINavigationController? And what are my alternatives to subclassing?

问题描述

我目前正在建立一个标签式的iPhone应用程序，其中每个标签页的视图控制器是 UINavigationController 的一个实例，其中每个子控制器 UINavigationController 实例是 UITableViewController 的一个实例。理想情况下，我想子类 UINavigationController ，以便每个选项卡的控制器是UINavigationController的子类（除了所有标准 UINavigationController 功能，显然）充当数据源和与其子控制器相关联的每个表视图的委托。尝试这样做似乎打破了子类中的基本 UINavigationController 功能。

I'm currently building a tabbed iPhone application where each tab's view controller is an instance of UINavigationController, and where every subcontroller of every one of the UINavigationController instances is an instance of UITableViewController. Ideally, I'd like to subclass UINavigationController so that the controller for each tab is a subclass of UINavigationController that (in addition to having all the standard UINavigationController functionality, obviously) serves as the datasource and the delegate for each of the table views associated with its subcontrollers. Trying to do this seems to break the basic UINavigationController functionality in the subclass.

看到苹果在他们的iPhone文档，不应该子类 UINavigationController ，并且事情似乎打破了，我想知道我应该如何扩展 UINavigationController's 没有子类化的功能，一般来说，在进行Cocoa开发时，如何解决子类化限制。

Seeing as Apple says in their iPhone documentation that one shouldn't subclass UINavigationController, and things seem to break when one does, I'm wondering how I should go about extending UINavigationController's functionality without subclassing, and generally speaking, how one should work around subclassing limitations when doing Cocoa development.

谢谢！

推荐答案

我会继续说你的想法有一些优点，如果在每个级别你真正使用相同种类的数据，每个级别可能有一个不同的委托来处理单元格的创建。

I'm going to go ahead and say your idea has some merit, if at every level you are truly using the same kind of data and each level perhaps has a different delegate to handle cell creation.

基本上没有理由你不能子类化UINavigation控制器在它上面添加一个完全正交的数据层，因为它与无关UI或UINavigationController正在管理的行为（这是苹果公司关注的你会搞砸）。对于那些反对这个想法的人，把它想象为一个每个选项卡的数据存储，所有页面在一个选项卡可以访问，而不是每个页面在系统中必须去AppDelegate，或有一堆单身。基本上这是一个单例，但至少有一个已经存在，并得到自动传递的引用。

Basically there's no reason you cannot subclass UINavigation controller to add a totally orthogonal layer of data atop it, because it has nothing to do with the UI or behavior that UINavigationController is managing (which is what Apple is concerned you will be messing with). To those opposed to the idea, think of it as a per-tab data store that all pages in a tab can access instead of every page in the system having to go to the AppDelegate, or have a bunch of singletons. Well basically it's a singleton, but at least one that is already there and gets the reference passed around automatically.

所有这一切，我将结束一个替代设计方案 - 我想你可能想要做的是向下钻取通过多层重用相同的代码来生成单元格，等等，因为你在每一层有相同种类的数据。一个更好的方法是使用一个视图控制器来显示数据的子集，当用户向下钻取时，只需使用新的数据子集创建相同视图控制器的另一个实例。这种方法比将导航控制器用作每个级别的表委托的想法要好得多，因为您必须做大量的重新布线来回移动，并且需要更多的工作来记住每个级别的滚动位置级别启动。这就是为什么你想使用多个视图控制器实例进行深入分析，但是多个实例不一定意味着多个类。

All that said, I'll end with an alternate design proposal - I think what you are probably wanting to do is drill down through multiple layers reusing the same code to generate cells and such because you have the same kinds of data at each layer. A better approach to handle that is to have one view controller that you feed the subset of data to display, and when a user drills down it simply creates another instance of the same view controller with that new subset of data. That approach is much better than the idea of having the navigation controller act as a table delegate for each level, because you'd have to do a ton of rewiring moving back and forth and it would require even more work to remember scroll position at each level to boot. That's why you want to keep drill-downs using multiple instances of view controllers, but multiple instances doesn't have to mean multiple classes.

这篇关于为什么苹果不允许子类化UINavigationController？和我的替代子类化是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！