[APT-10128] Fixed the order of dispatched actions during seek related… #34
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… events Currently the order of the actions dispatched on a seeking action: Intial Seeking action (Skip distance, Prev chapter, seek position, etc.) Finish Seeking action because we immediately call exoplayer to seek to the new position and this triggers the Seek listeners with the current armadillo state without playback info being updated. Then dispatch PlaybackProgressAction with the new position that updates the armadillo state's playback info Instead we reverse the order of the finish seek action and PlaybackProgressAction so we are able to update the playback info progress before the finish seek occurs so it has the correctly updated playback info
kschults
approved these changes
Jun 6, 2024
griffinfscribd
deleted the
griffinf/APT-10128-update-seeking-playback-progress
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
… events
Currently the order of the actions dispatched on a seeking action:
Instead we reverse the order of the final seek action and PlaybackProgressAction so we are able to update the playback info progress before the finish seek occurs so it has the correctly updated playback info just before the listeners are triggered.
I also think that the PlaybackProgressAction order in the original code was likely misordered in the first place.
Normally, the PlaybackProgressAction gets fired a few times a second whether paused or playing that gets the exoplayer position, and updates the playback info progress with it. Having it run at the end of the sequence of events is redundant since it'll happen anyway. I think it might be that the intention was to use PlaybackProgressAction to update the playback info progress BEFORE the last finishing seek action is dispatched so it has the right progress that matches the finished seek position.
Changing this order now correctly sends the updated seek position to the audio player app for all the discontinuous jumps we make while paused and correctly saves the progress whether closing the audio player or force closing while paused.