保持指向子视图的指针(Keeping pointers to subviews)

保持指向子视图的指针(Keeping pointers to subviews)

视图会自动保留添加到视图的子视图。 假设您想要一个指向同一子视图的单独指针，因此您不需要经常通过其标记检索它。

这种情况需要什么类型的@property ？ 我认为将属性设置为retain不是一个好主意，因为主视图已经保留了它？ 应该assign吗？

或者，在这里完全没有使用@property ，除非您打算稍后重新分配它或用点表示法引用它？

Subviews added to a view are automatically retained by the view. Suppose you want to have a separate pointer to the same subview so you don't need to constantly retrieve it via its tag.

What type of @property is necessary for such a case? I assume that setting the property to retain is not a good idea since the main view is already retaining it? Should it be assign?

Or, is using @property entirely unnecessary here unless you plan to re-assign it later or refer to it with dot notation?

最满意答案

您可以使用retain或assign 。

当然，如果使用retain ，则必须将该属性设置为nil或在viewDidUnload和dealloc释放其对象。

有些人更喜欢retain的原因是因为它意味着该属性在viewDidUnload仍然有效。 因此，如果您要进行其他清理，并且清理要求视图仍然存在，则可以在viewDidUnload执行此操作。

如果使用assign ，则不必在viewDidUnload和dealloc中将属性设置为nil （尽管这是一种很好的做法）。 但是，当您收到viewDidUnload ，视图已经被释放，因此您无法在此时使用它进行其他清理。 相反，在调用[super didReceiveMemoryWarning]之前，你必须覆盖didReceiveMemoryWarning来进行清理。

在iOS 5.0中，您可以在viewWillUnload执行清理，而不是覆盖didReceiveMemoryWarning 。

You can use either retain or assign.

Of course, if you use retain, you have to set the property to nil or release its object in viewDidUnload and dealloc.

The reason some people prefer retain is because it means the property is still valid in viewDidUnload. So if you have other cleanup to do, and that cleanup requires the view to still exist, you can do it in viewDidUnload.

If you use assign, you don't have to set the property to nil in viewDidUnload and dealloc (though it would be good practice). However, by the time you receive viewDidUnload, the view has already been released, so you can't use it at that point for other cleanup. Instead you have to override didReceiveMemoryWarning to do the cleanup before calling [super didReceiveMemoryWarning].

In iOS 5.0, you can do the cleanup in viewWillUnload instead of overriding didReceiveMemoryWarning.