Re: another n00b question -- how to find a memory leak
Re: another n00b question -- how to find a memory leak
- Subject: Re: another n00b question -- how to find a memory leak
- From: "Shawn Erickson" <email@hidden>
- Date: Wed, 22 Oct 2008 14:34:54 -0700
On Wed, Oct 22, 2008 at 2:21 PM, John Zorko <email@hidden> wrote:
>
> appDelegate.playbackThreadFinished = false;
> appDelegate.playbackThreadFinished = true;
...
> ... and I have this KVO handler:
>
> - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object
> change:(NSDictionary *)change
> context:(void *)context
> {
> if ([keyPath isEqualToString:@"isPlaying"])
...
> else if ([keyPath isEqualToString:@"playbackThreadFinished"])
...
> else if ([keyPath isEqualToString:@"donePlaying"])
...
> else if ([keyPath isEqualToString:@"nextSong"])
...
> }
This looks like a misapplication of KVO to me (functional but not the
best way IMHO). I think it would be better for your application
delegate to provide methods for these state changes and then you can
send messages from your secondary thread(s) to the delegate using
performSelectorOnMainThread:... Then the delegate could set properties
as needed (if still needed).
On a side note...
For this type of thing I have a "HOM" (higher order messaging)
construct that I use to bounce messages from a secondary thread to the
main thread. (you can search on HOM and find examples of this)
For example if I wanted someObject to process the following message in
the context of the main thread...
[someObject doThis:this withThat:that];
...I could write...
[[someObject performOnMainThread] doThis:this withThat:that];
...or maybe if I wanted to defer the message until the next event loop cycle...
[[someObject performLater] doThis:this withThat:that];
> Should I make sure
> _anything_ that happens in this KVO handler is dispatched to the main thread
> in that way?
In general UI related objects (views) should be worked with only from
the context of the main thread. In fact most of Cocoa should be dealt
with only from the main thread unless documented otherwise.
-Shawn
_______________________________________________
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