Status Update
Comments
fl...@google.com <fl...@google.com> #2
Jeremy, is this still an issue? I think the problem was that you had two transitions targeting the same View for the same action (e.g. two Slide() transitions).
ap...@google.com <ap...@google.com> #3
I have a similar issue with plain AnimatorSet:
set.start()
set.pause()
set.setCurrentPlayTime(100)
set.setCurrentPlayTime(0)
set.setCurrentPlayTime(100)
set.resume()
doesn't play animation in resume().
ap...@google.com <ap...@google.com> #4
Should clarify that if I filter out setCurrentPlayTime(0)
(or replace it with setCurrentPlayTime(1)
) it works well.
Also even with setCurrentPlayTime(0)
, onAnimationEnd
is notified with correct delay (as if the animation has played).
ro...@google.com <ro...@google.com> #5
@
I think that is intended for Animator. If you set the currentPlayTime
to 0 or the total duration the animator completes. We do some
fl...@google.com <fl...@google.com> #6
Did some investigation on the Fragment side and it seems like the merged transition is targeting correctly.
Exiting Transition: Slide@aa9288e: tgts(android.widget.LinearLayout{f9add3d})
>>>>> ExitingViews <<<<<
View: android.widget.LinearLayout{f9add3d}
Entering Transition: Slide@35b8af: tgts(android.widget.LinearLayout{b7f24bc})
>>>>> EnteringViews <<<<<
View: android.widget.LinearLayout{b7f24bc}
Final merged transition: TransitionSet@7bc1c45:
TransitionSet@e133f9a:
Slide@aa9288e: tgts(android.widget.LinearLayout{f9add3d})
Slide@35b8af: tgts(android.widget.LinearLayout{b7f24bc})
merged transition passed to controlDelayedTransition: TransitionSet@7bc1c45:
TransitionSet@e133f9a:
Slide@aa9288e: tgts(android.widget.LinearLayout{f9add3d})
Slide@35b8af: tgts(android.widget.LinearLayout{b7f24bc})
Still digging.
Description
DataStore Component used: Proto DataStore (but behaviour should be common to Preferences as well given the scenario mentioned below)
DataStore Version used: rc01
Devices/Android versions reproduced on: all
Consider the following scenario: In SharedPreferences we have preference with key A saved. The app supports a preference with key B as well, but the user didn't get to the screen in the app where that is actually saved, therefore SharedPreferences is missing key B.
We implement a
SharedPreferencesMigration
, using the defaultMIGRATE_ALL_KEYS
option and callsharedPreferencesView.get...(key = B)
to define the mapping between SharedPrefs and DataStore. When migrating, we get "Can't access key outside migration".MIGRATE_ALL_KEYS
creates a set of keys containing just key "A", as this was the only one set by the user. The solution to this is to manually define the list of keys to be migrated.But, this is counter-intuitive to the
MIGRATE_ALL_KEYS
flag, as it assumes that all the keys are already saved in SharedPreferences.