Add sliding animated transition when opening/closing the attachment keyboard #14351
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
added 22 commits
March 28, 2025 02:57
There was a ConstraintLayout that wrapped another ConstraintLayout and had no other siblings. I removed it, recompiled, and it worked, so I figure it's not necessary. This improves performance.
RecyclerView introduces excessive boilerplate for a container whose size is roughly fixed at a small number and is generally expected to not need recycling to be done. A simple horizontal LinearLayout wrapped in a HorizontalScrollView for good measure simplifies the code and reduces weird interactions with the recycler when the attachment keyboard is resized as part of the smooth open/close animation that I am adding.
When we remove the fake keyboard fragment, use an animated transition to make it look less choppy. Also don't forcibly end the smooth transition for the fake keyboard unless the animation is actually in progress. This prevents erroneously setting the keyboard guideline to an obsolete value if it was moved by the built-in IME animation in between.
- Keep some useful ones, delete some less useful ones - Convert levels from warn to debug
This makes things look a tad bit nicer, and mimics the behaviour of the keyboard pager toggle button. (The keyboard pager toggle button doesn't have an animation yet, but at least it changes its presentation depending on whether or not the keyboard pager is open or not).
- Make recentering algorithm more concise - Make Kotlin code more idiomatic - Remove hard-coded values from recentering algorithm - Recenter when the buttons' container changes too, not just when the number of buttons changes. This fixes a bug where the buttons would not be centered after changing the device orientation while the buttons are open.
300 is just a tad too long compared to the Android OS actual duration for the IME show/hide animation.
It worked on my emulator but not my physical device :( Maybe it's because my emulator is slower than my physical device? Either way, I hope this fixes things... - Simplify recentering algorithm - Do not re-layout the attachment keyboard buttons if the app tries to set the same set of buttons - Make things more readable - Make Kotlin code more idiomatic - Add logging - Post recentering requests to hopefully fix it on my physical device - Simplify call hierarchy for recentering Request a recenter when the wrapper's width changes or when we add/remove buttons from the button list. If you think about it, nothing else is required.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
First time contributor checklist
Contributor checklist
Fixes #1234syntaxDescription
This pull request makes the attachment keyboard feel more modern and fun to use.
smooth-before.webm
smooth-after.webm
recenter-before.webm
recenter-after.webm