Difference Between Awakefromnib() and Viewdidload() in Swift

difference between awakeFromNib() and viewDidLoad() in swift

From Apple documentation:

awakeFromNib:

The nib-loading infrastructure sends an awakeFromNib message to each object recreated from a nib archive, but only after all the objects in the archive have been loaded and initialized. When an object receives an awakeFromNib message, it is guaranteed to have all its outlet and action connections already established.

See: Nib Files in Resource Programming Guide

viewDidLoad:

This method is called after the view controller has loaded its view hierarchy into memory. This method is called regardless of whether the view hierarchy was loaded from a nib file or created programmatically in the loadView method. You usually override this method to perform additional initialization on views that were loaded from nib files.

Which should I use, -awakeFromNib or -viewDidLoad?

awakeFromNib is called when the controller itself is unarchived from a nib. viewDidLoad is called when the view is created/unarchived. This distinction is especially important when the controller's view is stored in a separate nib file.

viewDidLoad and awakeFromNib timing

To understand that fact I recommend you to see loadNibNamed:owner:options: method of NSBundle.

When you init a view controller from nib, first of all it loads views that are contained there, then it sets file owners properties according to nib. viewDidLoad method is called when it sets file owner's view property to one of the views that were loaded. And awakeFromNib is called when all file owners outlets and properties are set (including view property). So it makes sense that viewDidLoad is called earlier than awakeFromNib.

Hope this'll help

awakeFromNib vs didSet: Where to set Font or corner radius and why?

If you are just setting a simple font:

titleLabel.font = UIFont(name: "SomeFamily", size: 20)

then it doesn't really matter whether you do it in didSet or awakeFromNib. However, if your font depends on the property of some other IBOutlet, like (contrived example here):

titleLabel.font = UIFont(name: anotherLabelOutlet.text!, size: 20)

Then you should definitely do it in awakeFromNib. In awakeFromNib, as it is documented:

When an object receives an awakeFromNib message, it is guaranteed to have all its outlet and action connections already established.

In the didSet of titleLabel, however, it is not necessarily true that anotherLabelOutlet has been set. Outlets are set in a non-guaranteed order.

This not only applies to setting fonts, but also any initialisation that involves other outlets.

On the other hand, if you happen to reassign titleLabel somewhere down the line (for some weird reason), that new label won't get the font you set, if you set it in awakeFromNib, but will if you set it in didSet.

// in a later part of the code...
titleLabel = UILabel(frame: ...)
// titleLabel now has the new font if you set it in didSet, otherwise it won't

I would recommend that you don't think about this too much and just do it in awakeFromNib, and avoid reassigning IBOutlets in general.

Description of initWithNibName, awakeFromNib and viewDidLoad?

If you're creating your views in IB, then you should use viewDidLoad. That will be called every time the view is initialized to be put up. You use initWithNibName: when you're creating your view in code. You shouldn't use awakeFromNib with views for the iPhone.

The reason that initWithNibName is not seeming to be called is that interface builder actually creates a real instance of your view controller and then serializes that view. So, when you create the view controller in IB (add it to your project, basically), IB calls initWithNibName, but unless you have overridden the default encodeWithCoder:, any transient variables that you've set up there will be gone when the view is loaded from the nib (deserialized). This is generally okay since you usually want to set up your view with information specific to your applications current, running context rather than pre-determined initializers.

Even if you are programmatically creating views and view controllers, however, you can still put all the initialization in viewDidLoad. This is often better because if your view ends up getting cached (unloaded) and then brought back onto the screen, viewDidLoad can be called again while your initializer wouldn't necessarily be. For example, you create a view programmatically and push it onto a navigation controller's stack—later the view has been covered up and a memory warning is issued so the nav controller "unloads" your view but doesn't release the object—when the view comes back (other views get popped off), the nav controller will call viewDidLoad again so you can re-initialize, but initWithNib will not be called again. Note that this is a rare case and most people's applications will die horribly for other reasons at this point anyway, however.

---

Related Topics