Aller au contenu

Vue d'ensemble de l'architecture

Vue d'ensemble

L'environnement WebView contient deux runtimes indépendants :

  • Runtime JavaScript (Couche Web)

  • S'exécute dans WebView, exécute HTML/JS/CSS, et gère l'IU et la logique métier.

  • Runtime Android Natif (Couche Java/Kotlin)

  • S'exécute dans l'application Android, a accès aux capacités de l'appareil (caméra, GPS, fichiers, capteurs, Bluetooth, etc.).

Comme ces runtimes ne peuvent pas communiquer directement, nous utilisons un pont, un système de communication structuré qui transmet des messages entre JavaScript et Android.

architecture-bridge-image

  • Le pont JavaScript est une combinaison de :

    • Un objet natif exposé à JS (ex. window.NativeBridge) ou une API postMessage.
    • Un protocole de messages (messages JSON avec une action, un id, des params, etc.).
    • Mise en file d'attente, traitement par lots et routage de rappels optionnels.

  • Android natif implémente des gestionnaires pour les actions, effectue le travail sur l'appareil, puis répond à JS.

Couches d'architecture

1. Couche Application JavaScript

Il s'agit de l'application JS standard s'exécutant dans WebView : - Interactions IU - Gestion des formulaires - Navigation entre les pages - Logique applicative

Les appels aux API natives se font via une interface simplifiée, ex. : 

const photo = await Native.call("takePhoto");

2. Couche Pont JavaScript (Côté Client)

Cette couche convertit les appels de fonctions JavaScript en messages structurés, généralement JSON. Ses responsabilités principales incluent : - Création des paquets de messages - Attribution d'IDs de requête uniques - Envoi de messages à la couche native - Gestion des réponses asynchrones - Résolution ou rejet des Promises en JS

Exemple de requête JSON : 

{
  "id": "req-23",
  "action": "getLocation",
  "params": { "accuracy": "high" }
}

Lorsque le natif répond : 

{
  "id": "req-23",
  "status": "ok",
  "result": { "lat": -1.288, "lng": 36.823 }
}

Le pont JS résout la Promise correcte en fonction de id.

3. Frontière JavaScript ↔ Native

C'est la véritable « porte » entre les deux mondes.

JS → Native :

  • Se produit via addJavascriptInterface
  • JS appelle Android.postMessage(jsonString)

Native → JS :

  • Se produit via evaluateJavascript()
  • Le natif appelle le rappel JS comme suit : window.onNativeMessage(jsonString)

Caractéristiques clés :

  1. La communication est presque toujours asynchrone (car les opérations natives prennent du temps et JS attend un comportement non bloquant).
  2. Seules les chaînes peuvent traverser
  3. Nécessite la sérialisation JSON
  4. S'exécute sur des threads différents

4. Couche Pont Native (Côté Serveur)

Cette couche reçoit les messages JSON du pont JS et les route vers le module natif approprié. Responsabilités principales : - Recevoir et analyser les messages JSON entrants - Identifier l'action demandée - Exécuter la fonction native correspondante - Convertir les résultats/erreurs en JSON - Envoyer une réponse structurée à JS : Exemple de flux : cameraflow

5. Couche Application Native (Logique Appareil)

Il s'agit de la couche d'implémentation Android réelle :

  • Accès à la caméra
  • Opérations sur le système de fichiers
  • Services de localisation
  • Communication Bluetooth
  • Permissions
  • Stockage
  • Tâches en arrière-plan

Le pont place une couche d'abstraction au-dessus de ces fonctionnalités afin que JavaScript puisse les demander sans connaître leur implémentation Android.

Pourquoi cette architecture ?

  • Permet aux applications web d'accéder aux fonctionnalités natives de l'appareil
  • Permet de construire l'IU avec des technologies web
  • Séparation nette des responsabilités
  • Plus sûr qu'exposer directement plusieurs méthodes natives
  • Évolutif, nouvelles fonctionnalités natives ajoutées facilement
  • Fonctionne avec n'importe quel framework JS (React, Vue, Angular, JS pur)