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>
71 lines
2.7 KiB
TypeScript
71 lines
2.7 KiB
TypeScript
import type * as ImagePicker from "expo-image-picker";
|
|
import { Alert, Linking } from "react-native";
|
|
|
|
type Copy = {
|
|
title: string;
|
|
/** Why we need it — shown while Android will still show its own dialog. */
|
|
message: string;
|
|
/** Shown once Android has stopped showing that dialog. */
|
|
blocked: string;
|
|
openSettings: string;
|
|
cancel: string;
|
|
};
|
|
|
|
/**
|
|
* Explains a refused camera or photo-library permission, and offers the only
|
|
* way out when there is one.
|
|
*
|
|
* `granted: false` covers two states that feel completely different to a
|
|
* driver. While `canAskAgain` is true the system dialog appeared and they
|
|
* declined it, so repeating why we need it and letting them tap the button
|
|
* again is the whole fix. Once `canAskAgain` is false Android stops showing
|
|
* that dialog altogether: `requestCameraPermissionsAsync()` returns denied
|
|
* without anything appearing on screen, so from the driver's side the app has
|
|
* simply stopped asking, and no amount of tapping will ever change it. The
|
|
* only remaining route is the system settings page for the app, so that case
|
|
* gets a button that opens it rather than a message telling them to allow
|
|
* something they are never going to be offered.
|
|
*
|
|
* Android also lands drivers in that second state through no choice of their
|
|
* own: requesting a runtime permission the manifest doesn't declare is
|
|
* auto-denied and flagged as permanently denied, and the flag survives an
|
|
* update install. A driver who ran a build predating the CAMERA declaration in
|
|
* app.config.js is stuck there until they either use this button or reinstall.
|
|
*/
|
|
export const alertPermissionDenied = (
|
|
permission: ImagePicker.PermissionResponse,
|
|
copy: Copy,
|
|
) => {
|
|
// Both branches below end in an alert and nothing else, which leaves no
|
|
// trace in the logs — the reason a driver reporting "it never asks me" is
|
|
// indistinguishable from one who never tapped the button. Logging the two
|
|
// fields that decide the branch makes that difference readable.
|
|
console.log(
|
|
"[CAPTURE_PERMISSION_DENIED]: ",
|
|
JSON.stringify({
|
|
status: permission.status,
|
|
canAskAgain: permission.canAskAgain,
|
|
}),
|
|
);
|
|
|
|
if (permission.canAskAgain) {
|
|
Alert.alert(copy.title, copy.message);
|
|
return;
|
|
}
|
|
|
|
Alert.alert(copy.title, copy.blocked, [
|
|
{ text: copy.cancel, style: "cancel" },
|
|
{
|
|
text: copy.openSettings,
|
|
onPress: () => {
|
|
// Failure here is not worth a second alert on top of this one: the
|
|
// driver is already reading instructions that name the settings
|
|
// screen, and reaching it by hand still works.
|
|
void Linking.openSettings().catch((error) =>
|
|
console.log("[CAPTURE_PERMISSION_SETTINGS]: ", error),
|
|
);
|
|
},
|
|
},
|
|
]);
|
|
};
|