[APT-10128] Update Reducer logic to copy seek position to playbackinfo

[griffinfscribd]

Jira ticket

https://scribdjira.atlassian.net/browse/APT-10128

Description

Bug:
When the audio player is paused and the user performs some combination of audio controls (seeking, chapter jumping, skip fwd back, etc), then force closes the app. The progress is updated, but is not the latest and is not correct. While in the paused state, the user would likely be losing their latest listening progress. This differs from the user closing the audio player in-app because in that scenario, the progress is correctly saved.

Explanation:
After much digging, when the audio player performs some audio control, say Seek, it would trigger the armadillo player to dispatch a Seek Action and the Reducer would update the armadillo state to be emitted to the listeners for said action.

Currently in the Scribd app, whenever the action listener would receive the armadillo state, it would look into PlaybackInfo.progress.positionInDuration. If you look at the Reducer in the armadillo player library, you can immediately see that the playbackinfo is not updated, only the controlstate, which is why when we are saving the progress, the progress is not updated to what it should be after performing the media control action. It would make sense to update the playbackinfo following these skips, seeks, etc. since prior to the emission, the exoplayer's position is already updated to where we are skipping.

Fix:
Update reducer to update the playbackinfo progress in terms of position and chapter index (we may be able to jump to the next or previous chapter). Now when paused and jumping around the audio, the progress is correctly save the same way whether we close the audio player in-app or force close.

Testing considerations

Introduced unit tests
Regression around audio controls (skip fwd, back, seek, jump to chapter, etc.) leading to progress saved while playing or paused.

Checklist

• Prefixed the PR title with the JIRA ticket code
• Performed simple, atomic commits with good commit messages
• Verified that the commit history is linear and commits are squashed as necessary
• Thoroughly tested the changes
• The appropriate complexity label (Low, Medium, High) is added to this PR
• Test Coverage of changes (if applicable)
• Updated the README.md as necessary
• I have confirmed and checked all of these boxes

Related links

• #XYZ
• JIRXXX
• Design Document
• Slack discussion

[kschults]

For most of these, I think seekPositionTarget should really be non-null. It's only used in SeekAction to resolve the end of a seek. Can you make it non-null for all the other actions where it's never actually null?

[griffinfscribd]

Did not notice that. Sure, I can make that change.

[kschults]

I guess the question to ask is "Should we consider the user at the new position when they start a discontinuous action like seeking or jumping?" I feel like the answer should be "no", but I'm willing to be convinced it makes sense.

How does the scrubber/UI get updated if you jump while paused? Can we hitch the progress update into whatever makes that update?