rama/halobestie-clone
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Phase 5/6 polish: end-session flow, notif sound on API 33+, Xendit webview

Browse Source 
Customer end-of-session (figma §6):
- PricingBottomSheet: ghost "cukup, akhiri sesi" CTA + dedup divider
- chat_screen._runEndSessionFlow chains ConfirmEndStep1 → ConfirmEndStep2
  → ClosingMessageSheet (or "lewati saja" → close + /home). The four
  popup/sheet widgets already existed; this commit just wires them
- showModalBottomSheet: showDragHandle=false to suppress the Material 3
  auto-injected handle that was stacking with our own pill

Notification sound on API 33+:
- Bump channel halobestie_chat_v1 → halobestie_chat_v2, created from
  native Kotlin in MainActivity.kt with AudioAttributes contentType
  CONTENT_TYPE_SONIFICATION. flutter_local_notifications' default of
  CONTENT_TYPE_UNKNOWN was causing Android 13 to silently drop audio
  focus while the notification still posted (isNoisy=true). Both apps
- Backend FCM payload channelId updated to v2
- AndroidManifest meta-data: default_notification_icon + color → brand
  silhouette tinted pink instead of generic Android bell. Both apps

Customer pairing reliability:
- pairing_notifier: applyPairedFromPush({sessionId, mitraName}) unsticks
  searching screen when WS push failed and FCM/active-session-poll is
  the first signal. Idempotent across PairingSearchingData,
  PairingTargetedWaitingData, PairingErrorData (covers ALREADY_ACTIVE)
- notification_service: dispatches every FCM data payload to an
  onDataMessage callback (foreground + tap + cold-start). main.dart
  wires that to applyPairedFromPush on type=='paired'. Foreground
  'paired' no longer renders a local banner — screen self-advances
- main.dart activeSession listener also calls applyPairedFromPush when
  a session appears server-side while pairing is in a waiting state.
  Covers stale ALREADY_ACTIVE recovery without a full page refresh

Auth refresh token race:
- auth_notifier._refreshFromStorage shares a single in-flight Future
  across all callers (Auth.build + 401-retry path). Backend rotates
  refresh tokens, so concurrent callers using the same stored token
  would race → loser 401s → catch wipes flutter_secure_storage → user
  appears logged out after kill+reopen

Polish:
- method_pick_screen: resizeToAvoidBottomInset=false — prevents the
  one-frame overflow when entering with the previous screen's keyboard
  still animating out
- bestie_history: BestieHistoryItem now carries `status` (backend
  already returns it). Removed _rawHistoryProvider that fetched the
  same endpoint just to read status; the two providers could go out
  of sync mid-rebuild and throw RangeError(length) on indexing

Xendit Stage 8 (carried from WIP):
- xendit_checkout_screen: embedded webview hosting Xendit's invoice
  page (intercepts halobestie:// deeplink + return-page URLs for
  deterministic pop)
- waiting_payment_screen: auto-pushes the webview when the backend
  payload includes xendit_invoice_url; spinner card + "Buka ulang
  halaman pembayaran" CTA for the QR-fallback path
- pubspec: webview_flutter ^4.13.0

