Re: Application Design
Re: Application Design
- Subject: Re: Application Design
- From: Steve Christensen <email@hidden>
- Date: Tue, 31 May 2011 10:44:00 -0700
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).
_______________________________________________
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