Fixed
Status Update
Comments
il...@google.com <il...@google.com>
jb...@google.com <jb...@google.com> #2
Project: platform/frameworks/support
Branch: androidx-main
commit 4fc8470745f5b0f08f9531b7ab85eed6a8f424cb
Author: Jeremy Woods <jbwoods@google.com>
Date: Thu Jun 10 11:26:54 2021
Remove uses of titleCase in Safe Args
The titleCase API was added in Kotlin 1.5.0. Gradle versions previous to
7.0 relied on eariler versionss of Kotlin that do not have that API
available. SafeArgs now depends on Android Gradle Plugin 4.2.0, which is
compatible down to Gradle 6.7.1, so we should continue to support older
versions of kotlin until we move to the next stable version of AGP.
RelNote: "SafeArgs will no longer fail when building your app with
`Kotlin` versions before `1.5.0`."
Test: tested in sample app
Bug: 190739257
Change-Id: Icd1ff3c64f220f4b310934c2edf910d6aae01475
M navigation/navigation-safe-args-generator/src/main/kotlin/androidx/navigation/safe/args/generator/ext/String_ext.kt
M navigation/navigation-safe-args-generator/src/main/kotlin/androidx/navigation/safe/args/generator/java/JavaNavWriter.kt
M navigation/navigation-safe-args-generator/src/test/kotlin/androidx/navigation/safe/args/generator/NavArgumentResolverTest.kt
https://android-review.googlesource.com/1733983
Branch: androidx-main
commit 4fc8470745f5b0f08f9531b7ab85eed6a8f424cb
Author: Jeremy Woods <jbwoods@google.com>
Date: Thu Jun 10 11:26:54 2021
Remove uses of titleCase in Safe Args
The titleCase API was added in Kotlin 1.5.0. Gradle versions previous to
7.0 relied on eariler versionss of Kotlin that do not have that API
available. SafeArgs now depends on Android Gradle Plugin 4.2.0, which is
compatible down to Gradle 6.7.1, so we should continue to support older
versions of kotlin until we move to the next stable version of AGP.
RelNote: "SafeArgs will no longer fail when building your app with
`Kotlin` versions before `1.5.0`."
Test: tested in sample app
Bug: 190739257
Change-Id: Icd1ff3c64f220f4b310934c2edf910d6aae01475
M navigation/navigation-safe-args-generator/src/main/kotlin/androidx/navigation/safe/args/generator/ext/String_ext.kt
M navigation/navigation-safe-args-generator/src/main/kotlin/androidx/navigation/safe/args/generator/java/JavaNavWriter.kt
M navigation/navigation-safe-args-generator/src/test/kotlin/androidx/navigation/safe/args/generator/NavArgumentResolverTest.kt
jb...@google.com <jb...@google.com> #3
This is fixed internally and will be available in the the Navigation 2.4.0-alpha04
release.
ap...@google.com <ap...@google.com> #4
Still occurs in Version 2.4.0-beta02 with Gradle 6.9
il...@google.com <il...@google.com> #5
Still occurs in Version 2.4.0-beta02 with Gradle 6.9
Description
When using the new state manager released in fragment 1.3.0-alpha08, if you manually (without using the hide/show fragment transactions) set the visibility state of your view after the SpecialEffectsController has started any animations/transitions on your view, the visibility changes are ignored.
The reason this happens is because the new state manager saves the visibility state of the view in
onViewCreated()
as the final state and then restores that visibility state once the special effect completes afteronStart()
. This means that any changes made by the user to the view visibility state betweenonViewCreate()
andonStart()
are completely ignored.This becomes apparent in two particular cases:
There is a fragment that is always added, but has its visibility state updated based on some internal data (i.e. an error screen that is set to
View.INVISIBLE
when there is no error andView.VISIBLE
when there is one). If the view state changes toINVISIBLE
inonStart()
, the fragment should not be shown once the add transaction completes.A entering fragment is postponed and while it is postponed, its view visibility state is set to
View.INVISIBLE
. Even once the fragment is no longer postponed, its view should still beINVISIBLE
until the user changes it again manually.The new state manager should defer view visibility state control to the user no matter when the state is changed. Doing so would ensure that the user always has the source of truth for their Fragment's view visibility.