ANE (Adobe Native Extensions). Erstellung nativer Erweiterungen für die Adobe Integrated Runtime

Inhaltsverzeichnis

Eidesstaatliche Erklärung

Abbildungsverzeichnis

Tabellenverzeichnis

Code-Beispiel-Verzeichnis

Danksagung

Abstract

Kurzfassung

Abkürzungsverzeichnis

Schlüsselwörter

1 Einleitung

2 Grundlagen
2.1 Rich Internet Applikation
2.2 Adobe Integrated Runtime
2.3 Vergleich zu Java Micro Edition
2.4 Adobe ActionScript
2.5 Apache Flex Software Development Kit
2.6 Adobe Native Extensions
2.7 NativeProcess-ActionScript Klasse
2.8 ActionScript Klassen Bibliothek (SWC-Datei)
2.9 Unterstützte Geräte
2.10 Beispiel-Erweiterungen
2.11 Zusammenfassung

3 Architektur von Native Extensions
3.1 Allgemeine Architektur
3.2 Native Architektur
3.3 Fazit

4 Entwicklungsschritte
4.1 Die Programmierung in ActionScript
4.2 Die Programmierung in C
4.3 Die Programmierung in Java
4.4 FREObekt-Typen
4.5 Descriptor-File
4.6 Verpacken der ANE
4.7 Vergleich zu Java Native Interface
4.7.1 Entwicklungsschritte für Java Native Interface
4.7.2 Vergleich von ANE und JNI

5 Praxis-Beispiele
5.1 ANE für Windows
5.1.1 Die C-Implementierung
5.1.2 Die ActionScript- Bibliothek
5.1.3 Das Descriptor-File
5.1.4 Erstellen der ANE
5.1.5 Verwenden der ANE
5.2 ANE für Android
5.2.1 Die ActionScript-Bibliothek
5.2.2 Descriptor-File
5.2.3 Default Implementierung
5.2.4 Die Android-Implementierung
5.2.5 Erstellen der ANE
5.3 Eigene Erfahrungen

6 Resümee

Literaturverzeichnis

Code-Anhang
TVChannelController.as:
Beispiel.cpp
Extension.java
ExtensionContext.java
UsefulFunction.java
JNIExample.java
JNIExample.h
JNIExample.cpp
feig.h
Feig.cpp
VolumeController.as
VolumeEvent.as
VolumeExtension.java
VolumeExtensionContext.java
InitFunction.java
SetVolumeFunction.java
SettingsContenObserver.java

Eidesstaatliche Erklärung

Ich erkläre hiermit an Eides statt, dass ich die vorliegende Arbeit selbstständig und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe. Die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht.

Die Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen Prüfungskommission vorgelegt und auch nicht veröffentlicht.

Graz, 08.04.2013

Martin Trinker

Abbildungsverzeichnis

Abbildung 1: Flash-Lite Architektur

Abbildung 2: Vergleichs-Spiel für JME(links) und Flash Lite (rechts)

Abbildung 3: ANE-Architektur

Abbildung 4: Ablauf der nativen Initialisierung

Abbildung 5: Aufruf einer nativen Funktion aus AS

Abbildung 6: native Event-Auslösung

Abbildung 7: Event-Benachrichtigung in AS

Abbildung 8: Beenden einer nativen Erweiterung

Abbildung 9: Konfiguration von javah.exe in Eclipse

Abbildung 10 empfohlene Ordner-Struktur

Tabellenverzeichnis

Tabelle 1: Schlüsselwörter XIII

Tabelle 2: unterstützte Plattformen für ANE

Tabelle 3: Beispiel-Erweiterungen

Tabelle 4: Ziel-Geräte und zu verwendende Native APIs

Tabelle 5: SWF-Version und AIR-Version

Code-Beispiel-Verzeichnis

Codebeispiel 1: Konstruktor mit ExtensionContext-Aufruf

