doormile_milderapp/lib/helpers/rider_shell.dart

import 'package:flutter/material.dart';

import 'package:miler/data/service_profile.dart';
import 'package:miler/widget/Bottom_page.dart' as parcel;
import 'package:miler/xpress/delivery_bootstrap.dart';
import 'package:miler/xpress/widget/Bottom_page.dart' as delivery;

/// ─────────────────────────────────────────────────────────────────────────
/// WHICH APP THIS RIDER GETS
///
/// One APK, two applications. A rider signs in and lands in whichever of them
/// his tenant says he works for:
///
///  • **parcel / meals** → the Miler dashboard: floating frosted tab bar, Home ·
///    Bookings · Activity · Account, the pickup flow with its stop verification
///    and cash collection.
///
///  • **delivery** → the ported Xpress-rider dashboard under `lib/xpress`:
///    classic bottom bar, HOME · DELIVERIES · SUMMARY · PROFILE, the last-mile
///    delivery flow, in Doormile red.
///
/// ── Why the switch is here and not inside the shell ──
///
/// The obvious alternative is one `BottomPage` that picks its own tabs. It does
/// not work: the two shells disagree about how many tabs there are, what a tab
/// is called, how the bar is drawn, and — the part that actually decides it —
/// which page widgets exist. The delivery pages are a verbatim port that reads
/// its own controllers, its own models and its own colour class. Fusing the two
/// shells would mean editing the ported flow, which is the one thing the port
/// was meant to avoid.
///
/// So the shells stay whole and separate, and exactly one function chooses
/// between them.
///
/// ── Why it is a function and not a route ──
///
/// Every caller already says `Get.offAll(() => const BottomPage())`. Making this
/// a widget-returning function means those sites become
/// `Get.offAll(() => riderShell())` and nothing else about routing changes —
/// no named routes, no redirect middleware, no second navigator.
///
/// ── When it is safe to call ──
///
/// After `TenantController.load()` has run, which `main()` awaits before the
/// first frame. [ServiceProfile.active] is a plain synchronous read, so this
/// needs no context, no await and no rebuild.
///
/// ── The fallback ──
///
/// Anything that is not explicitly the delivery line gets the parcel shell,
/// matching the direction [resolveServiceProfile] already falls in. The worst
/// case that way is a delivery rider seeing the parcel dashboard, which is
/// wrong but navigable; the other direction would drop a live parcel rider into
/// an app with no pickup flow at all.
/// ─────────────────────────────────────────────────────────────────────────
Widget riderShell({int initialIndex = 0, Widget? overridePage}) {
  if (ServiceProfile.active.isDelivery) {
    // ── Why this is here and not only in `main()` ──
    //
    // `main()` boots the delivery line's controllers when the app *starts* on a
    // delivery tenant. But a rider can also arrive here without a restart: sign
    // out of a parcel account, sign in to a delivery one, and `Mpin` routes
    // straight to this function inside a process whose container only ever held
    // the parcel controllers.
    //
    // The delivery home page resolves `DeliveryController` in a field
    // initialiser, so that path would throw while building rather than degrade.
    // [registerDeliveryLine] is `isRegistered`-guarded, so calling it on every
    // shell build costs four map lookups and closes the hole.
    //
    // Deliberately the **synchronous** half of the bootstrap, not the `async`
    // one. An un-awaited async registration returns at its first `await`, the
    // framework builds this shell in the gap, and the page throws on a
    // controller that is about to exist — see the note on [registerDeliveryLine].
    // The IO half is `main()`'s to await; nothing on screen needs it to have
    // finished, because the screens re-read that state anyway.
    registerDeliveryLine();

    return delivery.BottomPage(
      initialIndex: initialIndex,
      overridePage: overridePage,
    );
  }
  return parcel.BottomPage(
    initialIndex: initialIndex,
    overridePage: overridePage,
  );
}