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).
_______________________________________________
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]