Codebeispiel 2: Aufruf von nativen Funktionen

Codebeispiel 3: Konstruktor mit EventListener

Codebeispiel 4: Abfragen der verfügbaren Kanäle

Codebeispiel 5: verwenden der ANE-AS-Klasse

Codebeispiel 6: Implementierung der dispose()-Funktion

Codebeispiel 7: Zugriff auf Datei-System

Codebeispiel 8: native Initialisierung in C

Codebeispiel 9: nativer ContextInitializer in C

Codebeispiel 10: auslösen eines Events in C

Codebeispiel 11: Verwendung der Java-Klassen in AS

Codebeispiel 12: verwendung der ANE in AS

Codebeispiel 13: feststellen des Objekt-Typs in C

Codebeispiel 14: generischer Aufbau des Descriptor-Files

Codebeispiel 15: laden der nativen Bibliothek in Java

Codebeispiel 16: Aufruf einer nativ implementierten Methode

Codebeispiel 17: über javah.exe erstelltes Header-File

Codebeispiel 18: ausprogrammierte C++-Methode

Codebeispiel 19: Beispiel-Implementierung einer nativen Funktion

Codebeispiel 20: Descriptor-File für Windows ANE

Codebeispiel 21: importieren und erstellen des Objekts einer ANE

Codebeispiel 22: Definition der appClosing()-Methode

Codebeispiel 23: Implementierung der appClosing()-Methode

Codebeispiel 24: Konstruktor des VolumeControllers

Codebeispiel 25: setVolume()-Methode

Codebeispiel 26: Volume-ANE Descriptor-File

Danksagung

An dieser Stelle möchte ich mich bei jenen Menschen bedanken, welche mich bei der Erstellung dieser Arbeit unterstützt haben.

Allen voran möchte ich mich bei meinen Eltern bedanken. Nur mit ihrer Unterstützung war es mir möglich, mein Studium zu absolvieren und die damit verbundene Arbeit zu verfassen.

Bei meinem Betreuer, Herrn DI Dr. Nischelwitzer möchte ich mich für die gute Zusammenarbeit und zielführende Leitung durch dieses spezielle Themengebiet herzlich bedanken.

Ein spezieller Dank gilt auch meinen Studienkolleginnen und Kollegen, welche mich durch mein Studium begleitet haben und mir helfend zur Seite standen.

Abstract

Runtime environments provide the same set of functionality on different kinds of platforms. This allows the execution of a programme on different platforms without having to adopt or change the programme. Adobe provides the Adobe Integrated Runtime for Flash and ActionScript programmes.

To make use of platform specific functionality, the runtime environment needs to be extended. This native extension allows a programme to access and use specific hardware, for example.

This paper gives the reader a brief summary of the development process for native Extensions of the Adobe Integrated Runtime.

A short introduction provides the fundamentals of runtime environments and the architecture of Adobe’s runtime environment.

The main part describes the development steps necessary to create an Adobe Native Extension.

Following, examples from real life provide a detailed description of the development process for different platforms.

Concluding this paper, the concept of Adobe Native Extensions is compared to native extensions for alternative runtime environments and is critically analysed.

Kurzfassung

Laufzeitumgebungen stellen Programmen auf unterschiedlichen Plattformen eine einheitliche Funktionalität zur Verfügung. Dadurch kann das gleiche Programm auf unterschiedlichen Plattformen ausgeführt werden, ohne verändert werden zu müssen. Adobe stellt mit der Adobe Integrated Runtime eine Laufzeitumgebung für Flash und ActionScript-Programme zur Verfügung.

Um plattformspezifische Funktionalität, zum Beispiel spezielle Hardware, in der Laufzeitumgebung verwenden zu können, muss die Laufzeitumgebung erweitert werden.

In dieser Arbeit wird beschrieben, wie native Erweiterungen für die Adobe Integrated Runtime erstellt werden können.

