Status Update
No update yet.
Comments
ap...@google.com
Hi, thanks for reporting this. Please update this ticket with a reproducible code/sample so we can better investigate the issue.
Thanks!
ap...@google.com
The endless joy of support tracker ....
So I'm actually asking a question ... So instead of insta closing without reading anyway to have someone read and answer?
What / Where are the settings that controls the velocity calculations.
Compose animations are tied to Android dev settings animation scale. What is the equivalent here.
ap...@google.com
Not all compose animations are tied to Android developer settings.
Fling animations in lists are no longer controlled by the Settings menu and cannot be overriden, so that shouldn't be source of the problem you're seeing. This has been solved in
The velocity calculation for lists is done at the draggable level and are also transparent to developers, so you cannot control how these are calculated.
A sample/reproducible code is required if I was to move forward with investigating this issue.
jb...@google.com
I don't have a repro and can't build one, the app is in prod and working for thousands of other users.
Is there any other changes in Compose 1.4 that could impact the velocity calculation?
Description
Version used: 1.2.0-rc01
The setRetainInstance() method of Fragments was originally the only way to retain state outside of overriding methods in the Activity. However, it ends up tightly coupling the retained state (which should not have any reference to the Context, Views, etc) with the full Fragment API, introducing such exciting combinations such as retained Fragments that also have a View or mixing retained and not retained Fragments together when using setTargetFragment(). This leads to lifecycle combinations that are much more complicated.
With the introduction of ViewModels, developers have a specific API for retaining state that can be associated with Activities, Fragments, and Navigation graphs. This allows developers to use a normal, not retained Fragment and keep the specific state they want retained separate.
This ensures that developers have a much more understandable lifecycle for those Fragments (one that matches all of the rest of their Fragments) while maintaining the useful properties of a single creation and single destruction (in this case, the constructor of the ViewModel and the onCleared() callback from the ViewModel).
We should deprecate the setRetainInstance() method and point developers to use ViewModel for storing their retained state.