Maestro infra:
- subflows/onboarding_returning_user: drop the "Mulai" carousel wait
  (splash auto-advances since 2026-05-26); tap phone-field hint
  instead of point; drop hideKeyboard (sends BACK → /home when the
  IME isn't actually up)
- New flow ts-customer-06-01-end_session_via_timeup_sheet: drives
  the full path to the chat-expired banner. Last step blocked by a
  Maestro+Flutter gesture quirk on the perpanjang ElevatedButton
  (raw `adb input tap` works at the same coords). Documented in
  memory; deeplink fixture or manual verify recommended
- ChatExpiredBanner button wrapped with Semantics(identifier:
  'chat_extend_button', button: true, onTap: …) — good hygiene for
  future tests even though it doesn't fix the dadb tap issue

.dev/: tracked wsl_emulator_bridge.ps1 + wsl_tcp_relay.py for
Maestro-on-WSL setup (Windows-side netsh portproxy + WSL-side
loopback relays). Both referenced from existing CLAUDE.md notes.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Ramadhan Sjamsani
2026-05-28 21:45:46 +08:00
parent 2c95fd040d
commit 3a0cdf5c4e
28 changed files with 1424 additions and 159 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
client_app/lib/core/auth/auth_notifier.dart
View File

@@ -78,6 +78,14 @@ class AuthNeedsDisplayNameData extends AuthData {
class Auth extends _$Auth {
final _storage = TokenStorage();
// Coalesce concurrent _refreshFromStorage calls. The backend rotates the
// refresh token on every successful call — so if `build()` and an
// api_client 401-retry both fire refresh on the same stored token, one
// wins, the other gets 401, and the loser's catch block calls
// `_storage.clear()`, wiping the freshly-rotated token. Sharing a single
// in-flight Future across all callers prevents the double-fire.
Future<Map<String, dynamic>?>? _inFlightRefresh;
ApiClient get _apiClient => ref.read(apiClientProvider);
AuthBridge get _bridge => ref.read(authBridgeProvider);
@@ -96,7 +104,12 @@ class Auth extends _$Auth {
// ---------------- Refresh / bootstrap ----------------
Future<Map<String, dynamic>?> _refreshFromStorage() async {
Future<Map<String, dynamic>?> _refreshFromStorage() {
return _inFlightRefresh ??= _doRefreshFromStorage()
.whenComplete(() => _inFlightRefresh = null);
}
Future<Map<String, dynamic>?> _doRefreshFromStorage() async {
final refreshToken = await _storage.readRefreshToken();
if (refreshToken == null) return null;
@@ -106,7 +119,7 @@ class Auth extends _$Auth {
data: {'refresh_token': refreshToken},
skipAuth: true,
);
return _applyTokens(response);
return await _applyTokens(response);
} catch (_) {
await _storage.clear();
_bridge.clear();

58
client_app/lib/core/notifications/notification_service.dart
View File

@@ -7,22 +7,46 @@ import 'package:go_router/go_router.dart';
class NotificationService {
static final _localNotifications = FlutterLocalNotificationsPlugin();
static GoRouter? _router;
static void Function(Map<String, dynamic> data)? _onDataMessage;
static bool _initialized = false;
// Channel ID bumped (`chat_messages` → `halobestie_chat_v1`) when the
// branded notification sound was introduced. Android binds sound to a
// channel at create time on API 26+, so an existing channel can't pick
// up a new sound — a fresh ID is the only way. Backend FCM payloads
// target the same ID — see backend/src/services/notification.service.js.
// Channel ID bumped to v2 — v1 was created by flutter_local_notifications
// with AudioAttributes content_type=CONTENT_TYPE_UNKNOWN (the plugin's
// AndroidNotificationChannel doesn't expose contentType), which Android 13+
// silently treats as non-noisy when routing — notifications post and are
// tagged isNoisy=true, but systemui never requests audio focus and the
// sound never plays. v2 is created natively in MainActivity.kt with
// CONTENT_TYPE_SONIFICATION so audio routing works. Backend FCM payloads
// target this ID — see backend/src/services/notification.service.js.
//
// We still pass the channel definition here so `_localNotifications.show()`
// has the channel id/name/description; createNotificationChannel below is a
// no-op when the native channel already exists (channels are immutable on
// API 26+).
static const _channel = AndroidNotificationChannel(
'halobestie_chat_v1',
'halobestie_chat_v2',
'Chat HaloBestie',
description: 'Notifications for incoming chat messages and pairing requests',
importance: Importance.high,
sound: RawResourceAndroidNotificationSound('halobestie_notif'),
);
static Future<void> initialize(GoRouter router) async {
/// `onDataMessage` is invoked with the FCM `data` payload on every delivery
/// (foreground, background-tap, or cold-start tap). It runs *in addition to*
/// — and before — the navigation logic, so callers can sync app state (e.g.
/// advance the PairingNotifier when a `paired` push arrives because the WS
/// path failed). Keep it side-effect-only; don't block.
static Future<void> initialize(
GoRouter router, {
void Function(Map<String, dynamic> data)? onDataMessage,
}) async {
_router = router;
_onDataMessage = onDataMessage;
// Guard against re-attaching FCM listeners on every rebuild — main.dart
// calls this from `build()`, so without the flag we'd accumulate one
// extra subscription per rebuild and fire the handler N times per push.
if (_initialized) return;
_initialized = true;
// Create Android notification channel
await _localNotifications
@@ -52,9 +76,19 @@ class NotificationService {
}
static void _onForegroundMessage(RemoteMessage message) {
// Always dispatch the data payload first so app state stays in sync
// (e.g. PairingNotifier advances on `paired`) even if there's no
// notification body to display.
_onDataMessage?.call(message.data);
final notification = message.notification;
if (notification == null) return;
// `paired` while the app is already foreground: the pairing state will
// navigate the user to the chat screen in ~2s — a redundant banner on
// top of that transition is just noise.
if (message.data['type'] == 'paired') return;
_localNotifications.show(
id: notification.hashCode,
title: notification.title,
@@ -66,6 +100,12 @@ class NotificationService {
channelDescription: _channel.description,
importance: Importance.high,
priority: Priority.high,
// Foreground-path icon override. The OS will tint this monochrome
// (alpha-only content) and apply the color set in AndroidManifest's
// default_notification_color meta-data. ic_launcher_foreground is
// the adaptive icon's foreground layer (white HaloBestie logo on
// transparent) — renders as the brand-pink HaloBestie silhouette.
icon: 'ic_launcher_foreground',
// API 26+ ignores this in favor of the channel's sound; included
// for the API 24/25 path where channels don't exist yet.
sound: const RawResourceAndroidNotificationSound('halobestie_notif'),
@@ -93,6 +133,10 @@ class NotificationService {
}
static void _navigateFromMessage(Map<String, dynamic> data) {
// Dispatch first so PairingNotifier / other state owners can react,
// even if we end up bailing out of the navigation branches below.
_onDataMessage?.call(data);
if (_router == null) return;
final sessionId = data['session_id'] as String?;
final type = data['type'] as String?;

49
client_app/lib/core/pairing/pairing_notifier.dart
View File

@@ -186,7 +186,17 @@ class Pairing extends _$Pairing {
paymentRequestId: paymentRequestId,
);
} else if (code == 'ALREADY_ACTIVE') {
state = const PairingErrorData('Kamu sudah memiliki sesi aktif.');
// Stale in-flight session/request on the backend. The session may
// already have flipped to ACTIVE (mitra accepted the previous
// attempt while this new request was in-flight) — refresh now so
// the activeSession listener in main.dart can advance us out of
// this error without waiting for the next 15s poll tick. If the
// pre-existing session is still SEARCHING / PENDING_ACCEPTANCE,
// the next poll that surfaces an ACTIVE session will trigger the
// same recovery via applyPairedFromPush(PairingErrorData → ...).
state = const PairingErrorData('Kamu sudah memiliki sesi aktif. Menyambungkan...');
// ignore: discarded_futures
ref.read(activeSessionProvider.notifier).refresh();
} else {
state = const PairingErrorData('Gagal memulai. Coba lagi.');
}
@@ -322,6 +332,43 @@ class Pairing extends _$Pairing {
state = const PairingInitialData();
}
/// Out-of-band "paired" signal — fired when the backend's WS push to the
/// customer failed and the FCM fallback (or a post-resume activeSession
/// refresh) is the first thing to inform us that pairing succeeded.
///
/// Mirrors the WS `paired` branch in `_onWsEvent`: drops the WS+countdown,
/// flashes `BestieFoundData` for ~2s, then settles into `ActiveData`.
/// Idempotent — bails when we already know about this sessionId (so a
/// foreground FCM + activeSession-poll race doesn't double-fire).
///
/// Also accepts [PairingErrorData] as a valid prior state: the
/// `ALREADY_ACTIVE` recovery path lands the notifier in error while the
/// pre-existing session is still pending acceptance on the backend, and the
/// activeSession poll is what eventually surfaces the paired session.
Future<void> applyPairedFromPush({
required String sessionId,
required String mitraName,
}) async {
final current = state;
if (current is PairingBestieFoundData && current.sessionId == sessionId) return;
if (current is PairingActiveData && current.sessionId == sessionId) return;
if (current is! PairingSearchingData &&
current is! PairingTargetedWaitingData &&
current is! PairingInitialData &&
current is! PairingErrorData) {
return;
}
_cleanup();
state = PairingBestieFoundData(sessionId: sessionId, mitraName: mitraName);
// ignore: unawaited_futures
ref.read(activeSessionProvider.notifier).refresh();
await Future.delayed(const Duration(seconds: 2));
if (state is PairingBestieFoundData &&
(state as PairingBestieFoundData).sessionId == sessionId) {
state = PairingActiveData(sessionId: sessionId, mitraName: mitraName);
}
}
/// "Coba Cari Lagi" CTA on the S7 Timeout screen when the payment was kept
/// `confirmed` (retryable failure). Re-blasts on the same payment session.
///