In einem einführenden Kapitel werden dem Leser die Grundlagen über die Laufzeitumgebung von Adobe und deren Architektur vermittelt.

Im Hauptteil der Arbeit werden die Entwicklungsschritte für die Erstellung einer nativen Erweiterung detailliert beschrieben.

Anschließend wird anhand von Praxis-Beispielen die Erstellung einer nativen Erweiterung für unterschiedliche Plattformen dargestellt.

Abschließend wird das Konzept der Adobe Native Extensions mit nativen Erweiterungen bei alternativen Laufzeitumgebungen verglichen und kritisch analysiert.

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Schlüsselwörter

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Schlüsselwörter

1 Einleitung

Um ein beliebiges Programm auf mehreren Plattformen ausführen zu können, gibt es zwei Möglichkeiten. Einerseits kann das Programm für jede Plattform extra programmiert und kompiliert werden. Dies ist allerdings sehr umständlich, da unter Umständen das Programm komplett neu erstellt werden muss. Eine andere Alternative ist die Verwendung einer Laufzeitumgebung.

(vgl. [AIR-Laufzeitumgebung 2013] Seite 6)

Eine Laufzeitumgebung stellt dieselbe Funktionalität auf unterschiedlichen Plattformen zur Verfügung. Entwickler können dadurch ihre Programme auf den unterschiedlichen Plattformen ausführen, ohne das Programm für jede Plattform anpassen zu müssen.

(vgl. [AIR-Laufzeitumgebung 2013] Seite 7)

Eine Laufzeitumgebung stellt allerdings nur einen bestimmten, teilweise eingeschränkten Satz an Funktionen zur Verfügung, welche auf allen Plattformen einheitlich zur Verfügung stehen. Adobe stellt für Flash und ActionScript-Programme die Laufzeitumgebung Adobe Integrated Runtime (AIR) zur Verfügung.

Spezielle Funktionen, wie zum Beispiel die Verwendung einer bestimmten Hardware, werden in der Regel nicht von der Lauzeitumgebung unterstützt.

(vgl. [AIR Native Extension 2013] Seite 5)

Um dennoch plattformspezifische Funktionen in der Laufzeitumgebung verwenden zu können, kann die Laufzeitumgebung mit nativem Code erweitert werden. Dadurch steht zum Beispiel die spezielle Hardware für Programme, welche die Laufzeitumgebung verwenden, zur Verfügung.

Die Adobe Integrated Runtime kann mit Adobe Native Extensions erweitert werden.

(vgl. [AIR Native Extension 2013] Seite 6)

In dieser Arbeit soll dem Leser das Thema Adobe Native Extension näher vorgestellt werden. Dabei wird besonders darauf Wert gelegt, dem Leser die notwendigen Hintergrundinformationen, welche für ein besseres Verständnis der Thematik unerlässlich sind, zu vermitteln.

2 Grundlagen

In diesem Kapitel werden die grundlegenden Informationen und die wichtigsten Begriffe näher erklärt.

2.1 Rich Internet Applikation

In den letzten Jahren werden vermehrt Programme im Web-Browser ausgeführt statt am Desktop. Eine Ursache für die stärkere Verschiebung von Programmen in den Browser ist die weite Verbreitung des Internets als Kommunikations-Medium. Des Weiteren ist es vergleichsweise einfach, Web-Anwendungen zu erstellen. Es erlaubt außerdem, die Anwendungen unabhängig vom Betriebssystem auszuführen.

(vgl. [Chambers 2008] Seite 2)

Frühere Web-Anwendungen wurden meist ausschließlich in HMTL erstellt. Dies führte zu einer hohen Anzahl von Client-Server-Anfragen und häufigen Seiten-Aktualisierungen. Durch die Verwendung der Flashplayer-Laufzeitumgebung wurde es für Entwickler möglich, Desktop-Ähnliche Anwendungen im Browser ausführen zu können.

(vgl. [Chambers 2008] Seite 3)

Rich Internet- Applikationen können anhand folgender Kriterien definiert werden:

- Sie bieten einen leistungsstarke Laufzeitumgebung zur Ausführung des Codes
- Web- und Daten-Dienste werden durch Anwendungs-Server bereitgestellt
- Einfache Ausführung auf unterschiedlichen Betriebssystemen

(vgl. [Allaire 2002] Seite 2)

Als die Web-Anwendungen jedoch zu komplex wurden, wurden schnell die Grenzen der Browser und der Verwendbarkeit der Anwendungen erreicht. Web-Browser wurden ursprünglich dazu entwickelt, um HTML-Seiten anzuzeigen.

(vgl. [Chambers 2008] Seite 4)

Web-Anwendungen haben oft ihre eigenen Steuerelemente, welche mit den Bedien-Elementen des Browsers widersprechen. Als Beispiel kann hier der „Zurück“-Button im Browser angeführt werden. Dieser macht Sinn, um auf die vorherige Seite zurückzuspringen. In einer Anwendung hingegen kann dies oft zu Konflikten führen.

(vgl. [Chambers 2008] Seite 5)

Des Weiteren haben Browser-Anwendungen aus Sicherheitsgründen keinen Zugriff auf den Computer des Benutzers. Dadurch können oft verschiedene Bedien-Elemente, zum Beispiel „Drag and Drop“ von Lokalen Dateien in eine Browser-Anwendung, nicht genutzt werden. Browser-Anwendungen können auch nicht mit lokalen Anwendungen zusammen arbeiten.

(vgl. [Chambers 2008] Seite 5)

Eine weitere Einschränkung von webbasierten Anwendungen ist die Grundvoraussetzung von Internet. Ist keine Internet-Verbindung verfügbar, kann auch die Anwendung nicht geladen werden.

(vgl. [Chambers 2008] Seite 6)

2.2 Adobe Integrated Runtime

Mithilfe der Adobe Integrated Runtime wird nun versucht, die Vorteile von Browser-Anwendungen mit den Vorteilen von Desktop-Anwendungen zu verbinden.

(vgl. [Chambers 2008] Seite 6)

Adobe Integrated Runtime (AIR) ist eine Betriebssystem-Übergreifende Laufzeit-Umgebung, welche es ermöglicht, reichhaltige Internet-Anwendungen (Rich Internet Applications) auf unterschiedlichen Systemen ausführen zu können.

(vgl. [Chambers 2008] Seite 19)

Um Anwendungen auszuführen, verwendet AIR intern den Adobe Flash-Player als Laufzeitumgebung.

(vgl. [Adobe Systems 2007])

In der nachfolgenden Grafik ist die Architektur des Flash-Players in der Lite-Version dargestellt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Flash-Lite Architektur

(vgl. [Adobe Systems 2007])

Die Laufzeitumgebung besteht aus mehreren Schlüsselkomponenten, welche es den Anwendungen erlauben, mit dem Host-System zu interagieren. Das Kern-Element ist die „Core Rendering Engine“ welche Bilder am Bildschirm ausgibt.

Ein weiteres Kern-Element ist die ActionScript-Komponente, welche Prozess-Events abarbeitet. Dazu zählt zum Beispiel das Drücken von Tasten.

Weitere spezielle Pakete der Flash Laufzeitumgebung ermöglichen zum Beispiel den Zugriff zum Netzwerk.

(vgl. [Adobe Systems 2007])

2.3 Vergleich zu Java Micro Edition

Nachdem nun die Laufzeitumgebung von Adobe näher vorgestellt wurde, soll an dieser Stelle ein Vergleich zu einer anderen Laufzeitumgebung durchgeführt werden. Im folgenden Kapitel werden die Laufzeitumgebungen für mobile Geräte, nämlich Adobe Flash Lite und Java-Micro-Edition miteinander verglichen.

