Status Update
No update yet.
Comments
il...@google.com
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
sk...@gmail.com
il...@google.com
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
sk...@gmail.com
So is your actual issue that you didn't know that serializeAsValue needed to return a valid Uri encoded string?
Yes. Also, I realized this from Crashlytics. Maybe a lint would be useful or something to realize this earlier.
il...@google.com
cl...@google.com
As first step, adding comment to highlight the fact that outputs should be encoded. The lint can be added as a follow up, as part of other safe arg lints to be added.
ap...@google.com
Branch: androidx-main
commit 752e82e468e577c2fc891faae7b815501d6d3504
Author: Clara Fok <clarafok@google.com>
Date: Thu Jun 06 11:03:34 2024
Add comment on serializeAsValue/Values
Test: TH
Bug: 344943214
Relnote: "Add comment on NavType.serializeAsValue and serializeAsValues to highlight that the final outputs should be Uri encoded."
Change-Id: Ida6bd848fb1e3d8e26277eff0f214e1d40907063
M navigation/navigation-common/src/main/java/androidx/navigation/CollectionNavType.kt
M navigation/navigation-common/src/main/java/androidx/navigation/NavType.kt
cl...@google.com
The added comments will be available in navigation 2.8.0-beta03.
jb...@google.com
pr...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.navigation:navigation-common:2.8.0-beta03
ig...@forzafootball.com
I believe the real issue has not been addressed.
The very idea of implementing type-safe navigation is to abstract details away (like dealing with uri creation and parsing), thus decreasing runtime issues by making developers work with types, which is great, BUT for some reason type abstraction still leaks with uri-based backend details, and still obligates devs to write boilerplate. For example there could be
enum class Category {
@SerialName("started") Started,
@SerialName("ended_unexpectedly") EndedUnexpectedly
}
which could be used as a primitive within app, come from network of whatever and one would expect to safely use it as a property in route data class bc there is first-party support for enum serialization.
Despite all this assumptions app would fail, when EndedUnexpectedly is used, but won't fail if Started is used bc of _, which is quite weird and moreover crash won't tell anything related to this specifically, only generic "can't find destination".
Forcing developers taking care of this is clearly the same issue we had before type-safe nav and which it was supposed to fix.
Description
Component used: Navigation
Version used: 2.8.0-beta02
Devices/Android versions reproduced on: emulator API 34
Basically,
RouteBuilder.Filled<T>does not do any URL escaping. This causes runtime crashes during navigation with a non-escaped value the navigation library cannot find a target destination (as there is no argument match).This is unexpected as I'm using the abstraction for objects, with no URLs involved.