4.3 Interpretierte Anwendungen

Interpretierte Anwendungen gehen noch einen Schritt weiter als Hybrid-Anwendungen (vgl. Abschnitt 4.2). Benutzeroberflächen und Interaktivität werden durch plattformeigene Funktionalität erreicht und nicht in einem WebView simuliert.


Abbildung 4.3: Aufbau einer interpretierten Anwendung

Trotzdem sind interpretierte Anwendungen nicht nativ und werden nicht in der für die Plattform üblichen Programmiersprache geschrieben. Stattdessen wird die Anwendung mit einer definierten Menge von Funktionen in einer Sprache entwickelt, die vom Anbieter den nativen API-Funktionen des Zielsystems zugeordnet wurden. Auf dem mobilen Endgerät wird der Quellcode dann anhand dieser Zuordnung umgeschrieben und der entstandene native Code dynamisch ausgeführt.

Damit dies funktioniert muss auf dem Zielsystem ein Interpreter ausgeführt werden. Ein Interpreter „ist ein Computerprogramm, das einen Programm-Quellcode […] einliest, analysiert und ausführt. Die Analyse des Quellcodes erfolgt also zur Laufzeit des Programms.“ (Wikipedia, 2010b).

Dieser Interpreter wird zusammen mit dem Anwendungs-Quellcode in eine Container-anwendung eingebettet. Diese kennt die plattformspezifischen Zuordnungslisten zwischen Ansatz-Funktionen und nativer Funktionalität und steuert den Interpretationsvorgang auf dem Endgerät.

Das Ergebnis der auf dem Gerät ausgeführten Anwendung ist optisch nicht von einer nativen Anwendung zu unterscheiden, da die Oberfläche den üblichen Konventionen entspricht und sich wie eine normale Anwendung verhält. Auch die Performancelast eines Interpreters ist geringer als die Simulation einer Oberfläche in einem WebView mit Interaktivität per JavaScript.

Der interpretierte Code hat vollen Zugriff auf alle vom Smartphone bereitgestellten technischen Funktionen. Was von nativen Anwendungen genutzt werden kann, steht auch dem Ansatz zur Verfügung. Wie nah interpretierte Anwendungen an native Anwendungen heran kommen, hängt hauptsächlich davon ab wie gut und vollständig die nativ verfügbaren Funktionen von den Funktionen des Ansatzes genutzt werden können.

Die plattformübergreifende Kompatibilität hängt davon ab, für welche Plattformen der Anbieter einen entsprechenden Interpreter und die passenden Zuordnungstabellen bereitstellen kann.

Eine Herausforderung für die Ansätze ist die Zuordnung und Nutzung verschiedener nur auf bestimmten Plattformen verfügbarer Elemente. So werden verschiedene Eingabeelemente je nach Plattform variiert oder die Nutzung einiger Elemente, für die sich keine Entsprechung finden lässt, auf eine Plattform beschränkt. Dies gilt natürlich ebenso für unterschiedlich verfügbare technische Funktionen.

Interpretierte Anwendung lassen sich während der Entwicklung nur schlecht testen. Theoretisch wäre es denkbar einen auf Desktop-Computern funktionierenden Interpreter anzubieten und die Ergebnisse unter verschiedenen Plattformen zu simulieren. Üblicher ist jedoch wie schon bei Hybrid-Anwendungen auf die für alle Plattformen verfügbaren Simulatoren zurückzugreifen oder die Anwendung direkt auf Smartphones aufzuspielen.

Abgrenzung zu cross-kompilierten Anwendungen

In der Berichterstattung (beispielsweise (Sugrue, 2010) oder (Dredge, 2010)) werden die zur Erstellung von interpretierten Anwendungen genutzten Frameworks oft als „Cross-Compiler“ kategorisiert. Auch die Marketingmaterialien einiger Anbieter und entsprechend viele Blog- oder Forenbeiträge im Internet verwenden diese Bezeichnung.

Da im Build-Prozess der Anwendung jedoch keine eigenständig ausführbare Anwendung erstellt wird, sondern erst ein Interpreter auf dem Zielgerät diese Umsetzung vornimmt, wird der Begriff Cross-Compiler hier falsch benutzt. Die Funktionsweise von echten Cross-Compilern wird in Abschnitt 4.4 beschrieben.

Einschätzung

Interpretierte Anwendungen kommen nativen Anwendungen sehr nahe. Sie sind schnell, stabil und bieten dem Nutzer ein gewohntes Nutzungserlebnis mit den von der Plattform bekannten Bedienelementen. Trotzdem ist eine einfache Programmierung und vor allem Plattformunabhängigkeit gegeben.

Die Umsetzung mit plattformeigenen Elementen bringt neue Probleme, die nicht einfach zu lösen sind. Zudem begibt der Entwickler sich mit der Nutzung eines Ansatzes zur Entwicklung interpretierter Anwendungen sehr in die Abhängigkeit zu einem Anbieter und seinem Ansatz. Die verschiedenen Ansätze sind nicht untereinander kompatibel. Es handelt sich daher um Insellösungen.

Ansätze dieser Klasse

  • Appcelerator Titanium Mobile
  • Rhomobile Rhodes

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert