On Apr 30, 10:10 pm, Marco Nelissen <marc...@android.com> wrote: > It might make it easier for you to retrieve an unreliable bit of > information, but you would still have to deal with all the same exceptions > and other errors that you can run in to now, precisely because the state > information is unreliable.
Yes, I know - this point about unreliable information was something you brought up to justify not exposing the state - its not the original point of this thread which is to do with the difficulty of having the client-code keeping track of what it thinks the state probably is. > In some cases, it's not a > problem to ensure that MediaPlayer is in a certain state. For example, if > you call prepare(), and it succeeds, then MediaPlayer is in the 'prepared' > state, and it won't suddenly 'unprepare' itself. In other cases, in > particular once you've started playback, it's not so clear cut. For example, > once you call start(), MediaPlayer will transition to the 'playing' state, > but it can drop out of that state at any time, for a number of reasons (such > as an error during playback, or reaching the end of the file). Yes, I mentioned all this earlier when I said "the only ones I really need to check for are PlaybackCompleted and Error". By the way, its extremely bad practice to use exceptions for normal flow control. The "unreliable" situations you describe can be seen as exceptional circumstances. The API at the moment is almost encouraging the client code to use this anti-pattern. On Apr 30, 10:24 pm, Marco Nelissen <marc...@android.com> wrote: > > 1. setState() is like a generic method call used in place of methods > > like prepare(), pause(), start(), stop() etc. > > 2. This method returns the new state rather than triggering the error > > listener. > > 3. I suppose setStateAsync() would not return anything, but would > > > potentially trigger a state change event. > > 3. The state change listener is there to inform client code of state > > changes not caused by calls to setState(). So maybe an > > OnStateAsyncChangedListener. > > That's only a cosmetic change though. Instead of calling, say, prepare() and > it throwing an exception, you now have it return some token that tells you > whether or not it succeeded. It doesn't really give you any extra > functionality or information. True, there's not any new functionality - its just a much easier API to deal with. All of this can be achieved by "decorating" the MediaPlayer - but that in itself is messy. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
