Files
buzz/mobile
Taylor HoandGitHub 07999425dc fix(mobile): keep latest messages above composer (#4981)
**Category:** fix
**User Impact:** Mobile users who jump to Latest now see the newest
message fully above the composer instead of partially hidden behind it.

**Problem:** The channel message list treated the raw viewport bottom as
the latest boundary even though the composer occupies part of that
viewport. Latest jumps and follow-mode corrections could therefore place
the newest message underneath the composer.

**Solution:** Derive the latest alignment from the measured composer
inset and use that same boundary for scrolling, follow detection, and
layout correction.

<img width="498" height="1008" alt="Screen Recording 2026-08-05 at 5 18
19 PM"
src="https://github.com/user-attachments/assets/a7fc1a94-3ffb-4c34-908d-9bf4f3f082b4"
/>


<details>
<summary>File changes</summary>

**mobile/lib/features/channels/channel_detail_page/message_list.dart**
Aligns Latest navigation and follow-mode correction with the visible
bottom edge above the composer, and evaluates boundary state against the
same geometry.

**mobile/test/features/channels/channel_detail_page_test.dart**
Adds a regression assertion that the newest live message clears the
composer and that the Latest control disappears after navigation.

</details>

## Reproduction steps

1. Open a mobile channel with enough messages to scroll away from the
newest message.
2. Tap **Latest**.
3. Confirm the newest message is fully visible immediately above the
composer and the **Latest** control disappears.
4. Resize the composer or keyboard while following latest and confirm
the newest message remains above the composer.

## Tested fix

The newest message remains fully visible above the composer after
jumping to **Latest**.

![Tested fix: latest message remains above the
composer](https://d24qwcpro867f5.cloudfront.net/repos/buzz/prs/4981/latest-above-composer-tested.gif)

## Validation

- `flutter analyze` — no issues
- `flutter test` — 1,243 passed

---------

Signed-off-by: Taylor Ho <taylorkmho@gmail.com>
2026-08-07 11:38:25 -07:00
..

Buzz Mobile

Flutter mobile client for Buzz.

Setup

cd mobile
flutter pub get

Run

# From repo root (recommended — starts Docker, relay, and simulator):
just mobile-dev

# Direct (requires services and relay already running):
cd mobile && flutter run

Worktree-aware debug identity

Debug builds produced from a git worktree get a unique app identifier keyed to the worktree directory name (com.buzz.buzzMobile.<slug> on iOS, xyz.block.buzz.mobile.<slug> on Android) plus a display-only branch label in the app name (Buzz (my-branch), or a short SHA when the worktree is detached). Because the identifier follows the directory rather than the branch, one worktree keeps exactly one installed app — and its login state — across branch switches, and builds from multiple worktrees install side by side, mirroring the desktop dev experience. Release and profile builds always keep the production identity and name.

just mobile-dev and just mobile-build-android apply this automatically by running scripts/mobile-worktree-overrides.sh, which writes two gitignored files:

  • mobile/ios/Flutter/WorktreeOverrides.xcconfig (included by Debug builds only; a developer's AppOverrides.xcconfig is included after it, so app-specific overrides like a personal BUNDLE_IDENTIFIER for device signing always win)
  • mobile/android/worktree.properties (read by the debug build type only)

For direct Xcode / Android Studio / flutter run development, run ./scripts/mobile-worktree-overrides.sh from the repo root once per branch switch to refresh the display label (the install identity never changes); the persisted files are then picked up by any subsequent build. In the main checkout the script is a no-op that removes stale override files, restoring the plain Buzz identity.

To remove leftover worktree-suffixed installs from booted iOS simulators and connected Android emulators, run just mobile-clean (add --dry-run via ./scripts/mobile-worktree-clean.sh --dry-run to preview). Production installs are never touched.

Checks

dart format --output=none --set-exit-if-changed .
flutter analyze
flutter test

Or from the repo root: just mobile-check and just mobile-test.

Android release signing

Android release builds fail unless all upload-key inputs are supplied through the environment:

  • BUZZ_ANDROID_UPLOAD_KEYSTORE_PATH: path to a CI-vended keystore file
  • BUZZ_ANDROID_UPLOAD_KEYSTORE_PASSWORD
  • BUZZ_ANDROID_UPLOAD_KEY_ALIAS
  • BUZZ_ANDROID_UPLOAD_KEY_PASSWORD

The keystore path must be absolute, and the keystore must remain outside the repository. Development and debug builds do not require these variables.

Release pipelines that sign through the central APK Signer service instead of a local upload keystore must set BUZZ_ANDROID_RELEASE_SIGNING=external. That mode produces an unsigned release bundle and refuses to run if any BUZZ_ANDROID_UPLOAD_* value is also set.

Architecture

lib/
├── main.dart              # Entry point, Riverpod bootstrap
├── app.dart               # MaterialApp with theme
├── shared/
│   └── theme/             # Catppuccin light/dark, spacing tokens, extensions
└── features/
    └── home/              # Placeholder home surface
  • State management: Riverpod + Hooks (HookConsumerWidget)
  • Theme: Catppuccin Latte (light) / Macchiato (dark) — matches desktop
  • Spacing: Grid tokens for consistent spacing
  • Linting: flutter_lints + riverpod_lint via custom_lint
  • Feature isolation: No cross-feature imports except shared/