That's ok in a situation where you have very tight control over the method calls to a MediaPlayer instance. However, in my case I have a pool of MediaPlayer instances and so I need to know what the current state of each one is before I can call any of those state-dependent methods on it.
Of course, I can work around this by using the decorator (?) pattern, working out what the state *should* be based on which methods were called and what exceptions were thrown and whether the error handler was called. But this is all messy and bound to result in my calculated state getting out of line with the real internal state. Is there any reason not to expose the underlying state? On Apr 29, 8:29 am, Marco Nelissen <marc...@android.com> wrote: > You can't get that state directly, but you can infer what state the > MediaPlayer is in by whether or not you have successfully called the methods > you need to call to get into a state. For example, if you call > MediaPlayer.setDataSource(), and it succeeds, then you will be in the > correct state for calling prepare(), and if you then call prepare(), and it > succeeds, you will be in the PREPARED 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 -~----------~----~----~----~------~----~------~--~---
