Status Update
Comments
lo...@gmail.com <lo...@gmail.com> #2
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
cl...@google.com <cl...@google.com> #3
cl...@google.com <cl...@google.com>
cl...@google.com <cl...@google.com> #4
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
Author: Clara Fok <
Link:
Fix deeplink incorrectly matching when deep link fields don’t match perfectly
Expand for full commit details
Fix deeplink incorrectly matching when deep link fields don’t match perfectly
Navigation used to allow matching as long as one of three (uri / action / mimType) matches. However this is erroneous, as each field is a defined filter - a potential match should at the very least fulfill all filters.
This is fixed by applying these ground rules for deeplink matching:
1. The added NavDeepLink field’s nullability has to match the NavDeepLinkRequest field’s nullability. i.e. if deeplink.uri is null, request.uri must also be null
2. Any NavDeepLink non-null fields has to match exactly with NavDeepLinkRequest’s non-null fields
To elaborate, consider this scenario where
request:
“www.example.com/13”, action = “theAction”
potential matches:
1. www.example.com/{id}, action = "theAction"
2. www.differentUrl.com, action = "theAction"
When handling this request , even though deeplink 2 has a matching action, the differing url will rule it out as a potential match.
This fix also addresses a bug with wildcards where
request:
www.example.com/wildCardMatch?token=123, action = "theAction"
potential matches:
1. www.example.com/.*?token={id}, action = "theAction"
2. www.example.com?token={id}, action = "theAction"
Even though both deep links have a matching Action, deeplink 1 has a better Uri match, and so the request will now match with deeplink 1 instead of deeplink 2.
Test: ./gradlew navigation:navigation-common:cC
Test: ./gradlew navigation:navigation-runtime:cC
Bug: 395712033
Relnote: “NavDeepLink matching has been fixed where a deeplink and a deeplink request have to match exactly on uri, action, and mime. Matching is no longer allowed if only one or two fields match.“
Change-Id: I3b0295caa6324cc707d080856e88e62b4c3cd4d5
Files:
- M
navigation/navigation-common/src/androidInstrumentedTest/kotlin/androidx/navigation/NavGraphAndroidTest.kt
- M
navigation/navigation-common/src/androidMain/kotlin/androidx/navigation/NavDestination.android.kt
- M
navigation/navigation-common/src/commonMain/kotlin/androidx/navigation/NavDeepLink.kt
- M
navigation/navigation-fragment/src/androidTest/java/androidx/navigation/fragment/BaseNavControllerTest.kt
- M
navigation/navigation-runtime/src/androidInstrumentedTest/kotlin/androidx/navigation/NavControllerRouteTest.kt
- M
navigation/navigation-runtime/src/androidInstrumentedTest/kotlin/androidx/navigation/NavControllerTest.kt
- M
navigation/navigation-runtime/src/androidInstrumentedTest/kotlin/androidx/navigation/NavInflaterTest.kt
- M
navigation/navigation-runtime/src/androidInstrumentedTest/res/navigation/nav_deeplink.xml
- M
navigation/navigation-runtime/src/androidInstrumentedTest/res/navigation/nav_simple.xml
Hash: 85ccd3f102d5d1da4bfc7ceba71425319a6f1c50
Date: Wed Feb 19 12:51:38 2025
ba...@gocity.com <ba...@gocity.com> #6
I think this fix has broken some other deeplinks.
I have the following defined in my NavHost file:
composable<Screen.AttractionDetail>(deepLinks = listOf(navDeepLink<Screen.AttractionDetail>(basePath = "gocity:/attraction"))) ...
@Serializable
data class AttractionDetail(val id: String, val hideBookmark: Boolean = false) : Screen
In one of my UI tests I have this code:
deeplinkNavigator("gocity:/attraction/$attractionId")
With 2.8.7 this works fine but as soon as I upgrade to 2.8.8 the deeplink no longer opens the AttractionDetail screen.
I've experimented with changing the data class to be val hideBookmark: Boolean?
and to using uriPattern
instead of basePath
but I can't get this deeplink to work in 2.8.8
cl...@google.com <cl...@google.com> #7
@Serializable
sealed interface Screen {
@Serializable
data class AttractionDetail(val id: String, val hideBookmark: Boolean = false) : Screen
}
controller.graph =
controller.createGraph(startDestination = "start") {
...
composable<Screen.AttractionDetail> { deepLink(navDeepLink<Screen.AttractionDetail>("gocity:/attraction")) }
}
val request = NavDeepLinkRequest(Uri.parse("gocity:/attraction/13"), null, null)
val handled = controller.handleDeepLink(request)
Can you file a separate bug and attach a repro?
e....@gmail.com <e....@gmail.com> #8
I also had problem after updating to version 2.8.8.
Explicitly setting action
to Intent.ACTION_VIEW
in the Deep Link builder now may be required if your intent filter for deeplink schema has android.intent.action.VIEW
.
At least that's how I solved the issue that I got after using version 2.8.8.
See example:
Manifest:
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data
android:scheme="company"
android:host="app"
android:pathPattern="/.*" />
</intent-filter>
In broadcast receiver:
//...
val deepLinkUri = NavDeepLinks.progressDeepLink.uriPattern
val intent = Intent(
Intent.ACTION_VIEW,
Uri.parse(deepLinkUri) //
).apply {
flags = Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TOP
`package` = context.packageName
}
val pendingIntent = PendingIntent.getActivity(
context,
0,
intent,
PendingIntent.FLAG_IMMUTABLE
)
//...
Definition of DeepLink using builder:
val progressDeepLink = navDeepLink {
uriPattern = "$BASE/${Path.PROGRESS}"
action = Intent.ACTION_VIEW
}
Compose Navigation Graph Builder:
navigation<LimitsDirection>(
deepLinks = listOf(NavDeepLinks.limitsDeepLink)
) {
LimitsScreen(viewModel = limitsViewModel)
}
I hope that helps you.
Also, may be this fix requires some update for documentation and/or guides
Description
If a NavGraph has multiple NavDestinations, each with a deeplink that share the same action i.e.
Deeplink "https://example.com/2 " would actually match with
https://completelyDifferentUrl.com
rather than the exact matchhttps://example.com/{id}
.We would expect deeplink to match with the url that has a better path + argument match.