Re: Application Design
Re: Application Design
- Subject: Re: Application Design
- From: Steve Christensen <email@hidden>
- Date: Fri, 27 May 2011 12:19:39 -0700
A view controller controls a specific view hierarchy so it shouldn't be reaching explicitly out to other view controllers to tell them to do something.
Depending on your specific situation, interested objects could register for notifications when certain things change in the world, then one object could just broadcast that something changed and not worry about what other objects care. Or you could synch a controller's state (and possibly its view(s)) in its -viewWillAppear: method since in many cases only a single controller's view hierarchy is visible at any one time.
On May 27, 2011, at 11:13 AM, Dan Hopwood wrote:
> I have been writing iPhone applications for a while now, with not too many
> problems but I feel like I haven't fully grasped how an application should
> be structured in terms of storing application objects. e.g. up to now, I've
> created a header file, declared all the main objects e.g. app delegate, view
> controllers, utilities and initialised them in the app delegate. For each
> class, I then just include the header file, which gives me access to all the
> objects, should I need to send them messages on certain UI events.
>
> Another option I have considered is storing them all in the app delegate
> instead and creating utility methods in the app delegate that delegate out
> to the objects from one place. E.g. a VC would then call the app delegate
> each time it needs to interact with another VC.
>
> If neither of these options is valid, which I suspect is the case (certainly
> global pointers is considered to be bad practise), then how do you store
> these pointers to that they are accessible in some way by all the VCs.
> Sending in the required pointers on initialisation of each VC (and storing a
> copy in each class) is the only other option I can think of but this seems
> annoyingly unelegant.
>
> Thoughts and suggestions much appreciated.
_______________________________________________
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