Fix #1801: Audio player running after closing

[KevinGitonga]

Explanation

Fix #1801
This fix adds check in the implemented playStatusLiveData to complete audioPause request if any is pending while the playerStatus keeps changing. When user clicks on pause audio icon and the UI disappears there is a delay in audio actually pausing. Adding a check in playStatusLiveData completes pause pending request fast enough to prevent it from playing.

Essential Checklist

• The PR title and explanation each start with "Fix #bugnum: " (If this PR fixes part of an issue, prefix the title with "Fix part of #bugnum: ...".)
• Any changes to scripts/assets files have their rationale included in the PR explanation.
• The PR follows the style guide.
• The PR does not contain any unnecessary code changes from Android Studio (reference).
• The PR is made from a branch that's not called "develop" and is up-to-date with "develop".
• The PR is assigned to the appropriate reviewers (reference).

For UI-specific PRs only

If your PR includes UI-related changes, then:

• Add screenshots for portrait/landscape for both a tablet & phone of the before & after UI changes
• For the screenshots above, include both English and pseudo-localized (RTL) screenshots (see RTL guide)
• Add a video showing the full UX flow with a screen reader enabled (see accessibility guide)
• Add a screenshot demonstrating that you ran affected Espresso tests locally & that they're passing

Before changes demo

20220928_111629.mp4

After changes demo

20220928_112012.mp4

[BenHenning]

Thanks @KevinGitonga. I can see this conceptually working (though per the videos it seems like it does functionally work), but I think some clarity is needed into why this particular approach works since it doesn't seem to exactly be "throttle control" for pausing per my comment.

Once we finalize the solution, I think you can go ahead with writing tests. That being said, until then you should consider marking this PR as 'Draft' since it isn't technically complete yet (and thus not ready for a full review).

[oppiabot]

Hi @KevinGitonga, I'm going to mark this PR as stale because it hasn't had any updates for 7 days. If no further activity occurs within 7 days, it will be automatically closed so that others can take up the issue.
If you are still working on this PR, please make a follow-up commit within 3 days (and submit it for review, if applicable). Please also let us know if you are stuck so we can help you!

[oppiabot]

Hi @KevinGitonga, I'm going to mark this PR as stale because it hasn't had any updates for 7 days. If no further activity occurs within 7 days, it will be automatically closed so that others can take up the issue.
If you are still working on this PR, please make a follow-up commit within 3 days (and submit it for review, if applicable). Please also let us know if you are stuck so we can help you!

[KevinGitonga]

Hi @BenHenning yet to assert this in tests as it seems complex on grounds that the AudioPlayer is restarted when the user clicks on continue button to proceed to the next lesson in the Exploration, Also not able to find a suitable way to invoke ShadowMediaPlayer for this context. The cause of Audio Playing after the user clicks the pause button while playing on a given exploration might be caused by the below issue [1].

[1]. After observing my logs data the audio player continues to play since the audio player is not in a “prepared” state. This state is checked as noted here before actually performing a pause through the audioPlayerController in AudioViewModel here. The pause will be skipped as the player is not in a “prepared” state hence why audio will continue to play once the state changes to prepared here which is the expected behavior. This is despite the player ui fragment being hidden.

The solution which works for this issue is to insert an if statement to check if a previous pause request exists as the state changes inside of this observer directly and if at the moment we have a pending request which was not executed when pauseAudio was initially invoked here. This will work if only the state is “prepared” and we have a “pending” request to pause the audio player. Kindly PTAL and advice your thoughts on this.

[BenHenning]

Thanks for the write-up @KevinGitonga. As discussed during the meeting earlier, I think the next steps here are carefully documenting the solution & why the code works/shouldn't change if we can't actually verify this in a test.

[KevinGitonga]

Thanks @BenHenning

After observing my logs data the audio player continues to play since the audio player is not in a “prepared” state. This state is checked as noted here before actually performing a pause through the audioPlayerController in AudioViewModel here. The pause will be skipped as the player is not in a “prepared” state hence why audio will continue to play once the state changes to prepared here which is the expected behavior. This is despite the player view fragment being hidden.

The solution which works for this issue is to insert an if statement to check if a previous pause request exists as the state changes inside of this observer directly and if at the moment we have a pending request which was not executed when pauseAudio was initially invoked here. This will work if only the state is “prepared” and we have a “pending” request to pause the audio player.

The main reasons why this fix cannot be checked through tests in platforms available is because of system constraint's in testing audio. I could also not come up with a suitable way to test this after researching how to undertake this. For this scenario we would require to listen the state of audio or check the state of the player buttons which would not be applicable since the audio player view itself has already been hidden from the UI as part of the pause process.

I have added comments and links to this comments and the issue itself in the code to assist other developers understand the reasons for the checks.

[BenHenning]

Thanks @KevinGitonga! Left one follow-up comment, otherwise the PR LGTM. PTAL.

[BenHenning]

Thanks @KevinGitonga. I think you missed responding to the comment thread, but otherwise the PR LGTM.

[oppiabot]

Unassigning @BenHenning since they have already approved the PR.