1

In an iOS 6 app I have some view controllers that are added as observers with the default notification center. They are added in the viewDidLoad method because I want the controllers to receive the notifications even when they are not on top.

A lot of people recommend removing the observer in the dealloc method. However, I have been logging messages with NSLog() both when adding and removing the observer, and it looks like dealloc is never called (I am using ARC).

Contrary to what one would think, the viewDidUnload method is not an option, since in iOS 5 it was only called during low-memory conditions, and in iOS 6 it is not called at all.

It actually seems that there is no way to do what the documentation requires! So far, my application has not crashed, by the way, even though controllers are being added multiple times and (apparently) never removed.

Note: So far I have been testing with the simulator only; is it possible that dealloc does get called in an actual device, but not in the simulator? Or is the call to NSLog() just not showing up (it shows up everywhere else, though).

EK0
  • 305
  • 5
  • 16

2 Answers2

3

Even in arc, dealloc is called. You cannot call [super dealloc] in arc but dealloc should be called if your view controller is being released. But, if you find it really difficult to manage, the situation why dont you add the notification observer in viewWillAppear and then remove it in viewWillDisappear. That way you will get notification until the view is shown and while the view is not shown, it may be released so it does not bother much to remove observer in viewWillDisappear. But, surely enough dealloc is called and is a good place for this.

  • Thank you, but `viewWillAppear` and `viewWillDisappear` are not an option because I want controllers to receive notifications even when their view is not on top. Maybe `dealloc` is getting called, but it's strange that the log message never shows up in the console. – EK0 Nov 28 '12 at 14:47
  • Actually, it seems that `dealloc` is _not_ getting called at all. I just put a breakpoint inside the method and the debugger never stops. – EK0 Nov 28 '12 at 15:00
  • OK, I take that back. . . . I'm giving you the checkmark because `dealloc` is being called just as you pointed out. Please see my own answer to the question for the details of what the problem really was. – EK0 Nov 28 '12 at 22:35
0

@NSProxy was correct that dealloc should be called. However, it was not being called for some of my controllers. Here's why:

View controller A was segueing to controller B. In prepareForSegue, controller A was creating a block that contained a reference to controller B (the target controller). Since the block was held on to by controller A (which being the home controller never went away), and the block was holding on to B, controller B never got deallocated.

I changed the reference to B in the block to be a weak pointer, and voilà, dealloc was called when B's view disappeared. The moral of the story is that you need to be very careful what you refer to in a block belonging to a class that stays around.

This still leaves me with one mystery: I still don't know why my home controller's dealloc never gets called, even when exiting the app by clicking the home button or stopping it in the simulator. No block refers to the home controller, so there must be something else holding on to the controller somewhere.

EK0
  • 305
  • 5
  • 16
  • The home button may background, suspend or even terminate the app, depending on your Info.plist settings. (A simulator exit is also a type of termination.) But those are not deallocing situations. See this answer to another question: http://stackoverflow.com/a/5081201/39381 – JK Laiho Jan 11 '13 at 13:16
  • That makes sense. So I guess can we assume that the OS automatically removes the app's observers from the default notification center when the app terminates, so that the home controller doesn't need to (and basically can't) do anything to clean itself up. – EK0 Jan 14 '13 at 14:58