ADFA-3070 | Fix agent chat unscrollable in landscape

[jatezzz]

Description

Fixed an issue where the agent chat is not scrollable on shorter screens, such as in landscape orientation. The previous LinearLayout setup caused the RecyclerView to be measured at zero height once the UI chrome exceeded the container's height. The layout has been updated to bound the chrome elements and float the composer toggle over the list. Additionally, an auto-hide controller was introduced to fold the composer away on compact screens, ensuring maximum space for the chat history.

Details

• Extracted the composer behavior into a dedicated ComposerAutoHideController to manage visibility state and auto-hide countdowns.
• Added integer resources to define compact screens (under 480dp) and trigger auto-hiding after 5 seconds of idle time.
• Implemented window inset handling to properly pad the RecyclerView around display cutouts in landscape orientation.
• Consolidated the attachment, input, and send controls into a single bordered composer box layout.

Screen_Recording_20260807_093529_Code.on.the.Go.mp4

Ticket

ADFA-3070

Observation

The auto-hide functionality includes explicit safeguards to ensure the composer remains visible if the user is typing, the input is not empty, the agent is actively running, or if touch exploration accessibility services are enabled.

[claude]

Claude Code Review

This repository is configured for manual code reviews. Comment @claude review for a one-time review, or @claude review always to subscribe this PR to a review on every future push.

_{Tip: disable this comment in your organization's Code Review settings.}

[hal-eisen-adfa]

Code review

Found 1 issue:

1. The composer can reach an unrecoverable hidden state after process death. attach() passes the saved visible flag straight through, and applyCompactRule re-derives only autoHide — not visible. Sequence: fold the composer on a compact screen, the process is killed while backgrounded, the app restores into a taller configuration. autoHide is correctly recomputed to false, but the stale saved visible = false is still applied, so setVisible hides the input bar and hides the tab that would restore it (binding.btnShowComposer.isVisible = autoHide && !visible → false && true). The user is left with no input bar, no attach button, and no on-screen affordance to recover the composer.

plugin-examples/ai-assistant/src/main/kotlin/com/itsaky/androidide/plugins/aiassistant/fragments/ComposerAutoHideController.kt

Lines 64 to 68 in 26995d6

	autoHide = savedState?.getBoolean(KEY_COMPOSER_AUTO_HIDE) ?: false
	applyCompactRule(config, visible = savedState?.getBoolean(KEY_COMPOSER_VISIBLE) ?: true)
	}

plugin-examples/ai-assistant/src/main/kotlin/com/itsaky/androidide/plugins/aiassistant/fragments/ComposerAutoHideController.kt

Lines 148 to 153 in 26995d6

	private fun setVisible(visible: Boolean) {
	val binding = _binding ?: return
	binding.inputBarCard.isVisible = visible
	binding.btnShowComposer.isVisible = autoHide && !visible
	binding.btnHideComposer.isVisible = autoHide && visible
	if (visible) {

onConfigurationChanged already guards the live-rotation case with applyCompactRule(config, visible = true), but attach() never got the equivalent guard:

plugin-examples/ai-assistant/src/main/kotlin/com/itsaky/androidide/plugins/aiassistant/fragments/ComposerAutoHideController.kt

Lines 80 to 84 in 26995d6

	*/
	fun onConfigurationChanged(config: Configuration) =
	applyCompactRule(config, visible = true)
	/**

The KDoc on saveState already names this exact scenario — "the process can come back in an orientation other than the one it died in, and the saved flag would describe a screen that is gone" — but only autoHide is re-derived on restore, not visible:

plugin-examples/ai-assistant/src/main/kotlin/com/itsaky/androidide/plugins/aiassistant/fragments/ComposerAutoHideController.kt

Lines 126 to 135 in 26995d6

	/**
	* Saves the composer across process death. The auto-hide flag is written too, but
	* [applyCompactRule] re-derives it on restore: the process can come back in an orientation
	* other than the one it died in, and the saved flag would describe a screen that is gone.
	*/
	fun saveState(outState: Bundle) {
	outState.putBoolean(KEY_COMPOSER_AUTO_HIDE, autoHide)
	outState.putBoolean(KEY_COMPOSER_VISIBLE, _binding?.inputBarCard?.isVisible ?: true)
	}

Suggested fix: in applyCompactRule, ignore the restored visible = false once autoHide resolves to false, so the composer can only stay folded on a screen that still offers the reopen tab.

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[hal-eisen-adfa]

Code review

Found 1 issue:

1. The manual fold path has no agentRunning guard, so the Hide tab can fold the Stop button away mid-run (bug due to ComposerAutoHideController.kt: canAutoHide()'s return !agentRunning is consulted only by schedule(), so it blocks the idle-timeout fold but not a tap on btnHideComposer)

The KDoc on onAgentRunningChanged states that "a running agent also pins the composer open for as long as the run lasts":

plugin-examples/ai-assistant/src/main/kotlin/com/itsaky/androidide/plugins/aiassistant/fragments/ComposerAutoHideController.kt

Lines 83 to 88 in 3793da9

	/**
	* Switches the trailing button between Send and Stop. Stop lives on that button, so a running
	* agent also pins the composer open for as long as the run lasts.
	*/
	fun onAgentRunningChanged(running: Boolean) {

But setVisible never checks agentRunning:

plugin-examples/ai-assistant/src/main/kotlin/com/itsaky/androidide/plugins/aiassistant/fragments/ComposerAutoHideController.kt

Lines 151 to 165 in 3793da9

	*/
	private fun setVisible(visible: Boolean) {
	val binding = _binding ?: return
	binding.inputBarCard.isVisible = visible
	binding.btnShowComposer.isVisible = autoHide && !visible
	binding.btnHideComposer.isVisible = autoHide && visible
	if (visible) {
	schedule()
	} else {
	countdown?.cancel()
	binding.promptInputEdittext.clearFocus()
	hideKeyboard()
	}
	}

On a compact screen this is reachable on exactly the screen class the PR targets: onAgentRunningChanged(true) calls setVisible(true), which makes btnHideComposer visible (autoHide && visible), and its click listener routes straight to setVisible(false), hiding inputBarCard and the Stop button it carries.

Recovery is a single tap on the still-visible btnShowComposer, so this is low severity. Either honour agentRunning on the manual path, or soften the KDoc so it does not promise a guarantee the code does not make.

Reviewed against base feat/ADFA-1798-model-memory-preflight (stacked PR), so PR #63's commits were excluded. Code review only, not device-verified.

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[jatezzz]

@hal-eisen-adfa Good catch on the mismatch. Keeping the manual path as-is and fixing the doc instead: folding the composer to read streaming output on a short landscape screen is a reasonable thing to want mid-run, and gating the tap would leave a visible button that does nothing. Reworded the KDoc so it only promises what the code does, the run opens the composer and suppresses the idle countdown; an explicit Hide still folds it, with Stop one tap away on the reopen tab.