Fixed
Status Update
No update yet.
Comments
il...@google.com
Actually, a multiplier of 8.67 gets me back to the approximate position it should be.
ch...@google.com
This bug was fixed in 2.1.1. Thanks for the report!
ch...@google.com
While the behavior has changed, it is still incorrect, IIUC. Now the view is shifted up too much for the values entered. For instance, when I enter a bottom inset of 200, which is less than half of the total height (509) of the map, and so should have no effect on the default centering behavior, the marker is actually centered at 354.5 points from the bottom, which is the center of the map plus half of the bottom inset. This seems incorrect per my understanding of that API.
il...@google.com
354.5 sounds exactly right to me.
il...@google.com
an...@gmail.com
Is there any update on this issue? It's been reported in March.
jb...@google.com
li...@gmail.com
Is there any progress or workaround?
This issue may trigger many chain reactions, e.g. LiveData observer's onChange never be called.
il...@google.com
Re #7 - this is being actively worked on in the
il...@google.com
A postponed fragment will never reach onResume() (part of the contract of a postponed fragment is that it can only go up to STARTED), so the example project needed to be changed to use onStart().
That being said, this has been fixed internally and will be avilable in Fragment 1.3.0-alpha08.
Note: this fix relies on using the
Description
Version used: 2.0.0
The fragment I use as my startDestination uses postponeEnterTransition() and startPostponedEnterTransition() for transition purposes. When my app is opened though, that fragment is never actually visible.
This is because the Fragment does *not* receive onStart() or onResume(), so my data source is never setup, so I do not call scheduleStartPostponedTransitions(). The last lifecycle callback I get is onViewCreated().
If I remove the call to postponeEnterTransition() then everything works as normal, except my transitions.