Fix in-app message flickering with Jetpack Compose

[franco-zalamena-iterable]

Summary

• Fix in-app message dialog flickering when used with Jetpack Compose
• Stabilize dialog window and WebView rendering

Test plan

• Test in-app messages in a Compose-based app
• Verify no flickering
• Verify in-app messages still work in traditional View-based apps

🤖 Generated with Claude Code

[franco-zalamena-iterable]

PR Analysis

Problem: In-app message dialogs flicker (visual artifacts) when displayed in a Jetpack Compose-based app. Compose's recomposition cycle re-triggers lifecycle callbacks and layout passes on the DialogFragment, causing redundant window updates that manifest as flickering.

Ideal fix plan:

• Identify which lifecycle callbacks or layout operations are being re-triggered by Compose recomposition
• Consolidate window gravity setup to a single point (onCreateDialog) instead of repeating it in onStart, onCreateView, and onCreateDialog
• Disable default dialog window animations that conflict with the custom animation system already in place (showAndAnimateWebView)
• Remove redundant requestLayout() calls in the resize() method since setLayoutParams() already triggers a layout pass internally
• Consider hardware-accelerated rendering for the WebView to prevent visual artifacts during Compose layout passes
• Verify the fix works for all in-app layouts (TOP, BOTTOM, CENTER, FULLSCREEN) and does not regress View-based apps

What the PR did:

• Removed applyWindowGravity() call from onStart() (was redundant with onCreateDialog)
• Removed applyWindowGravity() call from onCreateView() (was redundant with onCreateDialog)
• Added window.setWindowAnimations(0) in onCreateDialog to disable default dialog animations
• Set LAYER_TYPE_HARDWARE on the WebView
• Removed explicit requestLayout() calls in the resize() method

Assessment:

• Root cause identified: partially -- the PR correctly identifies that redundant lifecycle calls and layout passes are the triggers, but the comments frame Compose "recomposition" as the cause rather than the real mechanism: Compose re-triggering Fragment lifecycle callbacks (onStart) when state changes cause the ComposeView hosting the Fragment to recompose. The distinction matters for understanding when this would occur.
• Fix correctness: partially correct -- consolidating gravity to onCreateDialog and removing redundant requestLayout() calls are sound changes. However, setWindowAnimations(0) disables ALL dialog window enter/exit transitions globally, which may cause the dialog to appear/disappear abruptly on View-based apps where the custom animation timing (400ms postOnAnimationDelayed in hideWebView) was calibrated against the default window animation. The hardware layer type on WebView is a reasonable stabilization measure but adds GPU memory cost; it would be better to confirm it actually addresses a specific symptom rather than being applied speculatively.
• Missed:
  • No check on whether disabling window animations regresses the dismiss experience (hideWebView relies on a 400ms delay that was presumably tuned with default window animations active)
  • The showAndAnimateWebView() comment says "we handle animations manually" but the exit path in hideWebView() also depends on timing that may shift without window animations
  • No investigation into whether ComposeView or AndroidViewBinding is wrapping the fragment and whether setRecompositionMode or other Compose-side mitigations could address this at the integration layer
• Wrong assessment: the comments suggest "Compose's recomposition cycle can conflict with the window animation system" -- this is imprecise. Compose recomposition does not directly touch the window animation system. The conflict is that recomposition can re-trigger Fragment lifecycle methods (specifically onStart when the dialog's host is recomposed), and those methods were doing redundant layout work. The window animation disabling is a separate fix for a potentially separate symptom.
• Tests: needed but missing -- at minimum, a unit test verifying that applyWindowGravity is called exactly once (in onCreateDialog) and not in onStart/onCreateView would prevent regressions. An instrumented test with a Compose host would be ideal but admittedly harder.