[UI mobile] Redirection vers l'appli + page de téléchargement #84

New issue

Closed

opened 2026-09-07 11:32:55 +02:00 by kyuno · 0 comments

kyuno commented

2026-09-07 11:32:55 +02:00

Owner

Résumé

Quand le site web est visité depuis un navigateur mobile, tenter d'ouvrir
l'appli Android installée ; si elle ne s'ouvre pas (non installée),
rediriger vers une page de téléchargement dédiée. Fait partie du chantier
"UI mobile & tablette" (voir le ticket socle de ce même chantier).

Contexte

Vérifié dans le code, pas supposé : aucune infra de deep-link n'existe
aujourd'hui — pas de scheme personnalisé, pas d'Android App Links, pas
d'assetlinks.json, pas de listener appUrlOpen côté JS.
apps/web/android/app/src/main/AndroidManifest.xml ne déclare qu'un seul
<intent-filter> (le lanceur standard MAIN/LAUNCHER).

Décision d'approche (tranchée avec l'utilisateur en amont)

Scheme personnalisé + tentative JS avec délai, pas Android App Links —
App Links intercepterait TOUT clic vers le domaine (pas seulement la
landing page) une fois vérifié, et demande de maintenir assetlinks.json +
l'empreinte SHA-256 du keystore de release en synchronisation, pour un
gain marginal (pas de prompt "ouvrir avec") face à l'approche plus légère.

Contenu attendu

Détection "navigateur mobile" côté web (UA + largeur — aucun utilitaire
de ce type n'existe encore dans le repo, à créer).
Nouveau <intent-filter> additif dans AndroidManifest.xml
déclarant un scheme personnalisé (ex. batchcooking://), sans toucher au
filtre MAIN/LAUNCHER existant.
Logique JS (pattern "smart app banner" classique) : tente d'ouvrir le
scheme personnalisé, délai court, si la page est toujours visible ⇒
l'appli n'est pas installée ⇒ redirige vers /telecharger.
Nouvelle page /telecharger : reprend le lien existant
${API_BASE_URL}/mobile/download (déjà fonctionnel côté API, voir
apps/api/src/modules/mobile/ — rien à changer côté API) comme action
principale.
Doit prévoir de respecter une préférence "toujours ouvrir dans l'appli /
rester sur le web" (réglage exposé par le ticket "Onglet Paramètres
d'application" du même chantier, qui peut arriver avant ou après ce
ticket-ci) — lire un réglage désactivable, ne pas forcer la redirection
de façon inconditionnelle.

Dépendances

Indépendant des autres tickets du chantier, peut être implémenté en
parallèle.

Hors scope

Android App Links (voir décision ci-dessus). iOS (l'app n'existe que sur
Android).

## Résumé Quand le site web est visité depuis un navigateur mobile, tenter d'ouvrir l'appli Android installée ; si elle ne s'ouvre pas (non installée), rediriger vers une page de téléchargement dédiée. Fait partie du chantier "UI mobile & tablette" (voir le ticket socle de ce même chantier). ## Contexte Vérifié dans le code, pas supposé : aucune infra de deep-link n'existe aujourd'hui — pas de scheme personnalisé, pas d'Android App Links, pas d'`assetlinks.json`, pas de listener `appUrlOpen` côté JS. `apps/web/android/app/src/main/AndroidManifest.xml` ne déclare qu'un seul `<intent-filter>` (le lanceur standard `MAIN`/`LAUNCHER`). ## Décision d'approche (tranchée avec l'utilisateur en amont) Scheme personnalisé + tentative JS avec délai, **pas** Android App Links — App Links intercepterait TOUT clic vers le domaine (pas seulement la landing page) une fois vérifié, et demande de maintenir `assetlinks.json` + l'empreinte SHA-256 du keystore de release en synchronisation, pour un gain marginal (pas de prompt "ouvrir avec") face à l'approche plus légère. ## Contenu attendu - Détection "navigateur mobile" côté web (UA + largeur — aucun utilitaire de ce type n'existe encore dans le repo, à créer). - Nouveau `<intent-filter>` **additif** dans `AndroidManifest.xml` déclarant un scheme personnalisé (ex. `batchcooking://`), sans toucher au filtre `MAIN`/`LAUNCHER` existant. - Logique JS (pattern "smart app banner" classique) : tente d'ouvrir le scheme personnalisé, délai court, si la page est toujours visible ⇒ l'appli n'est pas installée ⇒ redirige vers `/telecharger`. - Nouvelle page `/telecharger` : reprend le lien existant `${API_BASE_URL}/mobile/download` (déjà fonctionnel côté API, voir `apps/api/src/modules/mobile/` — rien à changer côté API) comme action principale. - Doit prévoir de respecter une préférence "toujours ouvrir dans l'appli / rester sur le web" (réglage exposé par le ticket "Onglet Paramètres d'application" du même chantier, qui peut arriver avant ou après ce ticket-ci) — lire un réglage désactivable, ne pas forcer la redirection de façon inconditionnelle. ## Dépendances Indépendant des autres tickets du chantier, peut être implémenté en parallèle. ## Hors scope Android App Links (voir décision ci-dessus). iOS (l'app n'existe que sur Android).