Beide Laufzeitumgebungen werden dazu verwendet, um Applikationen für mobile Geräte betriebssystem-unabhängig erstellen und ausführen zu können.

(vgl. [Koller 2008] Seite 1)

Die Java Micro Edition (JME) wurde für Geräte mit wenig Ressourcen und geringer Rechenleistung entwickelt. Durch zusätzliche Pakete, zum Beispiel der Bluetooth-API kann die Funktionalität auf Kosten der Geräteunabhängigkeit erhöht werden. Mobile Java-Applikationen, sogenannte MIDlets, können einfach verteilt und ausgeführt werden.

(vgl. [Koller 2008] Seite 2)

Adobe Flash Lite ist eine abgespeckte Version des Flash Player, speziell für mobile Geräte.

(vgl. [Koller 2008] Seite 2)

Die Unterschiede der beiden Umgebungen werden anhand eines praktischen Beispiels erläutert. In diesem Beispiel soll ein Spiel mit demselben Funktionsumfang sowohl für Java als auch für Adobe Flash erstellt werden.

(vgl. [Koller 2008] Seite 3)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Vergleichs-Spiel für JME(links) und Flash Lite (rechts)

(vgl. [Koller 2008] Seite 4)

Schon bei der Entwicklung für die jeweiligen Umgebungen fallen die ersten Unterschiede auf. Die stark Objekt-Orientierte Programmierung in Java steht im Kontrast zur Zeitleisten-Orientierten, Sequenziellen Programmierung in Flash und ActionScript.

(vgl. [Koller 2008] Seite 4)

Für die Erstellung der Menüs bietet Flash mit der Zeitleiste ein wesentlich komfortableres Werkzeug. Es können in beiden Umgebungen gleichwertige Menüs erstellt werden, jedoch ist dies in Java mit einem höheren Aufwand verbunden.

(vgl. [Koller 2008] Seite 4)

Mit beiden Umgebungen ist es einfach, Grafiken und Audio-Dateien zu verwenden. Allerdings wird bei JME eine breitere Palette von Formaten unterstütz.

(vgl. [Koller 2008] Seite 4)

Der Zugriff auf das Dateisystem und das Speichern von Highscore-Werten in einer Datei ist in beiden Umgebungen einfach zu implementieren.

(vgl. [Koller 2008] Seite 5)

Bei der Erstellung der Game-Engine, also der zentralen Spiele-Steuerung kann bei Java ein Paket verwendet werden, welche die Funktionalität bereits erfüllt. In Flash muss hingegen die Funktionalität von Grund auf erstellt und implementiert werden, was einen erheblichen Zeitaufwand bedeutet.

(vgl. [Koller 2008] Seite 6)

Bei der Kollisions-Erkennung kann bei beiden Umgebungen auf bestehende Methoden zurückgegriffen werden. In Flash werden zur Kollision-Erkennung jedoch nur die Rechtecke der Grafiken unterstützt. In der JME werden dabei transparente Pixel unterstützt. Diese genauere Form der Kollisions-Erkennung der JME verbessert den Spiel-Eindruck wesentlich.

(vgl. [Koller 2008] Seite 6)

Für beide Umgebungen sind umfassende Dokumentationen erhältlich, welche die Entwicklung wesentlich erleichtern.

(vgl. [Koller 2008] Seite 6)

Bei der Entwicklung in Java sind für das Spiel gesamt ungefähr 3000 Code-Zeilen erforderlich. Zum Vergleich: in Flash sind lediglich 1000 Code-Zeilen erforderlich, um das Spiel umzusetzen. Ein wesentlicher Vorteil in Flash sind hier die grafischen Editoren, welche das Erstellen von Menüs und dergleichen wesentlich erleichtern.

(vgl. [Koller 2008] Seite 6)

Hinsichtlich der Datei-Größe der fertigen und ausführbaren Pakete ist nur ein geringer unterschied erkennbar. Die Dateigröße der JME-Applikation beläuft sich auf 81,5 KB. Die fertige Applikation für Flash ist 71,8 KB groß.

