I'll caution you as written that singleton is not be thread safe. Often you don't care, because you only have one thread or because creating 2 webservice clients may not be a problem for you.
On Jun 1, 2011, at 3:54 AM, Dan Hopwood <[email protected]> wrote: > 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 <[email protected]> wrote: > >> Great, thanks a lot Steve - very helpful. >> >> D >> >> >> >> On 31 May 2011 18:44, Steve Christensen <[email protected]> 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 <[email protected]>wrote: >>> >>>> On May 28, 2011, at 6:11, Dan Hopwood <[email protected]> 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* [email protected] > *m* +44 (0) 7748 544356 > _______________________________________________ > > Cocoa-dev mailing list ([email protected]) > > 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/lordpixel%40mac.com > > This email sent to [email protected] _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
