Re: [iPhone 3.0; XCode 3.1.3] Question about when views are available for manipulation.
Re: [iPhone 3.0; XCode 3.1.3] Question about when views are available for manipulation.
- Subject: Re: [iPhone 3.0; XCode 3.1.3] Question about when views are available for manipulation.
- From: Paul Collins <email@hidden>
- Date: Sun, 9 Aug 2009 18:46:21 -0700
On Sat, Aug 8, 2009 at 10:40 PM, Brian Bruinewoud<email@hidden> wrote:
> as it could be? What would be the better way to achieve this?
>
> At a guess to my second question: I suppose the new view should call on
> methods/properties of its File's Owner to discover what it needs to display.
> I haven't tried this so I don't know if its a workable solution, but it
> seems like it could be.
Earlier, you said:
> For example, if myProperty has a non-synthesized setter that expects IBOutlets to be bound it will be disappointed as they'll still be nil at this point.
The idea that a data property setter should be manipulating view
objects is what's getting you into trouble, IMHO. One way or another,
your model data should be more separate from your view (see "MVC").
Otherwise, it's fine to set your own properties of your new controller
MyController after you init it. Depending on whether your data is
going to get modified by the user working in this view, you might give
references or copies of your data objects to MyController, and let
MyController's -viewDidLoad (after calling super) then set the
contents of your views (probably interpreting/formatting at the same
time).
Your idea about calling File's Owner to get data is another way to go,
except File's Owner is MyController, so that's not going to get you
back to your object (containing the initWithNibName code you posted)
that presumably has the data. If you think this is a good way to go
for your app, you could give MyController a reference to that other
object to ask it for the data. Your probably want to NOT retain that
reference in MyController to avoid a reference loop, although you need
to make sure that object doesn't go away before MyController does. As
you see, this probably gives you more things to worry about than in
the previous strategy.
_______________________________________________
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