Question

Assume two threads: my thread, and the MediaPlayer thread (which sends
messages to me through a looper). My game thread reacts to user input:
if the user pauses gameplay, I call MediaPlayer.pause() as well.

Consider the following order of events:

1. A MediaPlayer audio stream reaches its end, so it enqueues an
   OnCompletion message to me
2. My thread: MediaPlayer.pause() called due to user action
3. I receive the OnCompletion call (too late, pause() was already
   called above)

The problem with this is that MediaPlayer.pause() is only allowed in
PAUSED and STARTED state, but due to Step 1, the MediaPlayer will
already be in PlaybackCompleted state when pause() is called. I see
two solutions:

1. Catching exception
2. asking MediaPlayer.isPlaying() before calling pause()

But the second solution has a problem in the following scenario:

1. Game started, MediaPlayer.start() called, but mediaplayer state is
   not yet STARTED
2. User leaves gameplay, calling the code: if(isPlaying()) pause();
3. MediaPlayer enters STARTED state (now isPlaying would return true,
   but too late)

The problem here is that isPlaying() will still return false (as the
docs say too), so the MediaPlayer will still start due to step 3.

Is there a solution which is correct and avoids exceptions in both cases? (Or are there any mistakes in my above train of thought?)

---

Update

Reacting to Geobits’ answer (I do it here because I’ll quote from Android doc):

Yes, I’m also doing local playback, tested it a lot just like you, and everything looked fine. But the documentation is a bit self-contradicting. The first part (this is OK):

Calling start() to resume playback for a paused MediaPlayer object,
and the resumed playback position is the same as where it was paused.
When the call to start() returns, the paused MediaPlayer object goes
back to the Started state.

And another quote from the same page:

Playback can be paused and stopped, and the current playback position
can be adjusted. Playback can be paused via pause(). When the call to
pause() returns, the MediaPlayer object enters the Paused state. Note
that the transition from the Started state to the Paused state and
vice versa happens asynchronously in the player engine. It may take
some time before the state is updated in calls to isPlaying(), and it
can be a number of seconds in the case of streamed content.

This latter one says that also when starting a paused player, the state change may take time (“vice versa”). So far so good, because it only applies to the internal player engine, but then comes the crazy part: “It may take some time before the state is updated in calls to isPlaying()”. This implies that isPlaying() isn’t returning the OBSERVABLE state, instead it depends on the internal state. This is confusing.

Answer 1

I’ve done a few apps with MediaPlayer, and used if(isPlaying()) pause(); each time with no bad effects. That’s with local media, though. If you’re streaming the latency might actually cause the second type of problem.

Try it out and see if you can break it. If you can’t, it’s nothing to worry about. If you can, you can always work around it. Setting a boolean when you call start(), queuing the pause, I’m sure there’s other methods I’m not thinking of.

But try it out first. It behaves well for me, and I’ve playtested the crap out of mine.