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. 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. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
