Question

I’m feeling very stupid, but…what is the right way to init instance variables in custom types, derived from Cocoa Touch UI classes?

Say I have type, derived from UIViewController, let it be TRUIController.
I defined an ivar as follows:

@implementation TRUIController
{
    NSNumberFormatter *_numberFormatter;
}
@end

And where should I put _numberFormatter initialization code, if I want it to be executed before any UI methods like viewDidLoad, etc?

In other languages I would create constructor, call base constructor and then init my ivars.
But that simply does not work in objective-c and Cocoa Touch.

In case described above,
If I write

-(id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil
{
    self = [super initWithNibName:nibBundleOrNil bundle:nibBundleOrNil];
    if(self)
    {
        //init ivars
    }
    return self;
}

It won’t work, I’ll try other initWithBlaBla methods, and finally find init, which is actually called, in that case – initWithCoder:

Now, let’s say I have class, derived from UITableViewCell. Again, need to init NSNumberFormatter ivar. Why can’t I just override init:, call super and init my ivars?

What’s the idea behind this strange design decision not to have single common initialization method for all types?

Is it the only way to initialize ivars in derived types? Every time do some research to figure out what method to override this time?

Have I missed something? Because it feels extremely stupid/unintuitive/error-prone

Answer 1

You have to do so overriding the designated initializer.

From the official documentation

A designated initializer is an init method of a class that invokes an
init method of the superclass. (Other initializers invoke the init
methods defined by the class.) Every public class should have one or
more designated initializers. As examples of designated initializers
there is NSView’s initWithFrame: and NSResponder’s init method. Where
init methods are not meant to be overridden, as is the case with
NSString and other abstract classes fronting class clusters, the
subclass is expected to implement its own.

Designated initializers should be clearly identified because this
information is important to those who want to subclass your class. A
subclass can just override the designated initializer and all other
initializers will work as designed.

When you implement a class of a framework, you often have to implement
its archiving methods as well: initWithCoder: and encodeWithCoder:. Be
careful not to do things in the initialization code path that doesn’t
happen when the object is unarchived. A good way to achieve this is to
call a common routine from your designated initializers and
initWithCoder: (which is a designated initializer itself) if your
class implements archiving.

Read the documentation for finding out which initializer is the designated one and override it.

According to the documentation of UIViewController initWithNibName:bundle: is the designated initializer for this class is so you should override that one, but if you are not programmatically instantiating your class (e.g. you’re loading it from nib/storyboard) you have to override the archiving method initWithCoder:.

As suggested by the documentation you can create a routine for initialization and call it from both the designated initializer and the archiving method.