Re: MPMoviePlayerController
Re: MPMoviePlayerController
- Subject: Re: MPMoviePlayerController
- From: Quincey Morris <email@hidden>
- Date: Wed, 13 Apr 2011 12:09:07 -0700
On Apr 13, 2011, at 11:39, Jeffrey Walton wrote:
> Silly me. I went looking for documentation on MPMoviePlayerController
> PLAY in MPMoviePlayerController's documentation.
Unfortunately, it's just something you need to learn about Apple's style of documentation -- when consulting the documentation for a class, especially the first time, you also need to look at the superclass documentation and (now that so many informal protocols have been formalized in Snow Leopard) in the documentation for protocols the class conforms to.
Although this can trip up the unwary (usually only once), it's hard to get worked up about, because the alternative -- repeating "inherited" method documentation everywhere, which some people have asked for on this list -- would probably be worse. There's an *awful* lot of methods whose behavior is shared.
> The great thing about an immediate return code (followed by a call to
> GetLastError or errno) is one can find the point of first failure
> quickly, without disgorging the point of failure from the reporting
> mechanism. There's a lot to be said about finding the point of first
> failure quickly.
The other point that Kyle didn't make explicitly is that global error variables aren't thread safe. Also, since Cocoa internally makes a lot of use of threading that you won't see explicitly, "the" point of failure can't be very well-defined in Mac OS X, in the sense it would be if you were single-threaded. 'errno' is old-school.
> MPMoviePlayerPlaybackDidFinishNotification " ... is also sent when
> playback fails because of an error." So how does one tell when the
> notification is sent for a good reason, versus a bad reason? As can be
> seen, the documentation does not clarify. Its too bad there is no
> 'MPMoviePlayerError' (or similar) notification (perhaps I'm reading
> the notification section incorrectly).
FWIW, anything involving QuickTime is "special". Historically, the QuickTime APIs have been a mess, and there are now archeological remnants of various attempts to fix and/or simplify them. QuickTime-related frameworks are a lot more rational and usable than they used to be, but for those historical reasons they still play by a different set of rules.
I'm sorry that you've been through the wringer in getting up to speed on Cocoa. It's not your fault, and you've been a little bit unlucky. Take comfort that the worst of the nightmare is probably over.
_______________________________________________
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