Re: Application Design
Re: Application Design
- Subject: Re: Application Design
- From: Andrew Thompson <email@hidden>
- Date: Wed, 01 Jun 2011 17:05:18 -0700
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@hidden> 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@hidden> wrote:
>
>> Great, thanks a lot Steve - very helpful.
>>
>> D
>>
>>
>>
>> On 31 May 2011 18:44, Steve Christensen <email@hidden> 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@hidden>wrote:
>>>
>>>> On May 28, 2011, at 6:11, Dan Hopwood <email@hidden> 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@hidden
> *m* +44 (0) 7748 544356
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden