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
