>
> 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
On Thu, Apr 30, 2009 at 10:50 AM, Tom Gibara 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 think that t
>
> 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 sta
On Apr 30, 10:10 pm, Marco Nelissen 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 unreliable.
Yes,
On Thu, Apr 30, 2009 at 10:06 AM, westmeadboy wrote:
>
> On Apr 30, 9:48 pm, Marco Nelissen 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 co
On Thu, Apr 30, 2009 at 9:46 AM, westmeadboy wrote:
>
> On Apr 30, 9:29 pm, Marco Nelissen 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
On Apr 30, 9:48 pm, Marco Nelissen 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 r
On Thu, Apr 30, 2009 at 9:33 AM, Tom Gibara 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 A
On Apr 30, 9:29 pm, Marco Nelissen 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 onStateChangedListener
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 exception
On Thu, Apr 30, 2009 at 8:55 AM, westmeadboy 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 of this
> State,
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 t
On Wed, Apr 29, 2009 at 11:18 PM, westmeadboy wrote:
>
> > > 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 p
> > 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 inheren
On Wed, Apr 29, 2009 at 8:22 AM, westmeadboy 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
> is in PAUSED or
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 cours
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
That's ok in a situation where you have very tight control over the
method calls to a MediaPlayer instance. However, in my case I have a
pool of MediaPlayer instances and so I need to know what the current
state of each one is before I can call any of those state-dependent
methods on it.
Of cours
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 cal
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 wrote:
> What do you mean by that
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 wrote:
>
>
21 matches
Mail list logo
