Status Update
Comments
su...@google.com <su...@google.com> #2
This also brings back dialog content size animations issues :( But on all devices this time.
See attached video
Repro:
Dialog(
onDismissRequest = {
if (dialogState.canDismiss.value) {
dialogNavigator.hide()
}
},
properties = properties,
content = {
Surface(
modifier = modifier
.safeContentPadding()
.fillMaxWidth(0.8f)
.animateContentSize(),
shape = shape,
color = backgroundColor,
contentColor = contentColor,
) {
.....A composable that change it's size
}
},
)
dr...@gmail.com <dr...@gmail.com> #3
Can you give a fuller example for the animateContentSize()
problem?
ra...@google.com <ra...@google.com> #4
It does that for all the cases where the content change.
properties = DialogProperties(usePlatformDefaultWidth = false)
var show by remember { mutableStateOf(false) }
LaunchedEffect(Unit) {
delay(1000)
show = true
}
Column {
Text("X")
if (show) {
Text"Y)
}
}
Edit: This was a well known long time issue when not using usePlatformDefaultWidth = false
so we were forced to workaround with that.
Now even with it it trigger that. (Depending on the phone, it's either super slow, or laggy and jumping).
dr...@gmail.com <dr...@gmail.com> #5
I am seeing a problem with decorFitsSystemWindows = false
where it continues to invalidate the layout even after the animation completes. I don't think that's the problem you're worried about, though.
If I understand correctly, the problem you're seeing is something about it being laggy? And it didn't happen in the previous version, right?
That problem is likely due to the Window resizing on every frame, which is more expensive than the window content resizing on every frame. In a previous iteration, the window size was full screen and the content resized itself. You can resolve this yourself by doing this:
Surface(
modifier = Modifier.safeContentPadding()
.fillMaxSize()
.wrapContentHeight()
.fillMaxWidth(0.8f)
.animateContentSize(),
...
I'll see if I can fix the problem with decorFitsSystemWindows = false
invalidating layout continuously.
ra...@google.com <ra...@google.com> #6
There's 2 very different issue here. The main very blocking is the Samsung dialogs from a bottomsheet/popup being at the bottom and under the navigation bar. Samsung is a very large percent of users. And a full rewrite of all M3 AlerDialog to something else to workaround is a pain as most M3 things are private / internal.
The second issue is about the huge lag.
It was present since a very long time with usePlatformDefaultWidth = true
but not with usePlatformDefaultWidth = false
now it's always present.
AFAIR previously all the workaround based on .fillMaxSize()
had issues with the dialog scrim, but I'll try again if there's a fix for the Samsung devices.
dr...@gmail.com <dr...@gmail.com> #7
I just verified that an AlertDialog
called from a ModalBottomSheet
from a Pixel 9XL works fine. I'll see if I can find a Samsung device to test.
ra...@google.com <ra...@google.com> #8
Yes this is specific to Samsung as stated in first message.
I repro via Samsung testlab as I do not have a device myself, but A54 A55 with Android 14 there does reproduce the issue. (And a few different other Android 14 samsung devices from my beta users)
dr...@gmail.com <dr...@gmail.com> #9
I just verified that I can repro on a Samsung device.
ra...@google.com <ra...@google.com> #10
Perfect.
Just quickly tested the
.fillMaxSize()
.wrapContentHeight()
And it seems to behave correctly for the dialog scrim so works as a solution, may worth a note somewhere as cheating with usePlatformDefaultWidth = false
was often found as solution in a few posts over Internet.
A quick "mostly" related question to the dialog scrim, many users requested an option to hide the status bar in my app to be in full immersive mode, but there's no way to do that with dialogs right now. Is this something that can be requested? I have a fork of M3 BottomSheet to handle that, but handling a fork of the low level dialog requires a full copy and rewrite of everything that depends on it.
ap...@google.com <ap...@google.com> #11
Have you tried using the DialogWindowProvider?
:
fun findDialogWindowProviderInParent(view: View): DialogWindowProvider? {
if (view is DialogWindowProvider) {
return view
}
val parent = view.parent ?: return null
if (parent is View) {
return findDialogWindowProviderInParent(parent)
}
return null
}
@Composable
MyDialogContent() {
val dialogWindowProvider = findDialogWindowProviderInParent(LocalView.current)
dialogWindowProvider?.window?.addFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN)
...
}
Description
When I set up a periodic job, I want the first in the series to be performed INSTANTLY (the user expects it... they hit a button and are waiting for an immediate result), and then for subsequent ones to be performed based on the periodic schedule (more vague timings is fine... the user is no longer waiting).
When you set up a periodic work request *without* a flex interval, it can run anytime in the set interval, i.e. from NOW until the end of the interval. If the device is awake when the periodic work request is scheduled, which is the case for me, I find that the first work in the series is generally performed at the START of the interval, i.e. NOW... though "NOW" may not be instantly (it's up to the device to decide... may be delayed a few seconds).
Because it cannot be guaranteed that the first periodic work will be performed *instantly*, instead I do an explicit call to the work-performing function outside of the WorkManager realm, and put a flexInterval on the periodic work of 5 mins so that the first periodic work will certainly not be performed straight away, but instead it will be near the end of the first period, most likely 5 mins before the end. This is not quite ideal (first gap between work runs is not quite a full interval) but it's OK... the user won't care or even notice it runs 5 mins "early" the first time.
Now, I thought that the ability to set an "initialDelay" in 2.1.0 would solve my problems... so that I could:
(a) still make an explicit call to the work-performing function to do the immediate work, guaranteed to be NOW (the user expects that)
(b) set up a periodic work request WITHOUT flexInterval (i.e. use the whole interval) and WITH an initial delay equal to the period "interval"
That way, I get the immediate work done, and then after "interval" the periodic work request is scheduled, and because (let's assume) the device is still awake, the first periodic work will likely perform at the START of the interval, i.e. almost straight away, i.e. pretty close to exactly one "interval" after the user set the schedule going.
BUT I'm not finding that. Let's say that "interval" of the periodic work is 15 mins, and I set an "initial delay" also of 15 mins, and I set this going when the user hits the button. I find that the immediate work is performed at 0 mins (triggered explicitly, not by WorkManager, so that's as expected), then at 15 mins NOTHING happens, and only at 30 mins does the first periodic work actually run.
It seems that either the first periodic work happens at the END of the first interval (15-30 mins) and not the start (like it usually does, if the device is awake and not busy), or WorkManager delayed first periodic interval to be at 30-45 mins, i.e. it waited 30 mins not 15 mins, twice what I asked for.
So, how is "setInitialDelay" for a periodic work request meant to work? It doesn't just wait "delay" (instead of not waiting at all) and then enqueue the periodic work request?