commit | 590af4206ee5798f3319f5df7c7dae6712753683 | [log] [tgz] |
---|---|---|
author | Clara Fok <clarafok@google.com> | Wed Feb 21 11:44:18 2024 -0800 |
committer | Clara Fok <clarafok@google.com> | Thu Feb 22 14:16:52 2024 -0800 |
tree | 74eea6bab42c1b2984042fc85499bd10fffacd6d | |
parent | a13ed0e47bbe05a73cf479cdc461fe60498d4231 [diff] |
Implement KType argument matcher Users can provide custom NavTypes via Map<KType, NavType<*>>. We map serialized arguments to NavType by matching the serialized arg to a KType. Matching is performed by first converting both serialized arg and KType to a common internal type, and then comparing the resulting internal type. KTypes can have different names for the same Type, i.e. Int can be represented as "int" and "java.lang.Integer" depending on factors such as its nullability, whether it is a TypeParameter etc. Therefore, conversion to a common type enables easier matching for different permutations of KType names especially with nested TypeParameters. The matcher recursively matches nested TypeParameters for Native Kotlin collections. For custom Types, TypeParameters are erased in serialization by default. The type is preserved only if a class field is of type T, and even then we cannot know if this type is in fact the TypeParameter. Therefore, matching custom types with TypeParameter<T> only works under two conditions: 1. A class field of that type must be declared for each generic type 2. These class fields must be declared in primary constructor in same order Otherwise, custom types with TypeParameter will be matched to a KType purely based on the class's fully qualified name and will not be able to differentiate between diffrent TypeParameters values. This can lead to indeterminate matching behavior. Test: ./gradlew navigation:navigation-common:test Bug: 188693139 Change-Id: I33778e21a36aeca629a3e03d809fa3fef9e8886c
Jetpack is a suite of libraries, tools, and guidance to help developers write high-quality apps easier. These components help you follow best practices, free you from writing boilerplate code, and simplify complex tasks, so you can focus on the code you care about.
Jetpack comprises the androidx.*
package libraries, unbundled from the platform APIs. This means that it offers backward compatibility and is updated more frequently than the Android platform, making sure you always have access to the latest and greatest versions of the Jetpack components.
Our official AARs and JARs binaries are distributed through Google Maven.
You can learn more about using it from Android Jetpack landing page.
For contributions via GitHub, see the GitHub Contribution Guide.
Note: The contributions workflow via GitHub is currently experimental - only contributions to the following projects are being accepted at this time:
When contributing to Jetpack, follow the code review etiquette.
We are not currently accepting new modules.
Head over to the onboarding docs to learn more about getting set up and the development workflow!
Our continuous integration system builds all in progress (and potentially unstable) libraries as new changes are merged. You can manually download these AARs and JARs for your experimentation.
Before uploading your first contribution, you will need setup a password and agree to the contribution agreement:
Generate a HTTPS password: https://android-review.googlesource.com/new-password
Agree to the Google Contributor Licenses Agreement: https://android-review.googlesource.com/settings/new-agreement
AndroidX uses git to store all the binary Gradle dependencies. They are stored in prebuilts/androidx/internal
and prebuilts/androidx/external
directories in your checkout. All the dependencies in these directories are also available from google()
, or mavenCentral()
. We store copies of these dependencies to have hermetic builds. You can pull in a new dependency using our importMaven tool.