Do you know why the State is not exposed? If there is no good reason,
then what are the steps to request that it is exposed in some future
SDK release?
One reason not to rely on these, and not to expose them so that people don't
try to rely on them, is that the states are inherently
On Wed, Apr 29, 2009 at 11:18 PM, westmeadboy mjc1...@googlemail.comwrote:
Do you know why the State is not exposed? If there is no good reason,
then what are the steps to request that it is exposed in some future
SDK release?
One reason not to rely on these, and not to expose them
OK, so you said one reason the State is not exposed is because you
don't want client code relying on these States because they are
inherently transient.
However, the alternative is for the client code to keep track of this
State, which is no better in this regard.
Is there another reason not to
On Thu, Apr 30, 2009 at 8:55 AM, westmeadboy mjc1...@googlemail.com wrote:
OK, so you said one reason the State is not exposed is because you
don't want client code relying on these States because they are
inherently transient.
However, the alternative is for the client code to keep track
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
On Apr 30, 9:29 pm, Marco Nelissen marc...@android.com wrote:
No, the fact that a getState() method would be unreliable is reason enough
not to have one.
Its no less reliable then any other call to any non-synchronized
getter method and there are plenty of those in the Android SDK.
An
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
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
On Thu, Apr 30, 2009 at 9:46 AM, westmeadboy mjc1...@googlemail.com wrote:
On Apr 30, 9:29 pm, Marco Nelissen marc...@android.com wrote:
No, the fact that a getState() method would be unreliable is reason
enough
not to have one.
Its no less reliable then any other call to any
On Thu, Apr 30, 2009 at 10:06 AM, westmeadboy mjc1...@googlemail.comwrote:
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
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
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.
That's only a cosmetic change if you think that throwing an exception is a
first-class way of returning state;
On Thu, Apr 30, 2009 at 10:50 AM, Tom Gibara m...@tomgibara.com wrote:
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.
That's only a cosmetic change if you
Define 'meaningful'.
In this context: process state is meaningful to me if its exposed in a
form that I can reason about competently.
I would find it easier to reason about the state of the media player as
exposed by the type of API I described above than that exposed by the API at
present.
But you do have very tight control over the method calls to those
MediaPlayers, since they're in your code.
You didn't say what exactly you're trying to do, but it in general, you
should just call setDataSource() immediately followed by prepare(), and then
you're ready to play. If you ever need to
The documentation lists 10 different states and while I could probably
reduce the number relevant to me to about 4 or 5, that doesn't help
enough.
One example of where this is important is knowing whether the player
is in PAUSED or STOPPED mode. pause() cannot be called in STOPPED
mode.
Of
On Wed, Apr 29, 2009 at 8:22 AM, westmeadboy mjc1...@googlemail.com wrote:
The documentation lists 10 different states and while I could probably
reduce the number relevant to me to about 4 or 5, that doesn't help
enough.
One example of where this is important is knowing whether the player
What do you mean by that? If you want to know if it's playing, call
MediaPlayer.isPlaying(). If you want to know how far along it is, call
MediaPlayer.getCurrentPosition(). Are those kinds of things you're looking
for, or something else?
On Tue, Apr 28, 2009 at 11:06 AM, westmeadboy
No, I mean the states described in the documentation: IDLE,
INITIALIZED, PREPARED etc
At the moment, I do not know whether I can call prepare without
getting an exception. prepare() can only be called in certain Valid
states.
On Apr 29, 12:00 am, Marco Nelissen marc...@android.com wrote:
What
You can't get that state directly, but you can infer what state the
MediaPlayer is in by whether or not you have successfully called the methods
you need to call to get into a state. For example, if you call
MediaPlayer.setDataSource(), and it succeeds, then you will be in the
correct state for
20 matches
Mail list logo
