kenny lopez
19b476bae5
Second pass on the community-theme sync engine, closing four data-loss defects re-flagged in review. All are silent persistence/sync bugs; no UI or feature behavior changes. Desktop, snapshot lifetime and refresh: - The appearance snapshot that seeds no-record communities was captured once and never cleared, so after a user changed glass/opacity/prominent-tab a later empty community resurrected the stale pre-migration value and republished it over the current choice. Refresh the durable snapshot on a genuine user glass edit only; accent- or theme-only edits leave it untouched so a community's own glass can never leak into the profile-wide seed, and programmatic per-community applies never reach the persist branch. - The snapshot lived on the per-community controller instance, which remounts under a keyed provider, so a full store lost it across mounts and the next community re-captured the previous one's already-rewritten appearance. Back the capture with a module-level in-memory cache so the profile's first-seen value survives a full store for the life of the process. Mobile, merge and hydration gate: - Merging desktop-only glass from a decoded full cache trusted stale fields, so a mobile accent edit republished stale glass over current relay state. Always overlay the observed remote's desktop-only fields; mobile has no glass-editing UI, so those fields are never locally authored, only inherited. - The pre-hydration hold could strand an edit forever when the first fetch returned unavailable and the subscription stayed quiet. Add a bounded-backoff hydration recovery that re-queries and releases the gate, mirroring the subscription-retry pattern, with cleanup wired into cancelPending and dispose. Co-authored-by: kenny lopez <klopez4212@gmail.com> Reviewed-by: Mongo <mongo@buzz.block.builderlab.xyz> Signed-off-by: kenny lopez <klopez4212@gmail.com>
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'sAppOverrides.xcconfigis included after it, so app-specific overrides like a personalBUNDLE_IDENTIFIERfor 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 fileBUZZ_ANDROID_UPLOAD_KEYSTORE_PASSWORDBUZZ_ANDROID_UPLOAD_KEY_ALIASBUZZ_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:
Gridtokens for consistent spacing - Linting:
flutter_lints+riverpod_lintviacustom_lint - Feature isolation: No cross-feature imports except
shared/