View Single Post
  #8 (permalink)  
Old March 7th, 2011, 03:34 PM
thepianoguy thepianoguy is offline
Friend of Wrox
Points: 1,671, Level: 16
Points: 1,671, Level: 16 Points: 1,671, Level: 16 Points: 1,671, Level: 16
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
Join Date: Aug 2010
Posts: 298
Thanks: 1
Thanked 62 Times in 60 Posts

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 and DidHide when adding and WillShow and WillHide 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 -viewWillAppear method should be called directly by the class allocating the instance of the subview. When removing itself the subview should call the -viewWillDisappear on itself.

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 and -viewWillDisappear methods are called automatically when the tab selection changes.
3. Tab number 3 installs a navigationController into the 3rd tab. Again, the -viewWillAppear and -viewWillDisappear 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.


Last edited by thepianoguy; March 7th, 2011 at 03:38 PM..
Reply With Quote