Aller au contenu principal

Native Features

Version : 1.0

Statut : Architecture cible

Décision : MOBILE-008

1. Objectif​

L'application DMV repose principalement sur des technologies Web (React + Capacitor).

Cependant, certaines fonctionnalités offertes par les systèmes Android et iOS ne sont pas accessibles directement depuis le navigateur.

Le rôle de la couche Native Features est de fournir un accès uniforme à ces capacités sans introduire de logique métier dans la partie native.

Elle constitue une couche d'intégration entre le système d'exploitation et les applications React.

État actuel​

Aucun shell Capacitor complet n'est encore identifié dans le code audité. Les applications web portent déjà l'essentiel de l'expérience et certaines capacités web, mais la couche Native Platform décrite ici reste une cible d'architecture.

Architecture cible​

La Native Platform centralise l'accès aux capacités Android et iOS : notifications, caméra, galerie, partage, détection réseau, stockage sécurisé, géolocalisation et ouverture de liens.

Elle expose des services techniques aux applications React, sans logique métier et sans décision fonctionnelle.

Migration​

La migration consiste à :

  1. créer le shell Capacitor ;
  2. intégrer les plugins natifs un par un ;
  3. fournir une abstraction React stable pour chaque capacité ;
  4. remplacer les appels directs aux APIs natives par cette abstraction ;
  5. auditer chaque fonctionnalité pour garantir qu'aucune règle métier ne migre dans le natif.

2. Philosophie​

Le téléphone possède de nombreuses capacités.

Ces capacités ne sont pas le métier.

Le métier reste :

  • Laravel
  • PostgreSQL
  • dmv-public
  • dmv-workspace

Le natif apporte uniquement des services.

Application React

        │

 Native Service Layer

        │

 Capacitor Plugins

        │

 Android / iOS

3. Principes d'architecture​

Toutes les fonctionnalités natives doivent respecter les principes suivants.

Aucune logique métier​

Le code natif ne prend jamais de décision fonctionnelle.

Il fournit uniquement un service.

Exemple :

La caméra fournit une photo.

Elle ne décide jamais :

  • où la stocker ;
  • à quel acteur elle appartient ;
  • si elle est valide.

Interface unique​

React ne dialogue jamais directement avec Capacitor.

Toutes les fonctionnalités passent par une couche d'abstraction.

Exemple :

CameraService

NotificationService

LocationService

ShareService

Ainsi, si Capacitor est remplacé un jour, le reste de l'application reste inchangé.

Dégradation élégante​

Une fonctionnalité native peut être :

  • absente ;
  • refusée ;
  • indisponible.

L'application doit toujours continuer à fonctionner.

Exemple :

GPS refusé

↓

Sélection manuelle de la commune.

Permissions à la demande​

Aucune permission n'est demandée au lancement.

Une permission est demandée uniquement lorsqu'une fonctionnalité en a réellement besoin.

4. Architecture​

React

↓

Native Service

↓

Capacitor

↓

Android / iOS

Chaque service possède une responsabilité unique.

5. Services natifs​

CameraService​

Responsabilités :

  • prendre une photo ;
  • ouvrir la galerie ;
  • retourner une image.

Utilisations :

  • avatar ;
  • logo acteur ;
  • bannière ;
  • publication.

NotificationService​

Responsabilités :

  • enregistrer le téléphone ;
  • recevoir les notifications ;
  • ouvrir les Deep Links.

Ne décide jamais du contenu des notifications.

LocationService​

Responsabilités :

  • récupérer la position GPS ;
  • suivre les changements si autorisés.

Utilisations :

  • commune actuelle ;
  • recherche autour de moi ;
  • calcul de distance.

ShareService​

Utilisé pour partager :

  • publication ;
  • événement ;
  • acteur ;
  • commune.

Le contenu est généré par React.

FileService​

Gestion :

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

NetworkService​

Informe l'application :

  • connexion disponible ;
  • perte réseau ;
  • type de réseau.

PreferencesService​

Stockage léger :

  • thème ;
  • langue ;
  • derniers contextes.

BiometricsService (future)​

Authentification :

  • Face ID
  • Touch ID
  • Empreinte Android

HapticService​

Retour tactile.

Exemples :

  • validation ;
  • erreur ;
  • succès.

ClipboardService​

