Thanks for all your answers, they make complete sense. I have one more related question. I have developed a custom, stateful WebServiceInterface object, which manages all connection requests made to an XML-RPC server. Being stateful, I initialise this object when the app launches and at the moment I store a pointer to it in a header file, which I include in all view controllers. This allows me to make a request for data from anywhere. In a similar way, I feel that storing a global pointer is not best practise and can't help but think there is a more elegant way of doing this. One option I have considered if storing/initialising the object in the app delegate and then creating a utility method in the delegate that wraps the object call. Is this the best solution or is there a design pattern I am unaware of?
Many thanks! On 28 May 2011 19:15, Conrad Shultz <con...@synthetiqsolutions.com> wrote: > On May 28, 2011, at 6:11, Dan Hopwood <d...@biasdevelopment.com> wrote: > > > 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. > > That's very doable with notifications. See the "object" and "userInfo" > methods in NSNotification and corresponding methods in NSNotificationCenter. > > > 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'? > > Well, I'd say the view controllers aren't "stored" inside the root view > controller; they are pushed onto the navigation stack as and when needed. > Unless you are doing some caching, I wouldn't store the view controllers > outside the navigation stack. (If you do implement caching, make sure you > respond to memory warnings by flushing the cache!) > > In a navigation based application I feel that your architecture is > simplified by design. Since only one view controller (notwithstanding modal > view controllers) is on screen at any time, and they are all arranged > hierarchically, parents should configure their children before pushing them > onto the stack. When children need to communicate back to their parents (for > example, if you push an editor view controller from a summary view > controller, which needs to be updated when the editor view controller makes > changes), you can use KVO or notifications, but if the communication is by > design of interest only to the parent and child view controllers, just make > the parent the delegate of the child. So if the child, say, had a list of > favorite URLs for the user to select, it could call something like [delegate > didSelectFavorite:url] which would cause the parent to be updated (and > change appearance when the child is popped off the stack). > > (Sent from my iPad.) > > -- > Conrad Shultz > www.synthetiqsolutions.com -- Director, Bias Development Ltd. *e* d...@biasdevelopment.com *m* +44 (0) 7748 544356 _______________________________________________ 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
