Mobile Platform
Version : 1.0
Statut : Architecture cible
ADR : MOBILE-009
1. Objectif
Ce document décrit l'architecture globale de la plateforme mobile DMV.
Contrairement aux documents précédents qui décrivent des composants particuliers (Cache Engine, Synchronization Engine, Native Features...), celui-ci explique comment l'ensemble fonctionne comme une plateforme cohérente.
Il constitue le document de référence de toute l'architecture mobile.
État actuel
La plateforme existe aujourd'hui comme un ensemble cohérent mais non encore encapsulé dans un runtime mobile complet : applications web, API Laravel, Supabase Auth, Supabase PostgreSQL, Storage/RPC selon les modules, Cloudflare et backoffice séparé.
Les responsabilités sont déjà partiellement séparées, mais certaines intégrations front communiquent encore directement avec Supabase pour des besoins historiques ou spécialisés.
Architecture cible
DMV Mobile devient une plateforme d'exécution unique pour dmv-public et dmv-workspace, avec une couche mobile transversale : Capacitor, Native Platform, Cache Engine et Synchronization Engine.
Laravel reste l'orchestrateur métier. Supabase reste le socle Auth/PostgreSQL/Storage selon les usages validés.
Migration
La migration consiste à :
- conserver les applications web comme socle ;
- encapsuler leur exécution dans DMV Mobile ;
- formaliser les contrats entre React, la plateforme mobile et Laravel ;
- réduire les accès directs Supabase non nécessaires ;
- documenter explicitement les accès Supabase conservés.
2. Positionnement
DMV Mobile n'est pas une application.
DMV Mobile est une plateforme d'exécution.
Elle fournit un environnement dans lequel s'exécutent :
- dmv-public
- dmv-workspace
Ces applications restent totalement indépendantes de la plateforme mobile.
Autrement dit :
DMV Mobile Platform
│
┌──────────────┴──────────────┐
│ │
dmv-public dmv-workspace
│ │
└──────────────┬──────────────┘
│
Laravel API
│
PostgreSQL
3. Les couches
La plateforme est organisée en plusieurs couches.
Interface
Applications React.
Responsable :
- affichage
- UX
- navigation
Ne connaît jamais Android ou iOS.
Platform Services
Services fournis par la plateforme mobile.
Exemples :
- Native Features
- Cache Engine
- Synchronization Engine
- Navigation Engine
- Session Manager
Cette couche masque totalement Capacitor.
Le Navigation Engine (détaillé dans 16-navigation-engine.md) est le seul de ces services responsable de la question "où aller" — les autres répondent respectivement à "quelles données", "comment rester synchronisé" et "quelles capacités natives sont disponibles".
Runtime
Capacitor.
Responsable :
-
Android
-
iOS
-
Plugins
-
Lifecycle
Backend
Cloudflare
↓
Laravel
↓
PostgreSQL
4. Cycle de vie
La plateforme gère le cycle de vie complet de l'application.
États possibles :
Not Running
↓
Launching
↓
Foreground
↓
Inactive
↓
Background
↓
Suspended
↓
Terminated
Chaque changement d'état peut déclencher des actions spécifiques.
5. Démarrage
Lors du lancement :
Splash
↓
Chargement configuration
↓
Session
↓
Préférences
↓
Cache
↓
Synchronisation légère
↓
Application
L'objectif est d'obtenir une ouverture quasi instantanée.
6. Gestion de la session
La plateforme est responsable :
-
ouverture
-
expiration
-
renouvellement
-
déconnexion
Les applications React n'ont jamais à gérer ces aspects.
7. Gestion réseau
La plateforme surveille :
-
Wi-Fi
-
4G
-
5G
-
Ethernet
-
absence réseau
Les applications ne vérifient jamais directement la connectivité.
Elles interrogent uniquement la plateforme.
8. Gestion mémoire
La plateforme surveille :
-
mémoire disponible
-
stockage
-
batterie
Elle peut demander au Cache Engine de réduire son empreinte mémoire.
9. Communication interne
Tous les composants communiquent via des services.
Jamais directement.
Exemple :
React
↓
SessionService
↓
Platform
↓
Laravel
Cette architecture réduit fortement le couplage.
10. Résilience
La plateforme doit survivre :
-
aux coupures réseau ;
-
aux mises en veille ;
-
aux changements d'orientation ;
-
aux changements de thème ;
-
aux changements de langue.
Aucune perte de contexte ne doit se produire.
11. Observabilité
La plateforme produit des événements techniques.
Exemples :
Application démarrée.
Cache vidé.
Synchronisation lancée.
Notification ouverte.
Connexion perdue.
Ces événements servent au diagnostic.
Ils ne contiennent jamais de données personnelles.
12. Évolutivité
Toute nouvelle capacité mobile devra être intégrée sous forme de Platform Service.
Exemples :
WalletService
HealthService
WatchService
WidgetService
NFCService
Le cœur de la plateforme reste inchangé.
13. Décisions figées
✓ DMV Mobile est une plateforme d'exécution.
✓ Les applications React restent indépendantes.
✓ Toute fonctionnalité native passe par un Platform Service.
✓ Capacitor reste invisible pour les applications.
✓ Le backend reste la source de vérité.
✓ La plateforme est responsable du cycle de vie de l'application.
Conclusion
La plateforme mobile constitue le socle commun de toutes les expériences mobiles DMV.
Elle fournit un environnement stable, cohérent et évolutif permettant aux applications React de fonctionner sur Android et iOS sans dépendre des spécificités de chaque système.
Les futures évolutions (Widget, Wallet, Watch, Health...) devront s'intégrer dans cette architecture sans remettre en cause les principes fondamentaux.