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. 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? On Apr 29, 7:52 pm, Marco Nelissen <marc...@android.com> wrote: > But you do have very tight control over the method calls to those > MediaPlayers, since they're in your code. > You didn't say what exactly you're trying to do, but it in general, you > should just call setDataSource() immediately followed by prepare(), and then > you're ready to play. If you ever need to change the sound, you call > reset(), setDataSource() and prepare() again, and you're again ready to > play. Is there a specific reason that you might want to leave a MediaPlayer > in some half-initialized state? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
