Thanks Steve. For completeness - what's the proper way to perform the cleanup? Should another static method be created that releases the singleton instance when the app is closed? i.e.
+ (void)releaseSharedInterface { [sharedInstance release]; sharedInsance = nil; } D On 1 June 2011 09:54, Dan Hopwood <d...@biasdevelopment.com> wrote: > Great, thanks a lot Steve - very helpful. > > D > > > > On 31 May 2011 18:44, Steve Christensen <puns...@mac.com> wrote: > >> How about providing a singleton class method? Then you just >> include WebServiceInterface.h where needed. No need to have a global >> variable. >> >> @implementation WebServiceInterface >> >> ... >> >> + (WebServiceInterface*) sharedInterface >> { >> static WebServiceInterface* sharedInstance = nil; >> >> if (sharedInstance == nil) >> sharedInstance = [[WebServiceInterface alloc] init]; >> >> return sharedInstance; >> } >> >> ... >> >> @end >> >> >> foo = [[WebServiceInterface sharedInterface] someMethod]; >> >> >> On May 31, 2011, at 3:25 AM, Dan Hopwood wrote: >> >> 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). >>> >> >> -- 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