> > 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? 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? I would have expected something like onStateChangedListener and using synchronization to avoid the problem you mentioned. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
