IBOutlet должен быть слабым?

Возможный дубликат:
Должен ли IBOutlets быть сильный или слабый в ARC?

Я кратко прочитал об ARC и подумал, что все хорошо, а делегат слаб.

Теперь я создаю представление в построителе интерфейса и делаю IBOutlets, а для параметра Xcode по умолчанию установлено значение weak.

Кажется, есть причина для этого предложения, есть ли причина, по которой большинству IBOutlets нужно слабое свойство?

Это потому, что эти представления (IBOutlets) уже сохранены, потому что они прикреплены к его супервизору? а мы редко заменяем просмотры IBOutlet?

Но я не вижу вреда в том, чтобы ставить его сильным, есть ли в этом проблема?


ios iphone automatic-ref-counting iboutlet
person eugene    schedule 25.08.2012    source источник
comment
Просто убедитесь, что если вы используете strong, добавьте self.myOutlet = nil; в viewDidUnload.   -  person Mazyod    schedule 25.08.2012
comment
Мазёд: в этом есть необходимость? когда счетчик сохранения себя достигает нуля, все его подвиды не будут выпущены?   -  person eugene    schedule 25.08.2012

Ответы (2)


arrow_upward
5
arrow_downward

Обсуждение того, почему ссылки IBOutlet должны быть слабыми, см. в Руководство по программированию ресурсов: Nib-файлы. Цитирую из руководства:

Выходы, как правило, должны быть слабыми, за исключением тех, от владельца файла до объектов верхнего уровня в файле пера (или, в iOS, сцена раскадровки), которые должны быть сильными. Таким образом, создаваемые вами торговые точки обычно должны быть слабыми, потому что:

  • Выходы, которые вы создаете для подвидов представления контроллера представления или окна оконного контроллера, например, являются произвольными ссылками между объектами, которые не подразумевают владения.
  • Сильные выходы часто определяются классами фреймворка (например, выход вида UIViewController или выход окна NSWindowController).

За мои собственные два цента я делаю вещи strong, если они принадлежат мне, или мне нужна сильная ссылка на случай, если владелец уходит, и мне нужно, чтобы это осталось, ни то, ни другое здесь не применимо. Итак, вместо того, чтобы спрашивать «почему я не могу сделать это strong?», я бы спросил «почему я хочу сделать это strong?» Если для этого нет веских причин, я бы позволил Interface Builder сделать свое дело и сделать его weak.

person Rob    schedule 25.08.2012
comment
Мои два цента согласны. Я бы также добавил, что легче найти случаи, когда что-то weak должно быть strong (Эй, я не ожидал, что это будет ноль... Думаю, мне нужна сильная ссылка на это), чем наоборот (огонь вверх по приборам и искать утечки). - person rickster; 25.08.2012
comment
@Rob: разве представление не владеет своим подпредставлением? или контроллер представления имеет свое представление? Я не понимаю Выходы, которые вы создаете для подпредставлений представления контроллера представления или окна оконного контроллера, например, являются произвольными ссылками между объектами, которые не подразумевают владения. - person eugene; 25.08.2012
comment
@Eugene Да, контроллер представления владеет своим представлением (поэтому сильные выходы часто указываются классами фреймворка, например выход представления UIViewController), а представление владеет своими подпредставлениями. Но контроллер представления не владеет подпредставлениями своего представления; как вы только что указали, представление делает. - person Rob; 25.08.2012

arrow_upward
0
arrow_downward

Это просто предпочтение. Обоснование слабого или назначения заключается в том, что суперпредставления, контроллеры и т. д. будут содержать сильные ссылки в течение всего времени существования объекта в этом графе.

Лично я сторонник старой школы и предпочитаю сильные ссылки — даже в этом сценарии. Иногда использование сильных ссылок означает, что вам может потребоваться явно уничтожить компоненты подграфов ваших объектов (например, вы должны «сломать» все циклические зависимости при удалении). Я использую weak только в очень исключительных случаях, потому что предпочитаю последовательность; В игре меньше переменных, когда/если что-то пойдет не так и при чтении программ.

person justin    schedule 25.08.2012