Aller au contenu principal

Capacitor

Version : 1.0

Statut : Architecture cible

1. Objectif​

Capacitor constitue le shell natif officiel de DMV Mobile.

Il permet de transformer les applications web existantes en une véritable application Android et iOS sans réécrire la plateforme.

Le rôle de Capacitor n'est pas d'exécuter le métier.

Son rôle est d'apporter les capacités natives du téléphone.

2. Pourquoi Capacitor ?​

Après étude de plusieurs solutions (Flutter, React Native, développement natif...), Capacitor a été retenu pour plusieurs raisons.

Réutilisation​

DMV possède déjà :

  • dmv-public
  • dmv-workspace

Ces applications sont modernes et maintenues.

Les réécrire n'apporterait aucune valeur métier.

Une seule plateforme​

Capacitor permet de conserver :

  • une seule interface ;
  • une seule logique ;
  • une seule API.

Les développements Web profitent immédiatement à l'application mobile.

Maintenance​

Une correction réalisée sur :

dmv-public

est immédiatement disponible :

  • sur le Web ;
  • sur Android ;
  • sur iPhone.

Il n'existe donc pas deux développements parallèles.

Évolutivité​

Capacitor permet d'ajouter progressivement :

  • notifications ;
  • caméra ;
  • biométrie ;
  • widgets ;
  • NFC ;
  • Wallet ;
  • Apple Watch ;
  • Wear OS.

Sans réécriture complète.

3. Architecture​

Android
             │
             │
         Capacitor
             │
     ┌───────┴────────┐
     │                │
dmv-public      dmv-workspace
     │                │
     └───────┬────────┘
             │
     Cloudflare Worker
             │
        Laravel API
             │
        PostgreSQL

Capacitor ne remplace aucun composant.

Il ajoute simplement une couche native.

4. Responsabilités​

Capacitor est responsable :

  • du démarrage de l'application ;
  • des API natives ;
  • des permissions Android/iOS ;
  • des plugins ;
  • du stockage local ;
  • de la communication avec le système.

5. Ce que Capacitor ne fait jamais​

Capacitor ne doit jamais gérer :

  • les utilisateurs ;
  • les rôles ;
  • les permissions métier ;
  • les acteurs ;
  • les communes ;
  • les publications ;
  • les calculs métier.

Toutes ces opérations restent côté serveur.

6. Les plugins​

La liste suivante constitue la cible actuelle.

Application​

Gestion :

  • cycle de vie ;
  • reprise ;
  • fermeture.

Browser​

Ouverture des liens externes.

Exemples :

  • site web d'un acteur ;
  • Facebook ;
  • Instagram.

Camera​

Utilisée notamment pour :

  • photo de profil ;
  • logo ;
  • bannière ;
  • pièces jointes.

Filesystem​

Stockage :

  • cache ;
  • brouillons ;
  • téléchargements.

Network​

Détection :

  • connexion ;
  • perte réseau ;
  • reprise.

Preferences​

Stockage léger :

  • préférences ;
  • paramètres.

Push Notifications​

Notifications :

  • mairie ;
  • événements ;
  • rappels ;
  • Workspace.

Share​

Partage natif.

Geolocation​

Recherche locale.

Commune actuelle.

Navigation.

Splash Screen​

Affichage au démarrage.

Status Bar​

Intégration Android/iOS.

Keyboard​

Gestion du clavier natif.

Haptics​

Retour haptique.

7. Mises à jour​

Deux types de mises à jour existent.

Métier​

Exemple :

  • nouvelle Card ;
  • nouveau composant React ;
  • nouveau moteur ;
  • nouvelle fonctionnalité Web.

Aucune publication Store n'est nécessaire lorsque l'évolution est servie par l'infrastructure web existante et ne modifie pas le code exécutable natif ni le bundle soumis aux Stores.

Native​

Exemple :

  • nouveau plugin ;
  • nouvelle permission ;
  • évolution Capacitor.

Une publication Android/iOS est alors nécessaire.

8. Organisation du projet​

Le shell Capacitor constitue un projet dédié.

Il embarque :

  • Android
  • iOS

Les applications React restent indépendantes.

L'objectif est de limiter autant que possible le code spécifique mobile.

9. Gestion des permissions​

Les permissions sont demandées uniquement lorsqu'elles deviennent nécessaires.

Exemple :

Première ouverture

↓

Aucune permission

Premier ajout d'une photo

↓

Demande caméra

Première notification

↓

Demande notifications

Jamais l'ensemble des permissions au lancement.

Le shell doit être capable d'ouvrir directement :

  • une publication ;
  • un acteur ;
  • une commune ;
  • un événement ;
  • Mon Espace ;
  • le Workspace.

Exemple :

dmv://publication/12345

Les Deep Links devront également distinguer :

  • les URLs HTTPS canoniques ;
  • Android App Links ;
  • Universal Links iOS ;
  • le schéma interne dmv://.

11. Philosophie​

Le shell Capacitor doit rester le plus simple possible.

Toutes les évolutions doivent être réalisées :

  • dans dmv-public ;
  • dans dmv-workspace.

Le shell n'est qu'un conteneur.

12. Décisions d'architecture​

Les décisions suivantes sont considérées comme figées.

✅ Capacitor constitue le shell officiel.

✅ Aucun métier dans Capacitor.

✅ Les plugins restent génériques.

✅ Les applications React restent responsables de l'interface.

✅ Laravel reste responsable du métier.

✅ Les Stores sont requis pour les évolutions natives, les permissions, le shell, les plugins et tout code exécutable soumis avec l'application.

Conclusion​

Capacitor permet d'offrir une véritable expérience mobile tout en conservant une plateforme unique.

Son rôle est volontairement limité.

Cette simplicité constitue l'une des principales forces de l'architecture DMV Mobile.