(vgl. [Koller 2008] Seite 6)

Ein wesentlicher Unterschied ist in der Ressourcen-Belegung während der Ausführung feststellbar. Hier kann festgestellt werden, dass das Spiel in der JME im Durchschnitt nur ein Fünftel der Ressourcen verbraucht, wie in der Flash Laufzeitumgebung.

(vgl. [Koller 2008] Seite 6)

Auch die Frame-Rate, also die Anzahl der Bild-Aktualisierungen pro Sekunde ist in der JME um drei Frames pro Sekunde höher als in Flash. In der Ausführung des Spiels macht dies jedoch einen merkbaren unterschied.

(vgl. [Koller 2008] Seite 6)

Zusammengefasst kann festgehalten werden, dass das Spiel für beide Umgebungen entwickelbar ist. Allerdings ist Java aufgrund der umfangreicheren Erweiterungen und ressourcenschonenderen Ausführung zu bevorzugen.

(vgl. [Koller 2008] Seite 7)

2.4 Adobe ActionScript

ActionScript 3.0 ist eine Objekt-Orientierte Programmiersprache. In ActionScript verfasste Programme benötigen die AIR-Laufzeitumgebung, um ausgeführt werden zu können.

(vgl. [ActionScript 3 2011] Seite 4)

ActionScript bietet viele eingebaute Klassen, welche dem Entwickler standardmäßig zur Verfügung stehen. Als Beispiel hierzu sei die Klasse NetConnection genannt. Mit dieser Klasse lässt sich beispielsweise sehr einfach eine Netzwerk-Verbindung aufbauen.

(vgl. [ActionScript 3 2011] Seite 5)

ActionScript stellt nur Klassen mit genereller Funktionalität bereit. Um beispielsweise Plattform-Spezifische Funktionen nutzen zu können, werden native Codeerweiterungen (ANE) verwendet.

(vgl. [AIR Native Extension 2013] Seite 5)

2.5 Apache Flex Software Development Kit

Apache Flex ist ein Software Development Kit (SDK), mit welchem plattformübergreifende Rich Internet Applikations erstellt werden können. Aus ActionScript-Code und dem in MXML verfassten Layout Code wird eine Flex-Applikation erstellt. Diese Anwendung läuft dann in der Adobe Flash Laufzeitumgebung.

(vgl. [Apache Flex 2013])

Flex wurde von Adobe Systems an die „Apache Software Foundation“ gespendet. Diese Organisation betreut nun das Flex-Projekt weiter.

(vgl. [Apache Flex 2013])

Für Entwickler wird das Flex SDK als Erweiterung für bekannte Entwicklungsumgebungen angeboten.

(vgl. [Apache Flex 2013])

2.6 Adobe Native Extensions

Native Erweiterungen für Adobe AIR sind Code-Bibliotheken, welchen nativen Code enthalten. Dieser native Code ist mit einer in ActionScript verfassten API umhüllt und so in einer AIR-Applikation zugänglich.

(vgl. [AIR Native Extension 2013] Seite 5)

Native Extensions werden aus folgenden Gründen verwendet:

- Um Besonderheiten der Plattform ansprechen und verwenden zu können, welche standardmäßig in AIR nicht enthalten sind. ActionScript bietet Klassen mit genereller Funktionalität. Geräte-Spezifische Besonderheiten sind nicht in der Standard-Bibliothek von ActionScript enthalten. Diese geräte-spezifischen Besonderheiten, zum Beispiel Hardware, kann auch nicht direkt aus der AIR-Laufzeitumgebung angesprochen und verwendet werden. Durch eine Implementierung von nativem Code können diese Besonderheiten aber genutzt werden. Nativer Code hat nämlich Zugang zu geräte-spezifischer Hard- und Software.

(vgl. [AIR Native Extension 2013] Seite 5)

