Should I Be Using Awakefromnib or Initwithcoder Here

Should I be using awakeFromNib or initWithCoder here?

The point of -awakeFromNib is so that you can do init stuff when you can be sure that all your connections to other objects in the nib have been established.

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.

Don't forget to call super.

It is unlikely to go away any time soon, and if it did so much code uses it that the transition period would be long. Yes its name comes from the old "nib" file format but this stack overflow question clears up the differences in the file extensions.

So in summary either method will work for you as you are setting an internal instance variable for the class. Note that inside init methods (including -initWithCoder) it may not be safe to use your setter methods in case setters rely on the class being fully initialised (source WWDC 2012 video moving to modern objective-c). An example would be setting a property that references another object in the nib file.

In UIViewController subclasses -initWithCoder is only called when loading from a storyboard. As -awakeFromNib is called whether you use storyboards or not it might make more sense to use that.

Another pattern you could consider is the lazy-getter:

- (NSMutableArray *)articles{
    if (_articles){
        return _articles;
    }
    _articles = [[NSMutableArray alloc] init];
    return _articles;
}

The benefit of this approach is that if you wanted to do further setup to the array you can easily discard the array when you don't need it anymore and the next time you access the property you have a fresh one again.

awakeFromNib vs. initWithFrame for custome UITableViewCell

When you are creating a Xib, initWithFrame will not be used. However, initWithCoder will be used. So, you can do extra instantiation in there. However, there is nothing wrong with initializing other controls in awakeFromNib either.

Edit: in response to your first comment below, check out this related question:

Should I be using awakeFromNib or initWithCoder here?

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.

What is [super awakeFromNib]; used for?

My understanding is it is telling the super class of this view controller ...

right so far...

(which would be the window)

oops - that's the source of your confusion.

The "super class of the view controller" is UIViewController. "super" is referring to the base class that your UIViewController sub-class inherits from; it doesn't have anything to do with the window that encloses your view.

So, what this is doing is invoking the default awakeFromNib implementation of a basic UIViewController, in addition to whatever you're doing in your sub-class implementation.

If you're using a UIStoryboard, will UIViewController call awakeFromNib?

Yes, awakeFromNib is being called.

According to the documentation:

Initializing a View Controller Loaded from a Storyboard When you
create a view controller in a storyboard, the attributes you configure
in Interface Builder are stored in an archive. Later, when the view
controller is instantiated, this archive is loaded into memory and
processed. The result is a set of objects whose attributes match those
you set in Interface Builder. Here’s how that archive is loaded:

If your view controller implements an initWithCoder: method, that
method is called to process the information in the archive. If your
view controller does not implement an initWithCoder: method, your view
controller’s init method is called instead.

After the objects in the archive are loaded, iOS calls the awakeFromNib method on any objects
that implement such a method. You use this method to perform any
configuration steps that require other objects to already be
instantiated.

Should I call [super awakeFromNib]?

awakeFromNib for UIKit (iOS):

You must call the super implementation of awakeFromNib to give parent classes the opportunity to perform any additional initialization they require. Although the default implementation of this method does nothing, many UIKit classes provide non-empty implementations. You may call the super implementation at any point during your own awakeFromNib method.

awakeFromNib for AppKit (Mac):

(not true anymore, if using OS X 10.6 or higher)

You should call the super implementation of awakeFromNib only if you know for certain that your superclass provides an implementation. Because the Application Kit does not provide a default implementation of the awakeFromNib method, calling super results in an exception if the parent class does not implement it. Classes whose immediate parent class is NSObject or NSView do not need to call the super implementation. For any other classes, you can use the instancesRespondToSelector: class method of NSObject to determine if the parent class responds to awakeFromNib and call the method if it does.

---

Related Topics