On Thu, Apr 30, 2009 at 9:33 AM, Tom Gibara <m...@tomgibara.com> wrote:
> 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. > The problem with that is that the media engine doesn't run in your main thread. It runs in multiple other threads, in a different process. Synchronizing the two such that your app has completely knowledge and control over the current state would require blocking the engine thread(s) at some point, which would interfere with media playback. So, given that you can't always know the current state, you should code defensively and check return codes and exceptions. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
