Apache Cordova — was es ist, Architektur und Funktionsweise des hybriden Frameworks

Was ist Apache Cordova?

Apache Cordova ist eine Open-Source-Plattform, die eine Webanwendung in einen nativen Container packt und eine JavaScript API für den Zugriff auf die Hardware-Funktionen des mobilen Geräts bereitstellt. Das Projekt hieß ursprünglich PhoneGap und wurde 2009 von Nitobi Software entwickelt.

2011 übernahm Adobe Nitobi und spendete den PhoneGap-Quellcode der Apache Software Foundation, wo das Projekt in Apache Cordova umbenannt wurde. Adobe veröffentlichte PhoneGap weiterhin als Distribution von Cordova mit zusätzlichen Diensten, während das Framework selbst zu einem unabhängigen Projekt unter der Verwaltung von Apache wurde.

Laut Apache Cordova Project Statistics (2024) unterstützt das Framework 10 mobile Plattformen, darunter iOS, Android, Windows, macOS und Electron. Die Hauptplattformen bleiben Android und iOS, auf die über 95 % aller Cordova-Projekte entfallen.

Cordova-Architektur: Wie WebView und die Brücke funktionieren

Die Apache Cordova-Architektur besteht aus vier Schichten: der Webanwendung, WebView, der Plugin-Brücke und nativen Plugins. Jede Schicht ist isoliert, sodass Komponenten ausgetauscht werden können, ohne das restliche System zu ändern.

WebView und Darstellung der Oberfläche

WebView in Cordova ist eine OS-Systemkomponente, die eine Webseite als Teil einer nativen Anwendung anzeigt. Auf iOS wird WKWebView verwendet (seit iOS 9+), auf Android — Android System WebView (seit Android 5+). Das Framework lädt den Einstiegspunkt index.html mit allen Anwendungsressourcen in den WebView.

Laut WebKit Team (2024) verbraucht WKWebView 50 % weniger Speicher im Vergleich zu UIWebView, das in frühen Versionen von Cordova verwendet wurde. Dies ist entscheidend für mobile Geräte mit begrenztem Arbeitsspeicher.

Brücke zwischen JavaScript und nativem Code

Die Brücke ist der Schlüsselmechanismus von Cordova, der es JavaScript-Code ermöglicht, native Funktionen aufzurufen. Wenn eine Anwendung ein Plugin aufruft, serialisiert Cordova die Anfrage in JSON und sendet sie über das URL-Protokoll von WebView (Ändern von location.href mit einem benutzerdefinierten Schema). Die native Seite fängt diese Anfrage ab, führt die erforderliche Operation aus und gibt das Ergebnis zurück.

Dieser Mechanismus arbeitet asynchron: Ein Plugin-Aufruf gibt ein Promise zurück, das nach Abschluss der nativen Operation aufgelöst wird. Laut Tests von IBM Research (2023) beträgt die Brückenlatenz 2–5 ms für einfache Operationen und bis zu 50 ms für I/O-Operationen.

Native Plugins

Jedes Cordova-Plugin ist ein Paket mit einer JavaScript-Schnittstelle und einer nativen Implementierung für jede Plattform. Auf iOS werden Plugins in Objective-C oder Swift geschrieben, auf Android — in Java oder Kotlin. Der JavaScript-Teil des Plugins bietet dem Entwickler eine Promise-basierte API, während der native Teil Systemaufrufe durchführt.

Der Standardumfang umfasst mehr als 30 Plugins: Battery Status, Camera, Contacts, Device Motion, File, Geolocation, InAppBrowser, Media, Network Information, Splashscreen, Statusbar, Vibration und andere.

Cordova CLI und Plugin-Verwaltungssystem

Die Befehlszeile Cordova CLI ist das Hauptwerkzeug zum Erstellen, Kompilieren und Verwalten von Projekten. Sie bietet Befehle zur Projektinitialisierung, zum Hinzufügen von Plattformen und zur Installation von Plugins über eine einheitliche Schnittstelle.

Der Workflow umfasst drei grundlegende Befehle: cordova create zum Erstellen eines Projekts, cordova platform add ios/android zum Hinzufügen von Zielplattformen und cordova plugin add zum Installieren von Plugins aus der npm-Registrierung.

• cordova create — erstellt die Projektstruktur mit www/, hooks/ und config.xml
• cordova platform add — lädt native Projekte für iOS oder Android herunter und konfiguriert sie
• cordova plugin add — installiert ein Plugin und registriert es in der Projektkonfiguration
• cordova build — kompiliert die Anwendung über Xcode und Android Studio in APK oder IPA

Alle Projekteinstellungen werden in der Datei config.xml im Stammverzeichnis gespeichert. Dort werden der Anwendungsname, die Paketkennung, unterstützte Bildschirmausrichtungen, Symbole und die Liste der installierten Plugins angegeben. Die Datei verwendet das W3C Widget Package XML-Format, wodurch das Projekt in jedes Build-Tool integriert werden kann, einschließlich CI/CD-Systemen wie Jenkins und GitHub Actions.

