> In my -setFoo: method, I set up KVO on the properties of the foo that I'm
> interested in displaying. In the -observe... method, I update the various
> bits of UI as properties change.
If you're doing something like this:
- (void)setFoo: (Foo *)aFoo
{
[foo removeObserver:self forKeyPath:@"whatever"...];
foo = aFoo;
[foo addObserver:self forKeyPath:@"whatever"...;
}
we used that pattern for a while but were constantly getting bit by observers
on objects being dealloced or KVO firing and triggering unwanted side effects
if we called setFoo: in dealloc. So we did a complete switch over to doing
[self addObserver:self forKeyPath:@"foo.whatever"...
in init, and removeObserver in dealloc, because you can remove an observer on
yourself in dealloc without the "observers still registered" warning.
Since it's on self, you can set it before foo exists, and setFoo: triggers it.
Plus we could use synthesized setters.
----- Original Message -----
From: "Rick Mann" <rm...@latencyzero.com>
To: "Cocoa Developers" <cocoa-dev@lists.apple.com>
Sent: Wednesday, June 4, 2014 10:03:20 PM
Subject: viewDidLoad and KVO
I often have a view controller that displays a view associated with a model
object. So, I'll have a foo property on that VC, and in the prepareForSegue
call that presents the VC, I'll setFoo on it.
In my -setFoo: method, I set up KVO on the properties of the foo that I'm
interested in displaying. In the -observe... method, I update the various bits
of UI as properties change.
This generally works very well, except when I get to the VC via a segue.
-prepareForSegue gets called before -viewDidLoad, so none of the IBOutlets
exist yet.
I can solve this by doing an explicit UI update step in -viewDidLoad, but that
ends up effectively duplicating the UI update code.
I can load the view in -setFoo: by referencing self.view, but this seems like a
hack.
What are other people doing to address this? Any "best practice" you guys like?
--
Rick
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://urldefense.proofpoint.com/v1/url?u=https://lists.apple.com/mailman/options/cocoa-dev/lrucker%2540vmware.com&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yJFJhaNnTZDfFSSz1U9TSNMmxGyib3KjZGuKfIhHLxA%3D%0A&m=qYOnOaiiYwn8zuydsyBcZuhg6AnT0QTIlKRcBpdwfnM%3D%0A&s=a80229e6e590ffa9a96606cdc929d245804adff0b0a29bb275a85110c02b83bb
This email sent to lruc...@vmware.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
