4

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!

chown
  • 51,908
  • 16
  • 134
  • 170
  • After answering, I realized that there at least a few possible duplicates: [`[super viewDidLoad]` convention](http://stackoverflow.com/questions/844195/super-viewdidload-convention) [Do I always have to call `[super viewDidLoad]`](http://stackoverflow.com/questions/824695/) [`[super viewDidUnload]` calling order](http://stackoverflow.com/questions/2365440/iphone-super-viewdidunload-calling-order) – jscs Oct 11 '11 at 18:14
  • @JoshCaswell Good catch, I swear I did a few searches before asking, not sure how I missed all of those. – chown Oct 11 '11 at 18:20
  • Not a big deal, to my mind -- the design-y/procedural questions usually garner interesting new tidbits when they are duplicated (as opposed to the "Why does my array not work?"). Of course, it is still nice to put all those tidbits in one place. Plus, your question is quite well-written. – jscs Oct 11 '11 at 19:06

2 Answers2

7

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.

Rui Peres
  • 25,741
  • 9
  • 87
  • 137
  • 3
    _"[What if] Apple adds some important piece of code that will run when `[super viewDidUnload]` is called, what will happen now?"_ - That is a very good point that didn't really cross my mind until now. – chown Oct 11 '11 at 18:25
  • That is a good thought, although [Steven Fisher's point](http://stackoverflow.com/questions/824695/do-i-always-have-to-call-super-viewdidload-in-the-viewdidload-method/1408692#1408692) is probably accurate that Apple is _unlikely_ to pull the rug out from under us in this way. @chown – jscs Oct 11 '11 at 19:01
  • Josh, that I call speculation. He is probably right, but I wouldn't put my hand in the fire for that... – Rui Peres Oct 11 '11 at 19:06
  • Nor would I; there's essentially no cost to including `[super viewDidUnload]` (and [Paul Tomblin makes an even better point](http://stackoverflow.com/questions/824695/do-i-always-have-to-call-super-viewdidload-in-the-viewdidload-method/824729#824729) as to why you should -- in case you change the superclass for some reason), but I think it's good to be clear-headed. – jscs Oct 11 '11 at 19:12
  • Don't think the method has been deprecated. Just converted a project to iOS 8 / 64bit and Xcode is flagging lack of [super viewDidUnload] as an 'issue'. – David Jul 27 '15 at 16:02
3

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.

jscs
  • 63,694
  • 13
  • 151
  • 195