Do I need to call [super viewDidUnload]?

Question

I have seen some Apple examples that do call [super viewDidUnload]; and some that don't. I read an article (a few months ago so I dont recall the url) that said calling [super viewDidUnload]; was unnecessary but it didn't explain beyond that.

Is there a definitive reason why or why not to tell super that the viewDidUnload?
And, (if it should be done) do I call super before setting all my properties to nil, after, or does it matter?

- (void)viewDidUnload {
    // Is this necessary?
    // [super viewDidUnload];

    self.tableDataSource = nil;
    self.titleLabel = nil;

    // Is it better to call super before or after nil'ing properties?
    // [super viewDidUnload];
}

Thanks!

Answer 1

1- Is there a definitive reason why or why not to tell super that the viewDidUnload?

Honestly I don't know the consequences of not calling it. You can try to not call it and everything works smooth, but imagine that Apple adds some importante piece of code that will run when [super viewDidUnload] is called, what will happen now? Bad things will happen probably and you will spend precious time trying to solve your problem. My rule is: when overriding, call the super.

2 - Do I call super before setting all my properties to nil, after, or does it matter?

It does matter, I have watched bad things happen when I called [super dealloc] before releasing my objects. The same way I saw my UI being slow because I did my calculations before [super viewDidLoad]. It always depend of what you want to achieve.

Bottom line, what I do in my projects for viewDidUnload is:

//release my views

[super viewDidUnload];

As for iOS6:

The method has been deprecated.

Answer 2

viewDidUnload is like dealloc in that you are "shutting down" your object -- you're freeing up memory and putting it into a (semi-)inactive state.

The recommended pattern in Cocoa is to do [super dealloc] at the end of your subclass's dealloc because you need to make sure that all the stuff you've added to the class can get released before your instance is invalidated by being freed itself. The same idea, although it is probably less of an issue, holds for viewDidUnload.

In general, when creating, let the superclass work first. When destroying, let it work last.

You don't need to send [super deconstructionMethod] iff the superclass's implementation does nothing. I think that is the case for viewDidUnload, but I'm not sure, and that's kind of indicative of the proper direction: the superclass is opaque to you, so unless it's documented that its implementation does nothing, you should always call up.