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?
On Tue, Apr 28, 2009 at 10:57 PM, westmeadboy <mjc1...@googlemail.com>wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
