Fix FAB position not persisting and resetting on control panel visibility changes - #804
Open
khanhtrancc wants to merge 1 commit into
Open
Fix FAB position not persisting and resetting on control panel visibility changes#804khanhtrancc wants to merge 1 commit into
khanhtrancc wants to merge 1 commit into
Conversation
This file contains hidden or 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
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.
Problem
The Menu/Back floating action button (FAB) has two positioning bugs:
app restart / view recreation, always reverting to the XML-defined
default (bottom-end, above the control panel).
(
control_panel) shows or hides during playback. The FAB isconstrained via
app:layout_constraintBottom_toTopOf="@id/control_panel",so toggling that view's visibility makes ConstraintLayout re-solve all
constraints and snap the FAB back to its anchor position, discarding
the drag offset (which was only ever applied via
setX/setY, neverreflected in layout params).
Fix
Save the dragged position as a fraction (0–1) of the available drag
range, rather than raw pixels, and restore it on every layout pass:
posX/posYfractions via a small dedicatedSharedPreferenceStore, using the samePreferenceStore/Prefabstraction already used elsewhere in the codebase (e.g.
MainActivityPrefs's percentage-based prefs).ACTION_MOVE) into a sharedgetDragBounds()helper, reused forclamping, saving, and restoring.
ACTION_UPafter a real drag.onLayout()override, which fires both on viewrecreation and on control-panel visibility changes — and is skipped
while a drag is in progress so it can't fight the user's finger.
If the button was never dragged, the fraction stays unset and behavior
is unchanged (default constraint-defined position).
Scope
Change is fully contained to
depends/utils/src/main/java/me/aap/utils/ui/view/FloatingButton.java.