Status Update
Comments
jb...@google.com <jb...@google.com> #2
Feel free to disable the link check as a workaround.
The Gradle equivalent is:
android {
lintOptions {
disable "DialogFragmentCallbacksDetector"
}
}
[Deleted User] <[Deleted User]> #3
Not all of our builds depend on androidx.fragment and if you do not use androidx.fragment and you add this disable flag, lint fails due to non-existant check DialogFragmentCallbacksDetector. If you do not plan on fixing this soon, I can try and see if we can only disable the check if we depend on androidx.fragment.
il...@google.com <il...@google.com>
jb...@google.com <jb...@google.com> #4
Branch: androidx-main
commit 52b166175eabed99d14515190bfa0a7cea787004
Author: Jeremy Woods <jbwoods@google.com>
Date: Mon May 10 16:11:44 2021
Fix OnCreateDialogIncorrectCallback lint on empty java classes
The OnCreateDialogIncorrectCallbackDetector lint rule currently checks
the first element of a list without verifying the item is actually
there. We should check if the item is null before we do anything else.
RelNote: "The `OnCreateDialogIncorrectCallbackDetector` no longer fails
on empty java classes/interfaces"
Test: java empty interface clean
Bug: 187524311
Change-Id: Iaff6c041370bd5a7c2ac8ef8c32a2e6f7a15e456
M fragment/fragment-lint/src/main/java/androidx/fragment/lint/OnCreateDialogIncorrectCallbackDetector.kt
M fragment/fragment-lint/src/test/java/androidx/fragment/lint/OnCreateDialogIncorrectCallbackDetectorTest.kt
ap...@google.com <ap...@google.com> #5
This has been fixed internally and will be available in the Fragment 1.4.0-alpha01
release.
il...@google.com <il...@google.com> #6
I am using 1.4.0-alpha01 of the Fragment Library but I am still getting this error.
pr...@google.com <pr...@google.com> #7
Re #6 - please file a new bug with a sample that reproduces your error.
an...@daresay.co <an...@daresay.co> #8
li...@gmail.com <li...@gmail.com> #9
ho...@gmail.com <ho...@gmail.com> #10
ho...@gmail.com <ho...@gmail.com> #11
ho...@gmail.com <ho...@gmail.com> #12
Bug Fixes : NavHost in Navigation Compose now correctly intercepts system back calls even after the Activity has been STOPPED and RESUMED.
It works fine for me.
gi...@gmail.com <gi...@gmail.com> #13
va...@zedge.net <va...@zedge.net> #14
In my case it works fine when the app is first ran, but my custom callback calls navController.popBackStack internally if it can't handle back press on its own. So, when I run the app and click back, everything works, but after I pop up all the Composables from the stack and return to the app, the custom callback is not called anymore.
il...@google.com <il...@google.com> #15
Re
Note that you should never, ever be calling navController.popBackStack()
in your own BackHandler
as Navigation must be the only one handling its own back stack with the system back button so that Predictive Back works correctly in the future.
ja...@gopuff.com <ja...@gopuff.com> #16
ja...@sense.com <ja...@sense.com> #17
I believe this is still an issue even without using NavHost like mentioned in
Description
Versions
Component used: Navigation
Version used: 2.5.3
Devices/Android versions reproduced on: any
Description
According to the documentation of [BackHandler], nested BackHandlers(https://developer.android.com/reference/kotlin/androidx/activity/compose/package-summary#top-level-functions ) should take priority:
However, this doesn't work correctly if the activity is paused and then resumed.
Steps to reproduce
Code to demonstrate the issue
A sample project is attached.