On Thu, Apr 30, 2009 at 10:06 AM, westmeadboy <mjc1...@googlemail.com>wrote:
> > On Apr 30, 9:48 pm, Marco Nelissen <marc...@android.com> wrote: > > 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. > > That's not how I understand what Tom is saying... > > 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. So there is no need for any getState() method (although I personally > don't see the harm so long as the contract is clear). > > There is still the potential for the client code's understanding of > the State to become out-of-date but this is inevitable in a non- > synchronizable scenario such as this. Exactly, so you would still need to handle all the same error cases you might currently run in to, just using a different API. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
