On Wed, Apr 29, 2009 at 11:18 PM, westmeadboy <mjc1...@googlemail.com>wrote:
> > > > Do you know why the State is not exposed? If there is no good reason, > > > then what are the steps to request that it is exposed in some future > > > SDK release? > > > > One reason not to rely on these, and not to expose them so that people > don't > > try to rely on them, is that the states are inherently transient, because > > they ultimately come from the media engine, which runs in its own > thread(s). > > I don't understand this. Are you saying that if the application keeps > track of the State then this is more accurate than if it had access to > the underlying State? > > Before I call pause() I potentially need to check that the player is > not in one of these modes: > > Idle, Initialized, Prepared, Stopped, PlaybackCompleted, Error > > otherwise the errorListener is triggered. > > Idle, Initialized and Stopped are completely in my control (and so is > Preparing, once the MediaPlayer has been Prepared) so the only ones I > really need to check for are PlaybackCompleted and Error. > > So, as in your example, any call to pause() may result in the > errorListener being triggered because the MediaPlayer can suddenly > enter PlaybackCompleted State just before onCompletionListener has had > a chance to be triggered. > > So, it seems to me that the MediaPlayer API is broken because there is > no clear contract for the client code. It details the valid states > under which the various methods can be called but does not allow this > State to be known, only guessed. If you are concerned about the State > changing from one client code statement (testing State) to the next > (invoking a method such as pause()) then isn't this what > synchronization is for? No, synchronization won't help. To make your hypothetical getState() method work reliably, you would have to essentially lock the MediaPlayer and prevent further state changes to ensure that the state doesn't change again while you process the result of getState(). But that would mean blocking the underlying media playback engine as well (since that is ultimately the source of the state changes), and you can't just go and block the media engine because it could cause glitches. Furthermore, if you don't want client code relying on the State then > why is isPlaying() provided? Doesn't this just test if the State is > Started? isPlaying() is mainly a convenience for applications that want to implement a play/pause toggle, so they can do something like: if (mp.isPlaying()) mp.pause(); else mp.start(); We should probably deprecate isPlaying() and provide a better way of doing this. I would have expected something like onStateChangedListener and using > synchronization to avoid the problem you mentioned. Again, synchronization is not going to help. The best you can do is keep track of errors and other events, and catch the exceptions that can be thrown when calling MediaPlayer methods. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
