Driver onboarding now photographs the licence, ID card and vehicle
registration and reads the credential fields off them, plus a camera-only
profile selfie riders check the arriving driver against. Adds in-app chat
and WebRTC calls, push-backed ride offers, ratings, cancellation and
payment sheets, settlement, and the owner dashboard endpoints behind them.
Camera permission on Android:
- Declare CAMERA and READ_MEDIA_IMAGES in the manifest. expo-image-picker's
own plugin never declares CAMERA, and Android denies a request for an
undeclared permission instantly and silently — no dialog is ever shown,
which is indistinguishable from the app not asking at all.
- Handle canAskAgain: once Android stops showing the dialog, repeating why
we need it is a dead end, so offer Open Settings instead (lib/capture-
permission.ts), matching what the location flow already did.
Session: a 401 on a request that carried a token now ends the session
instead of being reinterpreted per-screen — driver-home had been reading it
as "this user has no driver profile" and showing an onboarding form to an
already-onboarded driver. Requests without a token are exempt so a failed
sign-in doesn't sign you out, and the notification is latched per token so
concurrent polls tear the session down once. (root) gains the auth guard
that turns that into the sign-in screen; app/index.tsx only guarded the way
in, leaving a session that ended mid-screen with nowhere to go.
Also ignore .uploads/ — it holds driver licence, ID and vehicle scans plus
profile photos, which are personal data and must not be committed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
49 lines
2.2 KiB
TypeScript
49 lines
2.2 KiB
TypeScript
// Dispatch timings and distances shared by the server engine (lib/dispatch.ts)
|
|
// and both clients. They live here rather than in lib/dispatch.ts because that
|
|
// module imports the database driver and can't be pulled into the bundle.
|
|
|
|
/**
|
|
* How long a request stays open for drivers to offer on before it gives up.
|
|
*
|
|
* This is the number both sides watch: the rider sees it as "we're still
|
|
* looking", the driver as how long they have to decide before the job is off
|
|
* the board. Long enough that a driver finishing a drop-off can still take it,
|
|
* short enough that a rider standing on a corner at 4am gets an answer instead
|
|
* of a spinner.
|
|
*/
|
|
export const REQUEST_TTL_SECONDS = 150;
|
|
|
|
/**
|
|
* How far a request is broadcast from the pickup point.
|
|
*
|
|
* A request is shown to every eligible driver inside this radius rather than
|
|
* to the nearest one at a time — the rider picks from whoever volunteers, so
|
|
* dispatch's job is to put the job in front of enough people to give them a
|
|
* real choice. Matches the default radius riders see drivers over on the map,
|
|
* so a rider who can see a car can be offered by that car.
|
|
*/
|
|
export const BROADCAST_RADIUS_M = 8000;
|
|
|
|
/**
|
|
* Android notification channel for incoming ride requests. Created on the
|
|
* client with max importance, sound and vibration, and named here so the
|
|
* server sends to the same channel the client registered — a mismatch
|
|
* silently downgrades the notification to the default channel and it stops
|
|
* making noise.
|
|
*/
|
|
export const OFFER_CHANNEL_ID = "ride-offers";
|
|
|
|
/**
|
|
* How old a driver's last position ping may be before they're treated as gone,
|
|
* whatever their `online` flag says. Every rider-facing query and the dispatch
|
|
* broadcast share this, so a driver can never be visible on the map but
|
|
* unreachable by a request, or vice versa.
|
|
*
|
|
* The heartbeat fires every 5s, so this is ~24 missed beats of slack. That
|
|
* sounds generous until you watch a real phone: Android throttles JS timers
|
|
* hard once the app leaves the foreground, and gaps of 20-30s were measured on
|
|
* a device that was awake and on screen. At 60s those gaps flickered drivers
|
|
* in and out of every rider's map.
|
|
*/
|
|
export const DRIVER_STALE_SECONDS = 120;
|