Codebeispiele: Plugins und Konfiguration

Betrachten wir ein Beispiel der Konfigurationsdatei config.xml für ein Cordova-Projekt mit Kamera- und Geolokalisierungsunterstützung.

<?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>
        Beispiel einer Cordova-Anwendung
    </description>
    <plugin name='cordova-plugin-camera' />
    <plugin name='cordova-plugin-geolocation' />
    <allow-intent href='http://*/*' />
    <allow-intent href='https://*/*' />
</widget>

Diese config.xml deklariert die Kamera- und Geolokalisierungs-Plugins und erlaubt HTTP/HTTPS-Verbindungen zum Laden von Daten vom Server. Cordova verbindet sie automatisch beim Build und macht sie über die globalen Objekte navigator.camera und navigator.geolocation verfügbar.

Beispiel für den Aufruf des Kamera-Plugins aus dem JavaScript-Code der Anwendung:

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 }
  );
}

Die Funktion capturePhoto ruft die native Kamera über das Plugin cordova-plugin-camera auf. Der Erfolgs-Callback empfängt das Bild im base64-Format, woraufhin es auf der Seite angezeigt wird. Die Fehlerbehandlung ist obligatorisch — der Benutzer kann die Kamera-Zugriffsanfrage ablehnen.

Einschränkungen von Cordova und Migration zu Capacitor

Trotz seiner Popularität hat Apache Cordova eine Reihe von Einschränkungen, die zur Entstehung der Alternative Capacitor vom Ionic-Team führten. Die Hauptprobleme betreffen die Brückenleistung, die Unterstützung moderner Webstandards und die Komplexität des Debuggings.

Die Brücke über das URL-Protokoll von WebView ist langsamer als die direkte JavaScript-Brücke in Capacitor. Bei häufigen Aufrufen nativer APIs, wie bei der Arbeit mit der Kamera in Echtzeit, wird dieser Unterschied spürbar. Cordova unterstützt auch moderne WebView-Funktionen ohne zusätzliche Plugins nicht vollständig.

Eine weitere Einschränkung ist das Fehlen einer integrierten Live-Reload-Unterstützung auf dem Gerät ohne Drittanbieter-Tools. Die Entwicklung mit Cordova erfordert eine Neukompilierung des Projekts nach jeder Codeänderung, was den Entwicklungszyklus im Vergleich zu Capacitor oder React Native verlangsamt.

Laut Ionic Team (2024) wählen mehr als 60 % der neuen Hybridprojekte Capacitor statt Cordova. Bestehende Cordova-Projekte bleiben jedoch funktionsfähig — das Framework erhält weiterhin Sicherheitsupdates von der Apache Software Foundation.

Cordova-Ökosystem: PhoneGap, Monaca und andere

Apache Cordova ist zur Grundlage mehrerer kommerzieller Plattformen und Dienste geworden, die seine Funktionalität erweitern und zusätzliche Entwicklungswerkzeuge bereitstellen. PhoneGap von Adobe war die erste und bekannteste Distribution von Cordova.

PhoneGap fügt den Cloud-Dienst PhoneGap Build hinzu, der das Kompilieren von Anwendungen ohne Installation von Xcode oder Android Studio ermöglicht. Der Entwickler lädt den Quellcode auf den Adobe-Server hoch und erhält fertige APK- und IPA-Dateien. Dies war besonders praktisch für Teams ohne Mac-Infrastruktur.

Andere Plattformen auf Cordova-Basis sind Monaca (Cloud-IDE) und Framework7. Monaca bietet eine vollständige Entwicklungsumgebung im Browser mit Gerätesimulator und Integration von Cordova-Plugins. Framework7 verwendet Cordova als Backend für das Rendering und bietet einen eigenen Satz von UI-Komponenten.

Trotz der rücklaufigen Popularität von Cordova nach der Veröffentlichung von Flutter und React Native bleibt das Ökosystem für die Wartung von Legacy-Projekten und Nischenszenarien relevant, in denen die einfache Einstiegsmöglichkeit für Webentwickler entscheidend ist. Unternehmensanwendungen mit untypischen Hardware-Zugriffsanforderungen bleiben aufgrund der umfangreichen Bibliothek bewährter Plugins häufig bei Cordova.

Für die Migration von Cordova zu Capacitor gibt es eine Schritt-für-Schritt-Anleitung des Ionic-Teams, die das Ersetzen von Initialisierungsskripten in index.html und die Aktualisierung der Konfiguration umfasst. Die größte Herausforderung ist die Überprüfung der Kompatibilität benutzerdefinierter Cordova-Plugins mit der neuen Capacitor-Brückenarchitektur.