Thanks for your response Steve. I have considered using the nsnotification service but what if you need to not only let another object know when an event has occurred but you also need to send that object some data? For example a user selects an option in a table - the selection must be conveyed in some way to the vc I'm pushing on the nav controller stack so that it's view is dynamic depending on the selection. As far as I'm aware that is not possible using notifications.
In general I create a new vc/nib for *every* screen I have in the app. Let's take a navigation app as an example. Are you saying that the hierarchy should be: -> 'root view controller' (has overall control, contains navigation logic and sends data between the containing view controllers) ->-> 'nav controller' ->-> 'all view controllers to be pushed/popped' ...where the nav controller and its view controllers are stored and initialised inside the 'root view controller'? Many thanks, Dan Sent from my iPad On May 27, 2011, at 20:19, Steve Christensen <puns...@mac.com> wrote: > A view controller controls a specific view hierarchy so it shouldn't be > reaching explicitly out to other view controllers to tell them to do > something. > > Depending on your specific situation, interested objects could register for > notifications when certain things change in the world, then one object could > just broadcast that something changed and not worry about what other objects > care. Or you could synch a controller's state (and possibly its view(s)) in > its -viewWillAppear: method since in many cases only a single controller's > view hierarchy is visible at any one time. > > > On May 27, 2011, at 11:13 AM, Dan Hopwood wrote: > >> I have been writing iPhone applications for a while now, with not too many >> problems but I feel like I haven't fully grasped how an application should >> be structured in terms of storing application objects. e.g. up to now, I've >> created a header file, declared all the main objects e.g. app delegate, view >> controllers, utilities and initialised them in the app delegate. For each >> class, I then just include the header file, which gives me access to all the >> objects, should I need to send them messages on certain UI events. >> >> Another option I have considered is storing them all in the app delegate >> instead and creating utility methods in the app delegate that delegate out >> to the objects from one place. E.g. a VC would then call the app delegate >> each time it needs to interact with another VC. >> >> If neither of these options is valid, which I suspect is the case (certainly >> global pointers is considered to be bad practise), then how do you store >> these pointers to that they are accessible in some way by all the VCs. >> Sending in the required pointers on initialisation of each VC (and storing a >> copy in each class) is the only other option I can think of but this seems >> annoyingly unelegant. >> >> Thoughts and suggestions much appreciated. > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
