Status Update
Comments
ma...@googlemail.com <ma...@googlemail.com> #2
Hi samsadch,
In the AndroidX PDF library, the search view is animated using the
Without this, the callback might be consumed at an upper level, preventing it from being received by the PdfViewerFragment's container.
ch...@target.com <ch...@target.com> #3
Actually the search view is coming but the issue is that it is showing below the Keyboard
ma...@googlemail.com <ma...@googlemail.com> #4
Still there
jo...@gmail.com <jo...@gmail.com> #5
Hey Samsad,
It seems your concern is that the search view remains behind the keyboard when it's open, instead of being positioned below it.
As mentioned in my earlier comment
For reference, you can see the search view translation logic
To resolve this, please ensure that the view hierarchy containing the PdfViewerFragment allows insets to propagate down the view hierarchy.
em...@gmail.com <em...@gmail.com> #6
Like the comment above, throttling from the Loading State to the Show data State makes no sense in either driving or parked mode.
Description
Library version used: 1.4.0 Devices/Android versions reproduced on: Automotive Emulator / Android 11 Android Auto version reproduced on: AAOS, Car App Host 1.007.648520300.01-x86_64
Since a recent update to the Car App Host, screen updates seem to be getting debounced quite aggressively. For example, I have many screens that first load some data (using
setLoading(true)
to show the progress bar) and then callinvalidate()
once loading has finished. In this case, it often takes about 10 more seconds after theinvalidate()
call untilonGetTemplate()
gets called and the screen is updated. This delay doesn't occur every time, but pretty often - especially after user actions (e.g. switching between different screens).This debouncing artificially slows down the app to the point where users complain that it feels sluggish. It also makes it pretty much impossible to display any data with real-time updates.