I have to agree with this. The MediaPlayer API is extremely hard work for precisely the reason that it expects client-code to maintain state that it can't reasonably be expected to know.
At the crux of the problem is the fact that the API is strict about the valid transitions by throwing exceptions when invalid state changes are attempted. This is fundamentally the wrong design for this API for the reasons given above: that the MediaPlayer transitions can be asynchronous to application flow. In my opinion a much better approach would be to model the API properly around a state engine, eg. with a setState() method which doesn't throw exceptions but returns the new state so that failure to transition can be detected. Combined with a state listener mechanism and a setStateAsync() method, I feel I'd have all the 'tools' I needed to produce much more robust media applications. Perhaps something like this could be retrofitted in the future. Tom On Apr 30, 2009 7:18 AM, "westmeadboy" <mjc1...@googlemail.com> wrote: > > Do you know why the State is not exposed? If there is no good reason, > > then what are the ste... I don't understand this. Are you saying that if the application keeps track of the State then this is more accurate than if it had access to the underlying State? Before I call pause() I potentially need to check that the player is not in one of these modes: Idle, Initialized, Prepared, Stopped, PlaybackCompleted, Error otherwise the errorListener is triggered. Idle, Initialized and Stopped are completely in my control (and so is Preparing, once the MediaPlayer has been Prepared) so the only ones I really need to check for are PlaybackCompleted and Error. So, as in your example, any call to pause() may result in the errorListener being triggered because the MediaPlayer can suddenly enter PlaybackCompleted State just before onCompletionListener has had a chance to be triggered. So, it seems to me that the MediaPlayer API is broken because there is no clear contract for the client code. It details the valid states under which the various methods can be called but does not allow this State to be known, only guessed. If you are concerned about the State changing from one client code statement (testing State) to the next (invoking a method such as pause()) then isn't this what synchronization is for? Furthermore, if you don't want client code relying on the State then why is isPlaying() provided? Doesn't this just test if the State is Started? I would have expected something like onStateChangedListener and using synchronization to avoid the problem you mentioned. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subs... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
