View Single Post
  #10 (permalink)  
Old March 8th, 2011, 10:07 AM
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

Feel free to check it out at your own pace.
As far as the from scratch/preexisting method problem, I think for any object you are using it is valuable to browse its class reference. Be aware of its properties, constants, notifications and whether it has delegate methods. You don't need to have everything in your head obviously, but after a while you can start to predict (guess?) what methods probably exist for an object and even what the signature will most likely be. The big "How was I supposed to know about that method?" question was one of the big stumbling blocks for me when I began dabbling in Cocoa. Foundation oriented stuff was very similar to libraries in C and was obvious, but GUI interaction was a whole new ballgame, with its heavy reliance on delegates and notifications in order to maintain the loose coupling that is such an important conceptual backbone of the object oriented design philosophy of iOS and Cocoa. Then along came bindingsā€¦

The project that I set up is actually pretty straightforward and primarily utilizes things already covered in the book up to the ScrollerView example. I don't think you would have any problem following it. It is the ScrollerView example with the addObserver/removeObserver conflict corrected combined with the TabBar example. By adding a second view there is now a reason to actually implement the -viewDidAppear and -viewDidDisappear methods instead of just putting the notification registration code in the -viewDidLoad and -viewDidUnload methods. The SecondView in the project is the corrected ScrollerView from the book. By switching to the other tabs you can observe (in the console) the notifications being sent and the observers being added and removed in SecondView, something you can't do in the book's single view project. So if you "get" the project in the book this will make sense and you can see the mechanics in action. The ThirdView uses a NavigationController to show that the behavior is consistent with the TabBar. The only view that might require some thought is the FirstView. This was based on the author's approach to programmatically add a view in Chapter 3. This is included to demonstrate that views added directly as subviews and not through controllers behave differently in terms of what delegate messages they receive, and that some methods must be called directly.

New link, since there was a tiny bug in the project.

Reply With Quote
The Following User Says Thank You to thepianoguy For This Useful Post:
gNotapipe (March 16th, 2011)