Status Update
No update yet.
Comments
ma...@gmail.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
il...@google.com
ap...@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
il...@google.com
This has been fixed internally (you should no longer get any crash from handleDeepLink()) and will be available in Navigation 2.3.0-alpha05.
ma...@gmail.com
il...@google.com
We're looking to do a Navigation 2.2.2 bug fix release and will include this fix in that.
an...@google.com
rc...@olx.ph
Hello, does anyone know the timeline when to release version 2.3.0-alpha05? Unfortunately we are also encountering this crash in our app. Thank you.
il...@google.com
rc...@olx.ph
The crash is gone now, thank you!
ja...@gmail.com
After upgrading to 2.2.2 i have crash on finding graph.
I/NavController: Could not find destination com.my.app:id/main_navigation in the navigation graph, ignoring the deep link from Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x1040c000 pkg=com.my.app cmp=com.my.app/com.my.app.MainActivity (has extras) }
This is simple deep link to specified fragment. We have nested NavHostFragment. The fragment i'm deep linking to is in PARENT GRAPH, not the nested one. MainPageFragment have the nested NavHostFragment in it, so i guess the graph found is the nested one and so - does not match one that we are looking for.
<navigation xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:id="@+id/main_navigation"
app:startDestination="@id/intro_navigation">
<fragment
android:id="@+id/mainPageFragment"
android:name="com.my.app.MainPageFragment"
android:label="MainPageFragment">
<argument
android:name="fromNotification"
android:defaultValue="false"
app:argType="boolean" />
</fragment>
</navigation>
I created this deep link by builder:
NavDeepLinkBuilder(context)
.setGraph(R.navigation.main_navigation)
.setDestination(R.id.mainPageFragment)
.setArguments(bundleOf("fromNotification" to true))
.createPendingIntent()
il...@google.com
Re #12 - please file a new bug with a sample project that reproduces your issue. It would be expected that you'd see at least one log message if you have nested NavHostFragment instances with different graphs (the nested graph would ignore deep links to the outer one, as expected).
ja...@gmail.com
I think that this code breaks down:
NavDestination node = i == 0
? (mGraph.getId() == destinationId ? mGraph : null)
: graph.findNode(destinationId, false);
For some reason it assumes that first deeplink have to be in current mGraph. Shouldn't it always scan all graphs to look for proper node?
ja...@gmail.com
I have 2 of such logs, each for every graph. I will try to create project that reproduces this and create new bug
Description
Version used: 2.2.0-rc03
Devices/Android versions reproduced on: can't reproduce
I have a few crash reports about this exceptions, that I can't reproduce in normal conditions and I wonder if this is some corner-case bug.
Stacktrace:
Fatal Exception: java.lang.IllegalStateException: unknown destination during deep link: com.app:id/nav_graph_main
at androidx.navigation.NavController.handleDeepLink(NavController.java:660)
at androidx.navigation.NavController.onGraphCreated(NavController.java:573)
at androidx.navigation.NavController.setGraph(NavController.java:534)
at androidx.navigation.NavController.setGraph(NavController.java:514)
at com.app.view.HomeFragment.prepareNestedNavHost(HomeFragment.java:65)
at com.app.view.HomeFragment.onViewCreated(HomeFragment.java:50)
at androidx.fragment.app.FragmentStateManager.createView(FragmentStateManager.java:304)
at androidx.fragment.app.FragmentManager.moveToState(FragmentManager.java:1227)
at androidx.fragment.app.FragmentManager.addAddedFragments(FragmentManager.java:2373)
at androidx.fragment.app.FragmentManager.executeOpsTogether(FragmentManager.java:2108)
at androidx.fragment.app.FragmentManager.removeRedundantOperationsAndExecute(FragmentManager.java:2064)
at androidx.fragment.app.FragmentManager.execPendingActions(FragmentManager.java:1960)
at androidx.fragment.app.FragmentManager$4.run(FragmentManager.java:418)
I have a main NavHostFragment, hosted in my MainActivity, that owns the "nav_graph_main" graph.
HomeFragment is a destination of "nav_graph_main" and it contains a second NavHost (the "nested" NavHost) to manage navigation between several subscreens together with a BottomNavigationBar (HomeFragment's layout is a NavHostFragment above a BottomNavigatonBar).
The graph of the "nested" navigation ("nav_graph_home") is a separate resource, with no link to the outer "nav_graph_main" graph.
I need to programmatically set the nested graph to the nested NavController, because the start destination practically depends on which bottom navigation tab I want to be selected first.
Therefore, in HomeFragment's onViewCreated, I call the following prepareNestedNavHost:
fun prepareNestedNavHost() {
val startDestination = args.startDestination
val navHostFragment = childFragmentManager.findFragmentById(R.id.navHostHome) as? NavHostFragment
navHostFragment?.navController?.apply {
// I have no other way to know if the graph is not set:
kotlin.runCatching { this.graph }.onFailure {
val nestedGraph = navInflater.inflate(R.navigation.nav_graph_home)
graph.startDestination = startDestination
this.graph = nestedGraph
}
}
}
The only potential reason that came out of my mind is that the nested NavController, sharing the same Activity with the outer NavController, might end up handling an Intent directed to the latter. Is this working as intended?