Status Update
Comments
st...@gmail.com <st...@gmail.com> #2
For reference, my class looked like
data class SomeDestination(val sections: List<CustomTypeWhichIsSerializableButNotProvidedInTypeMap>)
So it just told me about the fact that it did not know how to work with it, but not where to find where the problem was besides somewhere inside my NavGraphBuilder.homeGraph lambda, which in some cases may contain tens of destinations that one would have to go through to check.
il...@google.com <il...@google.com> #3
The exception did say
Cannot cast sections of type kotlin.collections.ArrayList
E.g., it told you exactly what field of what type was causing the exception. Was there more information you were looking for? E.g., SomeDestination
?
st...@gmail.com <st...@gmail.com> #4
The issue was mostly that the stacktrace was pointing at the entire function like here sections
was missing its types.
So what is actionable for me in this context since it does not actually tell me which destination that is, is to go through all of my destinations one by one, jump inside their type and find the one which has a field named sections
and has some sort of List<*> in there.
Then after I've found it, if I potentially have more than one destination with a field named sections
which has a list of something, then I don't actually know which one it was, so I need to edit something, run again, and notice if the crash stacktrace has changed or not.
I understand that one can end up finding what the issue is and where it is provided enough effort and that their graph is not huge, but optimally this should be much simpler than that.
Out of curiosity, what is it that makes the stacktrace point at the wrong lines of code?
jb...@google.com <jb...@google.com>
ap...@google.com <ap...@google.com> #5
Branch: androidx-main
commit c2f42d17627d19ad4de6121a098a0e8f463aeff4
Author: Clara Fok <clarafok@google.com>
Date: Tue Sep 17 20:38:29 2024
Improve unknown NavType exception message
RouteSerializer.computeNavType throws an IllegalArgumentExcpetion when it fails to map a route argument to a NavType.
To provide an exception with more specific details, the two direct callers of `RouteSerializer.computeNavType` will now catch the exception and throw a different IllegalArgumentExcpetion with a message that contains:
1. argument name
2. arugment fqn
3. route fqn
Test: ./gradlew navigation:navigation-common:cc
Test: ./gradlew navigation:navigation-compose:cC
Bug: 346264232
Relnote: "When Navigation fails to map a route's argument to a NavType, the new error message will contain the argument name, argument fully qualified name, and the route's fully qualified name."
Change-Id: Id84161f47630fe76d85af01bb06c7f3a13d372bb
M navigation/navigation-common/src/androidTest/java/androidx/navigation/NavDestinationBuilderTest.kt
M navigation/navigation-common/src/main/java/androidx/navigation/serialization/RouteSerializer.kt
M navigation/navigation-common/src/test/java/androidx/navigation/serialization/NavArgumentGeneratorTest.kt
M navigation/navigation-compose/src/androidTest/java/androidx/navigation/compose/NavGraphBuilderTest.kt
cl...@google.com <cl...@google.com> #6
Fixed internally, available in navigation 2.8.2
.
pr...@google.com <pr...@google.com> #7
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.annotation:annotation-wasm-js:1.9.0-rc01
androidx.annotation:annotation-watchosdevicearm64:1.9.0-rc01
androidx.navigation:navigation-common:2.8.2
androidx.navigation:navigation-compose:2.8.2
na...@google.com <na...@google.com> #8
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.navigation:navigation-common:2.9.0-alpha01
androidx.navigation:navigation-compose:2.9.0-alpha01
Description
Component used: Navigation
Version used: 2.8.0-beta02
Devices/Android versions reproduced on: Any
After migrating to use the new APIs, the last step for me was to go ahead and implement all the right
typeMap: Map<KType, @JvmSuppressWildcards NavType<*>>
to pass into my destinations. The stacktrace for those looked something like this:But the problem is that until the last point where it does lead me to the right place (at
com.hedvig.android.app.navigation.HedvigNavHostKt.HedvigNavHost$lambda$56$lambda$55(HedvigNavHost.kt:99)
) from that point and up, all the references to my own code are to lines that do not match my real project. For exampleHomeGraph.kt:82
points to line "82" but the entire file is 71 lines.I am not sure where this mismatch is happening, but it's making fixing the type maps a very slow job as I need to now go and manually check every single destination and manually deduce if it needs a type-map or not.