Re: Application Design
Re: Application Design
- Subject: Re: Application Design
- From: Dan Hopwood <email@hidden>
- Date: Tue, 31 May 2011 11:25:17 +0100
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).
>
> (Sent from my iPad.)
>
> --
> Conrad Shultz
> www.synthetiqsolutions.com
--
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