Status Update
Comments
ch...@google.com <ch...@google.com> #2
Branch: androidx-main
commit c2365dcfeb9064814282304f30f3eb86be71fdc7
Author: Dan Nizri <dniz@google.com>
Date: Wed Dec 20 16:33:08 2023
Fix Popup back handling on Android T/13+ when android:enableOnBackInvokedCallback="true"
Bug: 313702338
Bug: 318537200
Test: tested with android:enableOnBackInvokedCallback="true"
Change-Id: I7c7cef686ed9fbfd2d144c90040b13528f1675ed
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/window/AndroidPopup.android.kt
kl...@gmail.com <kl...@gmail.com> #3
Is there remaining work for this feature request. Support for predictive back in Dialogs would allow Material3 to remove some Dialog forks and would be very helpful!
m....@futuremind.com <m....@futuremind.com> #4
Yeah, we probably want to investigate new API shapes here to take advantage of predictive back. No work ongoing yet though, needs prioritization
ch...@google.com <ch...@google.com>
il...@google.com <il...@google.com> #5
m....@futuremind.com <m....@futuremind.com> #6
(recapping my chat with Ian)
The tricky part is that the onDismissRequest
is really the final signal and a chance for the app to just say 'nope, I don't want the dialog to dismiss' (since they own the state of 'should the dialog be shown or not' simply by either adding the Dialog to composition or leaving out of composition) - that's the just-in-time problem that the comment talks about. It would be very odd to have any kind of progress animation that doesn't actually lead to the dialog being dismissed when it is committed"
so really it needs to be a more holistic look at how to do dialogs and swap from a binary state (shown/not shown) to something that actually has something in between for cases like predictive back
jb...@google.com <jb...@google.com> #7
Navigation 2.4.0-alpha05
added crossfades between destinations, so those recompositions are indeed intentional. Glad you found the error though! Going to close this as working as intended.
il...@google.com <il...@google.com> #8
Note that your BookViewModel
can add a SavedStateHandle
parameter which will automatically be filled with the arguments of your destination, allowing you to do one time initialization directly in the init
block:
@HiltViewModel
class BookViewModel @Inject constructor(
savedStateHandle: SavedStateHandle,
// whatever other injected parameters you have
private val repository: BookRepository
) : ViewModel() {
init {
val bookId = savedStateHandle.get<Long>("bookId")
// Kick off your initialization here
}
}
Description
I have an app consisting of an android app module and a shared kmm module. This shared module performs some xml sax parsing via org.xml.sax.ext.DefaultHandler2.
Everything worked fine for a long time. But as soon as I changed navigation compose from alpha04 to alpha05 it completely messed up the parsing - there are no parsing exception, but the parser seems to miss some tags and parse some other multiple times - hard to say what's happening.
No idea how it's even possible but I'm 100% sure it's this lib update that changes the behavior.