views:

1715

answers:

1

I see some example code with [super viewDidLoad] called before your implementation and after your implementation.

I know you don't always have to call super (as seen in many other discussions). When you do call it, is it expected before or after you code?

This could have consequences depending on what super's implementation does. Though you shouldn't have to know super's implementation to write yours.

Of course this goes for all of UIViewControllers delegate methods (willAppear, didAppear, etc...)

Any thoughts?

+17  A: 

My rule of thumb is: if you're doing something related to initialization, always call the super class's method first (if you are going to call it at all). This gives the super class a chance to do any set-up that you may be relying on later in your method. If you're doing something related to destruction, call the super class's method last. This makes sure that you can rely on the state of the object throughout the execution of your method. Finally, take any other case on a case-by-case basis. For instance, if you're handling an event, you probably want to deal with the event first, and only invoke the super class's method if you chose not to handle the event or if you somehow altered it and want to pass it along the event chain.

Jason Coco
Good advice from Jason, and often Apple documents subclasser responsibility when it's important. E.g. when some crucial behavior depends on a super call, it's often highlighted in the documentation.In general, if it's not going to hurt you, just call through to super to be safe.
danielpunkass
Thanks, that is pretty logical and kind of the approach I was taking. I was subclassing my own classes and I had a choice of what to do. I didn't want to violate convention by requiring setup before/after viewDidLoad.
Corey Floyd
Of course its the opposite in -dealloc, since you might need to use something belonging to the superclass before it gets deallocated.
Mk12