Fixed
Status Update
No update yet.
Comments
il...@google.com
jb...@google.com
Looks to be the same issue as https://github.com/androidannotations/androidannotations/issues/1208 where after being parceled and unparceled, the type swaps to Parcelable[] which is indeed a different type than CustomModel[]. The same thing can be seen with Fragment destinations if you:
1. turn on the Developer Option of "Don't keep activities"
2. Navigate to the Fragment destination (it won't crash)
3. Hit the home button
4. Use the recents button to relaunch the app (it will crash)
It seems like the only viable work around is to create a new array of the correct type (CustomModel[]), then System.arraycopy() the objects over. We can do this automatically as part of the Args class. We should also double check to see if this same problem exists with Serializable.
1. turn on the Developer Option of "Don't keep activities"
2. Navigate to the Fragment destination (it won't crash)
3. Hit the home button
4. Use the recents button to relaunch the app (it will crash)
It seems like the only viable work around is to create a new array of the correct type (CustomModel[]), then System.arraycopy() the objects over. We can do this automatically as part of the Args class. We should also double check to see if this same problem exists with Serializable.
jb...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 72631a760ebfb23990c42440d0c1f8c67fafe5ed
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Thu Feb 07 14:11:06 2019
Copy & Cast Parcelable array items when reading NavArgs from Bundle
Bundle#getParcelableArray() return Parcelable[] which NavArgs was
failing to cast to Item[] where Item is an app defined Parcelable. This
CL changes the generated code so that the Parcelable[] items are copied
into an array of the defined type in the nav graph.
This issue doesn't exist for Serializable since there is no
Bundle#getSerializableArray().
Bug: 123963545
Test: Manual test with sample app provided in issue.
Change-Id: Ibfcb703a1ad48929a0731b82a13a1f33813187b5
M navigation/safe-args-generator/src/main/kotlin/androidx/navigation/safe/args/generator/java/JavaTypes.kt
M navigation/safe-args-generator/src/main/kotlin/androidx/navigation/safe/args/generator/kotlin/KotlinTypes.kt
M navigation/safe-args-generator/src/tests/test-data/expected/java_nav_writer_test/MainFragmentArgs.java
M navigation/safe-args-generator/src/tests/test-data/expected/kotlin_nav_writer_test/MainFragmentArgs.kt
https://android-review.googlesource.com/898454
https://goto.google.com/android-sha1/72631a760ebfb23990c42440d0c1f8c67fafe5ed
Branch: androidx-master-dev
commit 72631a760ebfb23990c42440d0c1f8c67fafe5ed
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Thu Feb 07 14:11:06 2019
Copy & Cast Parcelable array items when reading NavArgs from Bundle
Bundle#getParcelableArray() return Parcelable[] which NavArgs was
failing to cast to Item[] where Item is an app defined Parcelable. This
CL changes the generated code so that the Parcelable[] items are copied
into an array of the defined type in the nav graph.
This issue doesn't exist for Serializable since there is no
Bundle#getSerializableArray().
Bug: 123963545
Test: Manual test with sample app provided in issue.
Change-Id: Ibfcb703a1ad48929a0731b82a13a1f33813187b5
M navigation/safe-args-generator/src/main/kotlin/androidx/navigation/safe/args/generator/java/JavaTypes.kt
M navigation/safe-args-generator/src/main/kotlin/androidx/navigation/safe/args/generator/kotlin/KotlinTypes.kt
M navigation/safe-args-generator/src/tests/test-data/expected/java_nav_writer_test/MainFragmentArgs.java
M navigation/safe-args-generator/src/tests/test-data/expected/kotlin_nav_writer_test/MainFragmentArgs.kt
ap...@google.com
This is fixed internally and will be available in Navigation 1.0.0-beta02
il...@google.com
This has been fixed internally and will be available in the next release of Fragments.
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.INVISIBLEwhen there is no error andView.VISIBLEwhen there is one). If the view state changes toINVISIBLEinonStart(), 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 beINVISIBLEuntil 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.