Пер:
@IBOutlet weak var nameLabel: UILabel!
Всякий раз, когда я объявляю свои IBOutlets, я просто использую var вместо weak var. Но недавно я наткнулся на несколько шаблонов кода, в которых используется слабая переменная. Почему они это делают? В чем дополнительная выгода?
Почему в конце UILabel стоит оператор взрыва. Я знаю, что это необходимо, и я соглашаюсь с этим, но просто спрашиваю об этом сейчас.
Заранее спасибо.
У вас есть более подробная информация о разнице между слабым и сильным здесь
Когда вы объявляете выход в Swift, вы должны сделать тип выхода неявно развернутым необязательным (!). Таким образом, вы можете позволить раскадровке подключать выходы во время выполнения после инициализации.
Выходы слабы, поскольку элементы представления принадлежат (сильно) представлению. Я думаю, что технически нормально, чтобы ваш контроллер представления также имел сильную ссылку, но не обязательно.
Слабые переменные необязательны, так как они могут быть nil. Вместо этого вы можете объявить свои розетки с помощью ?, но это означает каждый раз использовать принудительную развертку или необязательную привязку. Объявление их как неявно развернутых опций с помощью ! — это просто удобство.
Вы используете weak при ссылке на IBOutlets, потому что, пока объект остается в своем супервизоре, на него будет строгая ссылка. См. раздел weak или strong для IBOutlets. Затем оператор взрыва указывает, что IBOutlet является явно развернутой меткой. С помощью оператора bang он гарантирует, что объект будет существовать, поэтому при ссылке на него вы можете просто сослаться на него следующим образом:
someLabel.text = "some text"
Однако вы можете сделать их IBOutlets необязательными:
@IBOutlet weak var someLabel: UILabel?
Но вы должны использовать ? при доступе к ним
someLabel?.text = "some text"
nil. Однако @IBOutlets будет инициализирован при вызове viewDidLoad. 02.03.2016 @IBOutlets инициализируются до того, как awakeFromNib вызывается на контроллере. 08.04.2016 Ответ @gregheo лучше всего объяснен для дальнейшего уточнения: если вы рассматриваете право собственности в этой ситуации, объект View, на который ссылается @IBOutlet, обычно не должен принадлежать контроллеру представления, ссылающемуся на него.
Скорее, он должен принадлежать своему супервизору, где бы он ни находился в дереве (что происходит в строгом соответствии с UIView.subviews). Контроллер представления вместо этого сильно владеет самым корнем своего дерева представлений (UIViewController.view). weak явно объявляет ссылку, не являющуюся владельцем, которая может стать нулевой в разные моменты жизни контроллера представления.
Здесь я бы предложил альтернативу использованию !: использование неявно развернутой дополнительной ссылки — опасная практика, которая ослабляет инструменты, которые предлагает нам Swift. Контроллер представления, который загружается из Xib или раскадровки, включает в свое время жизни регулярное время после создания и до того, как его представление было загружено, где ссылка @IBOutlet равна нулю, каждый раз. Предполагать, что никто не будет работать с членом в течение этого времени, означает не использовать грамматику Swift и обратную связь компилятора в наших интересах.
Кроме того, @IBOutlet являются мощным инструментом, обеспечивающим гибкий, ориентированный на визуальное восприятие подход при проектировании экрана или представления. Общепринятой практикой является то, что ваш контроллер представления выставляет @IBOutlets для всей доступной информации, независимо от того, известно ли, что он будет использоваться, и отдельно решает, что на самом деле подключать и использовать при построении и итерации представления из интерфейса. Строитель.
Кроме того, если ваше представление должно быть достаточно гибким, чтобы его можно было создавать из Xib/Storyboard И из кода, в зависимости от того, как вы решите, что ссылочные подпредставления должны быть созданы и подключены, они могут быть или не быть доступными немедленно.
По вышеуказанным причинам я определяю свой: @IBOutlet weak var nameLabel: UILabel?
