Status Update
Comments
ap...@google.com <ap...@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
}
},
)
ap...@google.com <ap...@google.com> #3
Can you give a fuller example for the animateContentSize()
problem?
ap...@google.com <ap...@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).
ap...@google.com <ap...@google.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.
Description
Component used: Fragment
StrictMode
We should build the same type of infrastructure for Fragments so that developers can enable runtime checking for bad behaviors and validate that they (or libraries they depend on) aren't using deprecated APIs or known potential problematic behaviors.
Importantly, this should only be as a second line of defense behind deprecation warnings or Lint warnings to catch these issues at build time or to handle cases where third party libraries / dependencies are triggering these behaviors so that bugs can be filed against them.
We should support at least
penaltyLog()
,penaltyDeath()
, andpenaltyListener()
.Given that we should maintain behavior compatibility, we should not add any
enableDefaults()
ordetectAll()
methods and instead have developers opt into exactly thedetect***()
methods they want. This should also remove the need forpermit***()
methods since they'll all default to off.Ideally, this is something that developers can either:
Set globally via
FragmentStrictMode.setDefaultPolicy(FragmentStrictMode.Policy)
Set on a specific
FragmentManager
(and its childrenFragmentManager
s) viafragmentManager.setStrictModePolicy(FragmentStrictMode.Policy)
(this would override the default policy)This API shouldn't be made public until there is at least two
detect***()
calls added. These will be filed as separate issues.