Fixed
Status Update
No update yet.
Comments
jb...@google.com
ap...@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.
ap...@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
jb...@google.com
This is fixed internally and will be available in Navigation 1.0.0-beta02
Description
Component used: Activity
Version used: 1.7.2
As explained
OnBackPressedCallbackfor non-UI cases (for example, just for logging back). If you add a callback, you have to handle back completely in your callback.That means that calling
remove()and triggering back viarequireActivity.onBackPressed()oronBackPressedDispatcher.onBackPressed()is always an anti-pattern and something that you should not do.It would be helpful if there was a Lint error that specifically catch this case and warn developers ahead of time that this is the wrong thing to do and offer alternatives or at least link to the guide for more information.