真的保留IBOutlet视图元素的最佳做法是什么？

我不断遇到包含大量IBOutlets的UIViewControllers，它将控制器连接到其视图的子视图（通常是UILabels）。真的保留IBOutlet视图元素的最佳做法是什么？

继“最佳实践”，即使用保留的所有UI元素：@property (retain, nonatomic) UILabel *theElement1，@property (retain, nonatomic) UILabel *theElement2，...给我疯了大量的锅炉板代码dealloc和viewDidUnload的视图控制器。

从未在UIViewController（set-method仅用于viewDidUnload和nib加载时）中使用违规的IBOutlets，除非在加载nib时自动执行此操作。

从 “最佳实践” 的结果是：

dealloc散落着[theElement1 release]，[theElement2 release]等
viewDidUnload与[self setTheElement1:nil]，[self setTheElement2:nil]等

然而，由于所有这些元素的无论如何都被视图保留，并且视图在适当的时候由UIViewController释放，我看到绝对没有任何理由让我手动管理这个。

这个特殊的“最佳实践”（据我所知）的原因是与你的保留一致。但是一旦你开始有大量的网点，你很可能会错过处理这两种方法中的某一个出口，而不是正确地改变网点以“保留”你想要的那些特殊网点即使在观点告别之后仍保留。

除了我所了解的或者我应该感觉在UIViewController的视图的子视图的特定情况下可以自由地打破这个“规则”，是否还有其他原因？

来源

2010-06-24 Nuoji

我喜欢这个问题的话题。 “真的” – VoodooChild 2010-06-24 17:47:49

你应该坚持这个最佳实践。当您在发生内存警告后访问IBOutlets时，它可以保护您免遭非常奇怪的崩溃。是的，您需要手动管理您的IBOutlets。 Accessorizer在自动执行此代码方面做得不错。在ObjC 2.0之前，我们也必须手工编写所有的访问器（@property和@synthesize是语言的新增加）。事情变得更好了。随着我们转向64位ABI和垃圾收集，事情变得更加简单（您应该期待这些事情最终成为iPhone的方式）。

但现在，请按照Memory Management of Nib Objects中列出的内存管理规则进行操作。您只需进行少量的打字就可以进行大量的调试。（嗯，看起来他们已经更新了这个文档;有时间研究自己。）

来源

2010-06-24 17:51:39

不错 - 我之前没有看到过Nib Memory Management文档。 – 2010-06-24 17:53:43

我的另一个理智的选择过了一段时间后，变成手工生成UI元素并将它们粘贴到NSArray中。但这就像挥舞着旗帜而放弃。拥有像20-30 IBOutlets一样的东西是维护的噩梦。为什么我会有这么多网点你可能会问？本地化的UILabels是我的答案。 – Nuoji 2010-06-24 18:05:40

除了难以调试涉及这些字段的错误之外，还有什么缺点？事实上，对于这些特定的领域，您可以放弃整个@ property/@综合并使这些领域@private防止任何其他类错误地相信即使在删除视图时也可以使用它们。我在UIViewControllers和（只读）子控件的非常具体的上下文中讨论该控制器的视图。大量IBOutlets的问题在其他方面似乎不太可能出现。 – Nuoji 2010-06-24 18:31:56

真的保留IBOutlet视图元素的最佳做法是什么？

回答

相关问题