- Um bei kritischen Algorithmen eine höhere Performance erreichen zu können.
(vgl. [AIR Native Extension 2013] Seite 6)
- Um bestehende native Code-Bibliotheken wiederverwenden zu können.

(vgl. [AIR Native Extension 2013] Seite 6)

Eine Native Extension ist eine Kombination aus einer ActionScript-Klasse und nativem Code.

2.7 NativeProcess-ActionScript Klasse

ActionScript bietet eine NativeProcess-Klasse. Die Klasse erlaubt der AIR-Laufzeitumgebung nativen Code am Betriebssystem auszuführen. Diese Funktionalität ist ähnlich zu Native Extensions, da NativeProcess-Klassen ebenfalls den Zugriff auf Geräte-Spezifische Eigenschaften bieten.

(vgl. [Native Process 2013])

Um nun zwischen NativeProcess-Klassen und Native Extensions unterscheiden zu können, sollten folgende Punkte berücksichtigt werden:

- Nur das extendedDesktop AIR-Profile unterstützen NativeProcess-Klassen. Für Anwendungen, welche extendedTV, mobileDevice, oder extendedMobileDevice AIR-Profile verwenden, sind NativeExtensions die einzige Möglichkeit.

(vgl. [AIR Native Extension 2013] Seite 6)

- Mit einer Native Extension werden meist Implementierungen für mehrere Plattformen mitgeliefert. Der Zugriff erfolgt über eine einheitliche Schnittstelle. Wird jedoch die NativeProcess-Klasse verwendet, kann der Zugriff auf die bereitgestellte Funktionalität unter den verschiedenen Plattformen variieren.

(vgl. [AIR Native Extension 2013] Seite 6)

Eine NativeProcess-Klasse startet bei der Ausführung einen eigenen Prozess. Hingegen läuft eine Native Extension im selben Prozess wie die AIR-Laufzeitumgebung. Daher muss bei Verwendung der NativeProcess-Klasse womöglich das Handling der Kommunikation zwischen den beiden Prozessen implementiert werden.

(vgl. [AIR Native Extension 2013] Seite 6)

2.8 ActionScript Klassen Bibliothek (SWC-Datei)

In einer SWC-Datei ist kein nativer Code enthalten. Daher sollten bei selbst erstellten Erweiterungen, in denen kein nativer Code benötigt wird, SWC-Dateien anstatt von Native Extensions verwendet werden.

(vgl. [Adobe SWC-File 2012])

2.9 Unterstützte Geräte

In der folgenden Tabelle sind Geräte /Plattformen gelistet, welche Native Extensions unterstützen:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: unterstützte Plattformen für ANE

(vgl. [AIR Native Extension 2013] Seite 6)

2.10 Beispiel-Erweiterungen

Um dem Leser eine bessere Vorstellung von nativen Erweiterungen zu geben, werden in diesem Kapitel einige Beispiele für Adobe Native Extensions näher beschrieben.

Auf der Webseite von Adobe^[1] werden ANE-Dateien Frei oder Kommerziell vertrieben. Auf dieser Seite werden detaillierte Informationen zur Verwendung der ANE-Dateien zur Verfügung gestellt.

Außerdem gibt es eine Vielzahl von Webseiten und Foren, zum Beispiel extensionforair.com^[2] oder milkmangames.com^[3], wo native Erweiterungen für die Adobe AIR angeboten werden.

Abbildung in dieser Leseprobe nicht enthalten

[...]

---

^[1] http://www.adobe.com/devnet/air/native-extensions-for-air.html

^[2] http://extensionsforair.com/

^[3] http://www.milkmangames.com/blog/tools/#iosgv

^[4] http://www.adobe.com/devnet/air/native-extensions-for-air/extensions/vibration.html

^[5] http://extensionsforair.com/extensions/contact-editor/

^[6] http://www.adobe.com/devnet/air/articles/ratebox-ane-ios-android.html