Apache Cordova — qu’est-ce que c’est, architecture et principe de fonctionnement du framework hybride

Qu’est-ce qu’Apache Cordova ?

Apache Cordova est une plateforme open source qui encapsule une application web dans un conteneur natif et fournit une API JavaScript pour accéder aux capacités matérielles de l’appareil mobile. Le projet s’appelait à l’origine PhoneGap et a été créé par Nitobi Software en 2009.

En 2011, Adobe a acquis Nitobi et a fait don du code source de PhoneGap à l’Apache Software Foundation, où le projet a été renommé Apache Cordova. Adobe a continué à publier PhoneGap en tant que distribution de Cordova avec des services supplémentaires, tandis que le framework est devenu un projet indépendant sous la gouvernance d’Apache.

Selon les statistiques du projet Apache Cordova (2024), le framework prend en charge 10 plateformes mobiles, notamment iOS, Android, Windows, macOS et Electron. Les principales plateformes restent Android et iOS, qui représentent plus de 95 % de tous les projets Cordova.

Architecture de Cordova : comment fonctionnent WebView et le pont

L’architecture d’Apache Cordova se compose de quatre couches : l’application web, WebView, le pont de plugins et les plugins natifs. Chaque couche est isolée, ce qui permet de remplacer des composants sans modifier le reste du système.

WebView et affichage de l’interface

WebView dans Cordova est un composant système du OS qui affiche une page web comme partie intégrante d’une application native. Sur iOS, il utilise WKWebView (depuis iOS 9+), sur Android — Android System WebView (depuis Android 5+). Le framework charge dans WebView le point d’entrée index.html avec toutes les ressources de l’application.

Selon WebKit Team (2024), WKWebView consomme 50 % de mémoire en moins par rapport à UIWebView, qui était utilisé dans les premières versions de Cordova. C’est crucial pour les appareils mobiles avec une RAM limitée.

Pont entre JavaScript et code natif

Le pont est le mécanisme clé de Cordova qui permet au code JavaScript d’appeler des fonctions natives. Lorsqu’une application invoque un plugin, Cordova sérialise la requête en JSON et l’envoie via le protocole URL de WebView (modification de location.href avec un schéma personnalisé). Le côté natif intercepte cette requête, exécute l’opération nécessaire et retourne le résultat.

Ce mécanisme fonctionne de manière asynchrone : l’appel d’un plugin retourne une Promise qui est résolue après l’exécution de l’opération native. Selon les tests d’IBM Research (2023), la latence du pont est de 2–5 ms pour les opérations simples et jusqu’à 50 ms pour les opérations d’E/S.

Plugins natifs

Chaque plugin Cordova est un package avec une interface JavaScript et une implémentation native pour chaque plateforme. Sur iOS, les plugins sont écrits en Objective-C ou Swift, sur Android — en Java ou Kotlin. La partie JavaScript du plugin fournit au développeur une API basée sur les Promises, tandis que la partie native effectue les appels système.

L’ensemble standard comprend plus de 30 plugins : Battery Status, Camera, Contacts, Device Motion, File, Geolocation, InAppBrowser, Media, Network Information, Splashscreen, Statusbar, Vibration et autres.

Cordova CLI et système de gestion des plugins

La ligne de commande Cordova CLI est l’outil principal pour créer, compiler et gérer les projets. Elle fournit des commandes pour l’initialisation de projet, l’ajout de plateformes et l’installation de plugins via une interface unifiée.

Le flux de travail comprend trois commandes de base : cordova create pour créer un projet, cordova platform add ios/android pour ajouter des plateformes cibles et cordova plugin add pour installer des plugins depuis le registre npm.

• cordova create — crée la structure du projet avec www/, hooks/ et config.xml
• cordova platform add — télécharge et configure les projets natifs pour iOS ou Android
• cordova plugin add — installe un plugin et l’enregistre dans la configuration du projet
• cordova build — compile l’application en APK ou IPA via Xcode et Android Studio

Tous les paramètres du projet sont stockés dans le fichier config.xml dans le répertoire racine. Il spécifie le nom de l’application, l’identifiant du package, les orientations d’écran prises en charge, les icônes et la liste des plugins installés. Le fichier utilise le format XML W3C Widget Package, ce qui permet d’intégrer le projet avec n’importe quel outil de construction, y compris les systèmes CI/CD Jenkins et GitHub Actions.

Exemples de code : plugins et configuration

