Fixed
Status Update
No update yet.
Comments
il...@google.com
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
mu...@gmail.com
d....@gmail.com
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 (
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
an...@gmail.com
Hello team,
I am also facing the similar issue(https://github.com/andor201995/NoteIt/pull/15 )
I am using nav_version: 2.1.0-alpha05
Device: Samsung galaxy S8+
Expected Result:
I have a dialog AddNewNoteFragment on top of a fragment NoteListingFragment and move to a fragment UpdateNoteBodyFragment from a button on AddNewNoteFragment(Dialog), the screen should show UpdateNoteBodyFragment. And when I pop back from UpdateNoteBodyFragment, it should go to previous stage of AddNewNoteFragment on top of NoteListingFragment.
Current Result:
When i trigger actionAddNewNoteFragmentToUpdateNoteBodyFragment then dialog is not dismissed and AddNewNoteFragment(dialog) is on top of UpdateNoteBodyFragment(while dialog should get dismissed) and when i dismiss the AddNewNoteFragment(dialog) then UpdateNoteBodyFragment also get's destroyed and return's back to NoteListingFragment(start point).
And now if i click on any button to trigger a navigation action then i get a crash.
java.lang.IllegalArgumentException: navigation destination com.andor.navigate.notepad:id/action_noteListingFragment_to_addNewNoteFragment is unknown to this NavController
at androidx.navigation.NavController.navigate(NavController.java:786)
at androidx.navigation.NavController.navigate(NavController.java:727)
at androidx.navigation.NavController.navigate(NavController.java:713)
at androidx.navigation.NavController.navigate(NavController.java:701)
at com.andor.navigate.notepad.listing.fragment.NoteListingFragment.onOptionsItemSelected(NoteListingFragment.kt:180)
attaching the video file
I am also facing the similar issue(
I am using nav_version: 2.1.0-alpha05
Device: Samsung galaxy S8+
Expected Result:
I have a dialog AddNewNoteFragment on top of a fragment NoteListingFragment and move to a fragment UpdateNoteBodyFragment from a button on AddNewNoteFragment(Dialog), the screen should show UpdateNoteBodyFragment. And when I pop back from UpdateNoteBodyFragment, it should go to previous stage of AddNewNoteFragment on top of NoteListingFragment.
Current Result:
When i trigger actionAddNewNoteFragmentToUpdateNoteBodyFragment then dialog is not dismissed and AddNewNoteFragment(dialog) is on top of UpdateNoteBodyFragment(while dialog should get dismissed) and when i dismiss the AddNewNoteFragment(dialog) then UpdateNoteBodyFragment also get's destroyed and return's back to NoteListingFragment(start point).
And now if i click on any button to trigger a navigation action then i get a crash.
java.lang.IllegalArgumentException: navigation destination com.andor.navigate.notepad:id/action_noteListingFragment_to_addNewNoteFragment is unknown to this NavController
at androidx.navigation.NavController.navigate(NavController.java:786)
at androidx.navigation.NavController.navigate(NavController.java:727)
at androidx.navigation.NavController.navigate(NavController.java:713)
at androidx.navigation.NavController.navigate(NavController.java:701)
at com.andor.navigate.notepad.listing.fragment.NoteListingFragment.onOptionsItemSelected(NoteListingFragment.kt:180)
attaching the video file
an...@gmail.com
Tested on google PixelXL(API 29) also same issue so it's not device specific.
il...@google.com
There's a couple of problems here relating to how Dialogs and Fragments work:
1. Dialogs are separate windows that always sit above your activity's window. This means that the dialog will continue to intercept the system back button no matter what state the underlying FragmentManager is in or what FragmentTransactions you do.
2. Operations on the fragment container (i.e., your normal <fragment> destinations) don't affect dialog fragments. Same if you do FragmentTransactions on a nested FragmentManager.
The initial release of Navigation's <dialog> support did not take these limitations into account and would treat dialog destinations just like any other in that, from Navigation's point of view, they could be put on the back stack and treated like any other <fragment> destination.
As that's not actually the case, we've made a few changes for Navigation 2.1.0-alpha06 to ensure that Navigation's state of the world matches what you actually see on the screen and prevent crashes like that in
The summary of this is that <dialog> destinations are now automatically popped when navigate to a non-dialog and non-activity destination, such as a <fragment> destination. For reference, this was done inhttps://android-review.googlesource.com/996359 and https://android-review.googlesource.com/1007662
1. Dialogs are separate windows that always sit above your activity's window. This means that the dialog will continue to intercept the system back button no matter what state the underlying FragmentManager is in or what FragmentTransactions you do.
2. Operations on the fragment container (i.e., your normal <fragment> destinations) don't affect dialog fragments. Same if you do FragmentTransactions on a nested FragmentManager.
The initial release of Navigation's <dialog> support did not take these limitations into account and would treat dialog destinations just like any other in that, from Navigation's point of view, they could be put on the back stack and treated like any other <fragment> destination.
As that's not actually the case, we've made a few changes for Navigation 2.1.0-alpha06 to ensure that Navigation's state of the world matches what you actually see on the screen and prevent crashes like that in
The summary of this is that <dialog> destinations are now automatically popped when navigate to a non-dialog and non-activity destination, such as a <fragment> destination. For reference, this was done in
j....@gmail.com
So what I can do to show the dialog again when the user press back on the fragment?
[Deleted User] <[Deleted User]>
So what I can do to show the dialog again when the user press back on the fragment?
Is this still not possible?
ar...@gmail.com
So, what you suggest to do for this case? Are there alternative solutions?
il...@google.com
Dialog destinations cannot be put on the back stack, that's still and will always be the case.
gu...@gmail.com
I think the only solution at present is to make fragment B a full dialog
Description
Version used: 2.1.0-alpha04
Devices/Android versions reproduced on: S10
I am trying to navigation from DialogFragment to Fragment in Navigation Component, but getting weird result.
When I navigate from DialogFragment to Fragment, background fragment is changing to target fragment with current dialog on top of it, instead of just moving to target fragment. Why I am getting this behavior or how to fix it?
By fixing I mean normal dialog behavior. Say, I have a dialog D on top of a fragment A and move to a fragment B from a button on D, the screen should show B. And when I pop back from B, it should go to previous stage of D on top of A.
Here is the navigation graph.
<navigation
xmlns:android="
xmlns:app="
xmlns:tools="
android:id="@+id/home"
app:startDestination="@+id/titleScreen">
<fragment
android:id="@+id/titleScreen"
android:name="com.example.android.navigationadvancedsample.homescreen.Title"
android:label="@string/title_home"
tools:layout="@layout/fragment_title">
<action
android:id="@+id/action_title_to_about"
app:destination="@id/aboutScreen"/>
</fragment>
<dialog
android:id="@+id/aboutScreen"
android:name="com.example.android.navigationadvancedsample.homescreen.About"
android:label="@string/title_about"
tools:layout="@layout/fragment_about">
<action
android:id="@+id/action_aboutScreen_to_register"
app:destination="@id/register" />
</dialog>
<fragment
android:id="@+id/register"
android:name="com.example.android.navigationadvancedsample.formscreen.Register"
android:label="fragment_leaderboard"
tools:layout="@layout/fragment_leaderboard" />
</navigation>
If this is a bug in the library, we would appreciate if you could attach:
- Sample project to trigger the issue.
- A screenrecord or screenshots showing the issue (if UI related).