On Wed, Apr 29, 2009 at 8:22 AM, westmeadboy <[email protected]> wrote:

>
> The documentation lists 10 different states and while I could probably
> reduce the number relevant to me to about 4 or 5, that doesn't help
> enough.
>
> One example of where this is important is knowing whether the player
> is in PAUSED or STOPPED mode. pause() cannot be called in STOPPED
> mode.


But shouldn't your app know whether it is paused or stopped, based on
whether it paused or stopped the mediaplayer prior to this?

Of course, like I said, I can use the decorator pattern to do this
> "tight control" to monitor the State but I feel like it makes way more
> sense for the player's State to be exposed.
>
> 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).
Suppose for example that there was a method to ask for the current state,
and that that method told you that the current state is 'started'. That only
tells you that that was the state at the specific point in time where you
sampled it. There is no guarantee that the state is still the same by the
time your code looks at this returned state or acts on it. For example,
playback might have reached the end by then, so you're now in the 'playback
complete' state. Or an error might have been encountered since then, so
you're now in an 'error' state.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to