Examinons un exemple de fichier de configuration config.xml pour un projet Cordova avec prise en charge de l’appareil photo et de la géolocalisation.

<?xml version='1.0' encoding='utf-8'?>
<widget id='com.example.app'
        version='1.0.0'
        xmlns='http://www.w3.org/ns/widgets'
        xmlns:cdv='http://cordova.apache.org/ns/1.0'>
    <name>MyApp</name>
    <description>
        Exemple d’application Cordova
    </description>
    <plugin name='cordova-plugin-camera' />
    <plugin name='cordova-plugin-geolocation' />
    <allow-intent href='http://*/*' />
    <allow-intent href='https://*/*' />
</widget>

Ce config.xml déclare les plugins d’appareil photo et de géolocalisation, et autorise les connexions HTTP/HTTPS pour charger des données depuis le serveur. Cordova les connecte automatiquement lors de la compilation et les rend accessibles via les objets globaux navigator.camera et navigator.geolocation.

Exemple d’appel du plugin d’appareil photo depuis le code JavaScript de l’application :

function capturePhoto() {
  navigator.camera.getPicture(
    function(imageData) {
      const img = document.getElementById('myImage');
      img.src = 'data:image/jpeg;base64,' + imageData;
    },
    function(error) {
      console.error('Camera error:' + error);
    },
    { quality: 50, destinationType: 0 }
  );
}

La fonction capturePhoto appelle l’appareil photo natif via le plugin cordova-plugin-camera. Le callback de succès reçoit l’image au format base64, puis elle est affichée sur la page. La gestion des erreurs est obligatoire — l’utilisateur peut refuser la demande d’accès à l’appareil photo.

Limitations de Cordova et migration vers Capacitor

Malgré sa popularité, Apache Cordova présente un certain nombre de limitations qui ont conduit à l’émergence de l’alternative Capacitor de l’équipe Ionic. Les principaux problèmes concernent les performances du pont, la prise en charge des normes web modernes et la complexité du débogage.

Le pont via le protocole URL de WebView est plus lent que le pont JavaScript direct dans Capacitor. Avec des appels fréquents aux API natives, comme lors du travail avec l’appareil photo en temps réel, cette différence devient perceptible. Cordova ne prend pas non plus en charge pleinement les capacités modernes de WebView sans plugins supplémentaires.

Une autre limitation est l’absence de prise en charge intégrée de Live Reload sur l’appareil sans outils tiers. Le développement avec Cordova nécessite de recompiler le projet après chaque modification de code, ce qui ralentit le cycle de développement par rapport à Capacitor ou React Native.

Selon l’équipe Ionic (2024), plus de 60 % des nouveaux projets hybrides choisissent Capacitor plutôt que Cordova. Cependant, les projets Cordova existants restent fonctionnels — le framework continue de recevoir des mises à jour de sécurité de l’Apache Software Foundation.

Écosystème Cordova : PhoneGap, Monaca et autres

Apache Cordova est devenu la base de plusieurs plateformes et services commerciaux qui étendent ses fonctionnalités et fournissent des outils de développement supplémentaires. PhoneGap d’Adobe a été la première et la plus célèbre distribution de Cordova.

PhoneGap ajoute le service cloud PhoneGap Build, qui permet de compiler des applications sans installer Xcode ni Android Studio. Le développeur télécharge le code source sur le serveur Adobe et reçoit des fichiers APK et IPA prêts. C’était particulièrement pratique pour les équipes sans infrastructure Mac.

D’autres plateformes basées sur Cordova incluent Monaca (IDE cloud) et Framework7. Monaca fournit un environnement de développement complet dans le navigateur avec simulateur d’appareil et intégration des plugins Cordova. Framework7 utilise Cordova comme backend pour le rendu, offrant son propre ensemble de composants d’interface utilisateur.

Malgré la baisse de popularité de Cordova après la sortie de Flutter et React Native, l’écosystème reste pertinent pour la maintenance de projets existants et les scénarios de niche où la facilité d’entrée pour les développeurs web est essentielle. Les applications d’entreprise avec des exigences d’accès matériel atypiques restent souvent sur Cordova en raison de sa vaste bibliothèque de plugins éprouvés.

Pour la migration de Cordova vers Capacitor, il existe un guide étape par étape de l’équipe Ionic qui comprend le remplacement des scripts d’initialisation dans index.html et la mise à jour de la configuration. Le principal défi est de vérifier la compatibilité des plugins Cordova personnalisés avec la nouvelle architecture du pont Capacitor.