Copie :

  • liens ;
  • codes ;
  • coordonnées.

6. Gestion des permissions​

Les permissions suivent toujours le même cycle.

Fonction demandée

↓

Permission nécessaire ?

↓

Oui

↓

Demande utilisateur

↓

Autorisée

↓

Fonction exécutée

↓

Refusée

↓

Alternative proposée

Jamais de permission "préventive".

7. Stratégie de dégradation​

Toutes les fonctionnalités natives doivent posséder une solution de secours.

FonctionAlternative
GPSChoix manuel de la commune
CaméraGalerie
NotificationsCentre de notifications DMV
BiométrieMot de passe
NFCQR Code
WalletPDF

Aucune fonctionnalité ne doit bloquer l'utilisation de DMV.

8. Notifications Push​

Les notifications constituent l'une des fonctionnalités majeures.

Exemples :

  • nouvelle publication favorite ;
  • alerte mairie ;
  • rappel d'événement ;
  • message Workspace.

Une notification ouvre toujours directement la ressource concernée.

Jamais l'écran d'accueil.

9. Caméra​

La caméra est utilisée pour :

  • photo de profil ;
  • logo ;
  • bannière ;
  • publication.

Les traitements (compression, validation, stockage) restent réalisés côté React et serveur.

10. Géolocalisation​

La géolocalisation est utilisée uniquement lorsque cela apporte une réelle valeur.

Exemples :

  • déterminer la commune actuelle ;
  • afficher les acteurs proches ;
  • rechercher autour de moi.

Elle n'est jamais utilisée en permanence.

11. Stockage local​

Le stockage local est réservé à :

  • cache ;
  • brouillons ;
  • préférences.

Jamais aux données métier.

Les fonctionnalités natives doivent ouvrir directement les ressources DMV, mais chaque type de lien a un rôle distinct.

  • Les URLs HTTPS restent l'adresse canonique publique et partageable : https://www.dansmonvillage.fr/....
  • Les Universal Links iOS associent ces URLs HTTPS à l'application installée.
  • Les Android App Links jouent le même rôle côté Android.
  • Le schéma dmv:// est réservé aux liens internes contrôlés par l'application ou aux intégrations natives qui ne nécessitent pas d'URL publique.

Exemples internes :

dmv://publication/123

dmv://commune/sete

dmv://acteur/bibliotheque

dmv://workspace/acteur/tennis-club

Une notification peut transporter une URL HTTPS canonique ou une route interne. La Native Platform la résout ensuite vers l'écran DMV correspondant.

13. Évolutions futures​

L'architecture doit permettre d'ajouter sans refonte :

Widgets​

Accueil Android

Widgets iOS

Live Activities​

Suivi d'événement.

Dynamic Island​

Notifications contextuelles.

Wallet​

Cartes :

  • adhérent ;
  • bibliothèque ;
  • piscine.

NFC​

Contrôle d'accès.

Pointage.

Badge.

Apple Watch​

Notifications.

Validation rapide.

Consultation.

Wear OS​

Même principe.

Android Auto​

Informations utiles pendant un trajet.

CarPlay​

Fonctionnalités compatibles avec la conduite.

14. Sécurité​

Toutes les API natives doivent respecter :

  • les permissions système ;
  • les recommandations Apple ;
  • les recommandations Google.

Aucune donnée sensible ne doit rester stockée en clair.

15. ADR​

Alternatives étudiées​

Utiliser directement Capacitor partout​

Rejetée.

Couplage trop fort.

Couche d'abstraction Native Services​

Retenue.

Simple.

Évolutive.

Testable.

16. Décisions figées​

✅ Aucun métier dans le natif.

✅ Tous les appels passent par une couche d'abstraction.

✅ Les permissions sont demandées uniquement au moment du besoin.

✅ Chaque fonctionnalité possède une solution de secours.

✅ Les évolutions futures (Watch, Wallet, NFC, Widgets...) doivent s'intégrer sans modifier l'architecture existante.

Conclusion​

La couche Native Features permet à DMV de bénéficier des capacités offertes par Android et iOS tout en conservant une architecture propre.

Le téléphone apporte des services.

La plateforme conserve le métier.

Cette séparation garantit une maintenance simple, une évolution durable et une compatibilité avec les futures technologies mobiles.