Followup on various points.
In the NotificationCenter when adding and removing an object as an observer, -addObserver and -removeObserver notifications should always be paired (the same name). If the names are mismatched then the observer is added and never removed. The documentation underscores the need to remove observers before the observer or any observed objects are deallocated. So the book is incorrect when using DidShow
when adding and WillShow
when removing. As a side note, if you observe the visual result, in the book's example, the animation is better if WillShow
is used. As noted previously, adding the observer in -viewWillAppear
and removing the observer in -viewWillDisappear
is done since these methods are usually called automatically when the view comes into view, and is removed. A key point is that these methods must be called directly under some circumstances. If a main controller is used (TabBar, Navigation, SplitView) then these methods are called automatically as delegate methods when the view is added (pushed) and removed (popped) from the stack. On the other hand, if a view is added as a subview to an existing view the -viewWillAppea
r method should be called directly by the class allocating the instance of the subview. When removing itself the subview should call the -viewWillDisappear
To demonstrate this I have applied a variant of the ScrollerView example from the book to various mutliple view scenarios within a TabBar example.
1. FirstViewController assigned to Tab 1 adds the ScrollerView as a subview to itself. When adding theScrollerView subview, FirstViewController must call
on itself as ScrollerView appears, and -viewWillAppear
on the ScrollerView instance it creates. When the ScrollerView subview removes itself it calls -viewWillDisappear
on itself (ScrollerView) and sends a notification to FirstViewController to call -viewWillAppear
on itself (FirstView). If these direct calls are omitted (or commented out in my project example), the methods are not called. The other situation that is taken into account is switching tabs while the subview is still visible. Switching views in the TabBar calls -viewWillDisappear
on the viewController in the tab that it is leaving (FirstViewController in this case). FirstView has no need for the message and should forward it. In the example, the message is passed on to the subview, since that view is in front. When the tab is returned to (Tab 1 in this case), -viewWillAppear
is called on FirstViewController which again, must pass it on to its subview.
2. SecondViewController is the basic implementation from the book. As you can see, the -viewWillAppear
methods are called automatically when the tab selection changes.
3. Tab number 3 installs a navigationController into the 3rd tab. Again, the -viewWillAppear
methods are called automatically, as you drill down from and return to the RootController.
All this can be tracked through the NSLog statements.
The link to the project.
In addition, to get a sense of how many notifications are constantly being passed around, uncomment
// [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(listNotifications:) name:nil object:nil];
in in the TabBar delegate and check the console as you run the program. You can envision it somewhat like Twitter. All types of messages are constantly being posted, but you only receive the ones you follow.
Finally, the UIKeyboard is a view. More on that later.