Fixed
Status Update
Comments
ya...@gmail.com <ya...@gmail.com> #2
Project: platform/frameworks/support
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
https://android-review.googlesource.com/1123258
https://goto.google.com/android-sha1/b90079595f33f58fece04026a97faa0d243acdb1
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
il...@google.com <il...@google.com>
br...@gmail.com <br...@gmail.com> #3
br...@gmail.com <br...@gmail.com> #4
Project: platform/frameworks/support
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically ( b/140759491 ).
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
https://android-review.googlesource.com/1288456
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
ap...@google.com <ap...@google.com> #5
Project: platform/frameworks/support
Branch: androidx-main
commit fd55939285777560a833f259725fd62e181249e9
Author: Brad Ball <github@bradball.net>
Date: Tue Apr 13 13:03:12 2021
[GH] [Navigation] Allow case-insensitive matches of Enum args in deep links
## Proposed Changes
Deep Link arguments that are Enum types would only match and get parsed if the casing of the argument value was an exact match to the casing of the Enum value. Since enum values are typically all upper case, this required deep links to contain upper case values as well, meaning if you have an enum with a value of say `Bitmap.Config.ALPHA_8`, a deep link that has an argument of type `Bitmap.Config` will only match if the URL contains `/ALPHA_8` and will not match a url with `/alpha_8`.
This PR updates the EnumType value parsing to include case-insensitive matching. It will first try to parse an enum value using a case-sensitive match, and if no match is found, it will then try to parse the enum value using a case-insensitive match.
Given the following enum:
```
enum class Colors {
RED,
BLUE,
GREEN
}
```
And a destination with an Enum argument and deep link:
```
<argument
android:name="destColor"
app:argType="com.my.app.Colors"
android:defaultValue="RED" />
<deepLink
app:uri="https://myapp.com/{destColor} " />
```
This PR updates the EnumType parsing so that a url like `https://myapp.com/green` will be matched and the `destColor` will be set to `Colors.GREEN`
## Testing
- There were no existing tests for the EnumType.parseValue() method.
- I added a test in `NavTypeTest` to test `EnumType.parseValue()` asserting that both case-sensitive and case-insensitive values are matched.
Test: /gradlew test connnectedCheck
## Issues Fixed
https://issuetracker.google.com/issues/135857840
Fixes: b/135857840
This is an imported pull request fromhttps://github.com/androidx/androidx/pull/152 .
Resolves #152
Github-Pr-Head-Sha: c7f5aefa7bb58a1224782ec269bb20f5a8dc8f04
GitOrigin-RevId: f8da24d9cd33f24b24763c87a4574979b0d1fbdc
Change-Id: I7738eaab2d64ff2bfeb20d5987190d0279a75314
M navigation/navigation-common/src/androidTest/java/androidx/navigation/NavTypeTest.kt
M navigation/navigation-common/src/main/java/androidx/navigation/NavType.kt
https://android-review.googlesource.com/1674765
Branch: androidx-main
commit fd55939285777560a833f259725fd62e181249e9
Author: Brad Ball <github@bradball.net>
Date: Tue Apr 13 13:03:12 2021
[GH] [Navigation] Allow case-insensitive matches of Enum args in deep links
## Proposed Changes
Deep Link arguments that are Enum types would only match and get parsed if the casing of the argument value was an exact match to the casing of the Enum value. Since enum values are typically all upper case, this required deep links to contain upper case values as well, meaning if you have an enum with a value of say `Bitmap.Config.ALPHA_8`, a deep link that has an argument of type `Bitmap.Config` will only match if the URL contains `/ALPHA_8` and will not match a url with `/alpha_8`.
This PR updates the EnumType value parsing to include case-insensitive matching. It will first try to parse an enum value using a case-sensitive match, and if no match is found, it will then try to parse the enum value using a case-insensitive match.
Given the following enum:
```
enum class Colors {
RED,
BLUE,
GREEN
}
```
And a destination with an Enum argument and deep link:
```
<argument
android:name="destColor"
app:argType="com.my.app.Colors"
android:defaultValue="RED" />
<deepLink
app:uri="
```
This PR updates the EnumType parsing so that a url like `
## Testing
- There were no existing tests for the EnumType.parseValue() method.
- I added a test in `NavTypeTest` to test `EnumType.parseValue()` asserting that both case-sensitive and case-insensitive values are matched.
Test: /gradlew test connnectedCheck
## Issues Fixed
Fixes:
This is an imported pull request from
Resolves #152
Github-Pr-Head-Sha: c7f5aefa7bb58a1224782ec269bb20f5a8dc8f04
GitOrigin-RevId: f8da24d9cd33f24b24763c87a4574979b0d1fbdc
Change-Id: I7738eaab2d64ff2bfeb20d5987190d0279a75314
M navigation/navigation-common/src/androidTest/java/androidx/navigation/NavTypeTest.kt
M navigation/navigation-common/src/main/java/androidx/navigation/NavType.kt
Description
Version used: 2.1.0 alpha 05
Deep links with arguments that are enum types are not recognized and parsed unless the casing in the deeplink is an exact match to the enum. This may not be feasible to fix/add, but wanted to bring it up just in case.
consider an example where I have an enum like so
enum class Colors {
RED,
BLUE,
GREEN
}
And a destination with an argument that takes a Colors, and supports a deeplink
<argument
android:name="destColor"
app:argType="com.my.app.Colors"
android:defaultValue="RED" />
<deepLink
app:uri="
The deeplink will only work if the color is correctly cased:
And the following will NOT work:
Granted, paths in URI's are by rule considered to be case-sensitive, so
It would be nice if perhaps when setting up a destination argument of an enum type (or maybe when defining a deep link) we had the option to specify that a deeplink should or should not match based on case-sensitivity. Of course, there's still the challenge of parsing "red" to Colors.RED when processing the deep link arguments.