On Jul 22, 2012, at 8:43 PM, Jay Reynolds Freeman wrote:
> What Ken, Fritz and Kyle are saying makes sense, but flies a little bit in
> the face of what "asynchronous" often means. (I won't quibble if Apple is
> doing it their own way, they often do.) It also doesn't explain why the same
> linked executable behaves one way under Snow Leopard and another way under
> Lion, and the documentation for [NSSound isPlaying] is written in a way that
> suggests the caller of that method is talking directly to the receiver (an
> instance of NSSound), not a message center somewhere; there is no hint that
> it cannot be used anywhere.)
The reason is that you are relying on undefined behavior. When you do that,
results may change from release to release.
> I appreciate the advice and will play some more, but I would be obliged if
> someone at Apple would be willing to comment on what is going on (not clear
> if Ken, Kyle, or Fritz are Apple folks), and if anyone has any pointers to
> Apple documentation about what "asynchronous" means to them, I would be
> obliged.
For just about all of Apple’s asynchronous APIs, you can assume that they will
require the main event loop to keep running. In general, it is bad UI to
beachball the app for seconds at a time anyway.
> Since my app has nothing to do while waiting for the sound to play, a polling
> loop on "isPlaying" is actually a good deal less code (only two lines) than
> setting up a delegate with "-sound:didFinishPlaying" implemented.
Oh, I dunno about that. It takes one line to set up the delegate:
[someSound setDelegate:self];
and then one more line later on in the object (not counting the braces, since
you’re not counting those in the sleep loop example anyway):
- (void)sound:(NSSound *)sound didFinishPlaying:(BOOL)finishedPlaying {
...
}
Looks about equivalent to me in terms of length.
Charles
_______________________________________________
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
