Erstellung von iPhone-Apps mit Flash CS5, FDT und dem neuen Adobe AIR 2.6

[Flash Doc]

Hallo an alle im Rund,

das neue Adobe AIR 2.6 ist raus. Die Runtime hatte ich schon dieser Tage aktualisiert, aber im SDK steckt ja noch viel mehr, was sich auch für die Entwicklung von Apps für iPhone & Co nutzen ließe. Aber das geht nicht mehr mit dem in Flash CS5 eingebauten iPhone-Packager. Deshalb möchte ich hier mal zusammenfassen, wie man sich sein Entwicklungsumfeld so herrichten kann, dass man mit den vorhandenen Mitteln Apps für die Apple-Geräte auf der Basis von Adobe AIR 2.6 erstellen kann. Infos zu den einzelnen Vorgehensweisen gibt es schon an verschiedenen Stellen. Ich ziehe das alles mal hier zusammen.

1. Voraussetzungen
Ich setze mal voraus, dass ihr euch schon mit einem Apple-Account versorgt habt und mit den Vorgehensweisen für die Erstellung von Zertifikaten und Provisioning-Profiles vertraut seid. Näheres hierzu könnt ihr auch diesem Thread [Tutorial] Flash iPhone Entwicklung mit FlashDevelop und Adobe “Packager for iPhone” entnehmen. Ferner hat hierzu auch schon Saban Ünlü (Stichwort: netTrek) hier beschrieben.

2. Vorbereiten der Entwicklungsumgebung
Zunächst lädt man sich, falls nicht schon geschehen, das AIR 2.6 SDK bei Adobe herunter und packt das Archiv in einen Ordner aus. Für alle Vista-Nutzer empfehle ich, den Zielordner direkt in C:\ anzulegen. So spart man sich Ärgernisse mit der Benutzerkontrolle. Diese separate Ablage ermöglicht es aber, das AIR-SDK später auch noch mit anderen Flex-SDKs zu mixen. Beschrieben ist das z.B. hier: How to Overlay the AIR SDK for Use With the Flex SDK

Jetzt muss man an die Flash CS5-IDE ran. Wie vorzugehen ist, ist auch hier Adobe Forums: Using Air 2.6 with Flash CS5 beschrieben. Die wichtigsten Eckpunkte hier aber noch mal in Kürze:

1. Zunächst ein mal die Inhalte der Ordner "\Program Files\Adobe\Adobe Flash CS5\Common\Configuration\ActionScript 3.0\AIR2.0" und "\Program Files\Adobe\Adobe Flash CS5\AIK2.0" sichern. Am besten man kopiert die betreffenden Ordner und hängt ein ".old" an die Ordnernamen an.
2. Nun kopiert man die airglobal.swc aus dem Ordner "\frameworks\libs\air" des vorher angelegten AIR-SDKs in den Ordner "Program Files\Adobe\Adobe Flash CS5\Common\Configuration\ActionScript 3.0\AIR2.0".
3. Als letztes korpiert man den kompletten Inhalt des Ordners des vorher angelegten SDK-Ordners in den Ordner "\Program Files\Adobe\Adobe Flash CS5\AIK2.0". Auf diese Weise werden alle zu ersetzenden Files durch die neuen 2.6er ersetzt.

Hinweis für Windows Vista und Windows 7: Da in Ordner unterhalb von \Programm Files eingegriffen wird, sind für diese Aktionen Admin-Rechte erforderlich. Außerdem meldet sich natürlich die Benutzerkontrolle mit entsprechenden Meldungen, die quittiert werden wollen.

3. Eine iPhone-App in Flash CS5 aufsetzen
In Flash CS5 steht der iPhone-Packager zur Verfügung. Dazu gehört auch die iPhone OS-Vorlage, die wir nach wie vor nutzen können und sollen, auch wenn der Packager selbst mit AIR 2.6 nichts mehr anfangen kann. Im Zusammenspiel mit FDT ist es aber trotzdem möglich IPAs für das iPhone zu erstellen. Hierfür macht man sich zu nutze, dass im 2.6er SDK der Packager for iPhone (PFI) Teil der ADT.jar ist. Dieses ADT kann man genauso wie den PFI über eine Kommandozeile aufrufen. In Packaging AIR application for iOS devices with ADT command and ANT script findet ihr schon mal ein Beispiel für ein ANT-Build-Script, das ich für FDT angepasst habe. Dieses angepasste Build-Script lege ich als ZIP mit bei.

Zunächst beginnt man in der Flash-IDE ganz normal mit einer neuen FLA-Datei und verwendet dabei die Vorlage iPhoneOS. Man sollte dann zunächst die FLA-Datei speichern, damit sie einen korrekten Dateinamen hat. Jetzt, falls erforderlich, das Zielverzeichnis für die SWF-Datei in den Einstellungen zur Veröffentlichung anpassen. Dort auch die Erstellung der HTML-Datei abschalten, die brauchen wir nicht.

Ich empfehle allerdings, das von FDT vorgeschlagene Dateisystem zu nutzen und für die SWF-Datei den Ordner /bin im Projekt bei den Veröffentlichungseinstellungen einzustellen. Unterhalb dieses Ordners sollten dann in einem z.B. /icons benannten Ordner die verschieben Icons für das Package abgelegt sein.

Anschließend gehen wir zu den Einstellungen für das iPhone OS. Hier legen wir die Versionsnummer und die App-ID fest und stellen die übrigen Parameter der App ein. Außerdem tragen wir hier das Zertifikat, das Passwort zum Zertifikat und das Provisioning-Profil ein. Als letztes weisen wir die Icons der App zu. Automatisch wird die für AIR nötige app.xml erzeugt, die wir uns als nächstes vornehmen.

Wir finden dort den Knoten <version>1.0</version>, den wir in <versionNumber>1.0</versionNumber> abändern. Mehr müssen wir in dieser Datei nicht tun.

Nun benennen wir die beiliegende build_ex.xml in build.xml um, speichern sie ins Root unseres Projekts und ersetzen die notwendigen Parameter in der ANT-Build-Datei. Ich habe in meinem Beispiel die wichtigen Sachen in Großbuchstaben eingetragen. Die build.xml müssen wir anschließend noch als ANT-Script im FDT bekannt machen.

Dann machen wir uns an die Entwicklungsarbeit. Zum allerersten Test reicht eine kleine Hello-World-App aus.

4. Die App kompilieren, die IPA erzeugen und testen
Wenn wir die erste Test-App mit ein paar funktionalen Inhalten versehen haben, starten wir den Build-Vorgang aus dem FDT heraus. Unsere build.xml enthält 3 Tasks mit denen wir den Buildvorgang anstoßen können. Sie starten dann jeweils den Compile-Vorgang, der in der Flash-IDE abläuft. Hier sind zwei ganz wichtige Dinge zu beachten:

• Wird in Flash die Veröffentlichung gestartet, springt natürlich auch nach Erstellung der SWF-Datei der iPhone-Packager an und steigt sofort mit einer Fehlermeldung wieder aus. Die Fehlermeldung quittieren wir. Da bei der "compile"-Task der Fehlerabbruch unterbunden (Attribut failonerror="false") wurde, läuft der Build-Prozess im ANT weiter und erzeugt die IPA-Datei.
• In der Flash-IDE müssen wir nach wie vor so tun, als würden wir noch den iPhone-Packager benutzen können. Das bedeutet, dass wir in den Einstellungen zum iPhone OS die Schalter für den Bereitstellungstyp jeweils für die entsprechenden Aufgaben setzen müssen. Diese Schalter haben Auswirkungen auf die SWF-Datei, die ja z.B. für das Debugging vom Gerät dieses auch zulassen muss. Entsprechend gilt das auch für die anderen Bereitstellungstypen. Wenn also insbesondere das Geräte-Debugging nicht funktionieren will (Kein Kontakt zur Flash-IDE), dann könnte hier die Einstellung nicht korrekt sein.

Und nun läuft eigentlich alles wie gehabt weiter. Das Gerät wird mit iTunes verbunden, die IPA ins iTunes gezogen und synchronisiert. Dann kann man die App auf dem gerät starten.

Und nun am Schluss des Ganzen der Wermutstropfen: Bei meinen Tests musste ich feststellen, dass mein iPhone 3G die IPA nicht mehr annehmen konnte. Ich vermute mal, dass nur noch Geräte mit iOS 4.3 oder höher unterstützt werden. Das iPhone 3G wurde aber mit diesem Systemupdate nicht mehr versorgt. Leider steht mir kein iPhone 3GS zur Verfügung, ich weiß aber, dass das 3GS das iOS 4.3 auch noch bekommen kann. Wer diesen ganzen Workflow mit dem neuen AIR 2.6 mal probiert und auf iPhone 3GS erfolgreich getestet hat, kann sich ja hier mal melden.

Ansonsten hoffe ich, dass ich allen hier mit diesem Post eine brauchbare Hilfestellung geben konnte. Wenn es hierzu noch Fragen gibt, dann postet sie bitte in diesem Thread.

Gruß vom Flash Doc

[Mr.Twister]

Hi Flash Doc,

vielen Dank für diese ausführliche Anleitung!
Damit hast du das geliefert, wonach im Moment viele Leute suchen.

Ich habe persönlich kein FDT (arbeite lediglich mit dem Flash Builder ohne Plugin) und muss zu meiner Schande gestehen, dass ich mit ANT noch nicht viel anfangen kann. Dennoch motiviert mich dein Tutorial, noch einmal den ganzen Weg zu versuchen. Ich werde es evtl. morgen ausprobieren können.

Nichtsdestotrotz traue ich mich nicht, mit so einer "Bastellösung" einem Kunden zu erzählen, dass ich marktreife iOS Apps entwickeln kann. Bevor es soweit ist, werde ich noch auf ein Update der Flash IDE warten oder so.

[Nico B.]

Selbst dann würde ich, dank mangelnder Performence bzw. Feature-Lücken, einem Kunden sowas nicht andrehen. Für den Preis bekommt er sicherlich auch ne "richtige" App. :P

[Mr.Twister]

Andrehen? :-)
Naja, das sehe ich anders.
Feature-Lücken ... kommt auf die Features an. Und wenn ein gewisser Anwendungsfall gewisse Features nicht benötigt, ist es keine Lücke.

Mangelnde Performance ... auch hier kommt es auf die Anwendung an. Und genau deshalb wollte ich ja mal unbedingt die Performance von AIR 2.6 testen.

Eine native iOS App zu entwickeln ist halt auch nicht ohne.
Und wenn man nicht gerade auf die Standard-Boardmittel des iOS SDKs setzen möchte, kann die Entwicklung auch schnell recht komplex werden.

[Omega Psi]

Performance und ein gutes Laufzeitverhalten sind auch Features, so wie ich das sehe...

[Mr.Twister]

Wäre das hier dann auch "andrehen"?

[Flash Doc]

Hallo,

@Mr. Twister: Vielen Dank für dein Lob. Genaus das wollte ich erreichen. Adobe AIR war noch nicht allzu lange draußen, aber es gab schon etliche Quellen. Ich wollte in meinem Post diese Quellen und deren Aussagen in einer Stelle zusammenführen und sie durch meine "Forschungsergebnisse" ergänzen. Schön, wenn ich damit den Nerv getroffen habe.

Was ich gemacht habe, sieht zwar aus wie eine "Bastellösung", aber es war leider notwendig und ist so auch legitim. Ich habe mein Flash CS5 einfach renoviert und das vorweg genommen was in einer möglichen CS5.5 drin sein dürfte. Gerüchte darüber sind im Umlauf, aber Adobe hält sich noch bedeckt und im WWW ist leider auch noch nicht viel dazu zu finden. Mal sehen, ob ich bei der FFK den Adobe-Leuten dort etwas entlocken kann.

Du musst aber keine Skrupel haben, wenn du auf dieser Basis für deine Kunden entwickeln willst. Ich zitiere mal einen ehemaligen Bundeskanzler sinngemäß: "Entscheidend ist, was hinten rauskommt." Den Kunden interessiert nur, was du ihm lieferst und nicht, wie es entstanden ist.

Ich nutze Flash CS5 im Gespann mit FDT oder besser umgekehrt. FDT hat sich hier wieder einmal als echte Geheimwaffe erwiesen. Es bringt alles mit, was du für die AS-Entwicklung mit Flash brauchst und ist ein echtes Entwickler-Sofa. Lade dir hier Powerflasher Solutions -FDT - Development Tools for Flash, Flex, Actionscript, MXML, Haxe, AS2, AS3, IDE, Editor, Refactoring, Adobe mal eine Testversion und probier es einfach mal aus. Wenn du wirklich dann noch den FlashBuilder nutzen willst empfehle ich dir, hier Adobe Flash Builder "Burrito" | cross platform development - Adobe Labs das Burrito-Preview runter zu laden. Damit kannst du auch für Android-Plattformen entwickeln. Du bekommst eine 60-Tage-Lizenz, die du aber in eine Dauer-Lizenz wandeln kannst, wenn du eine gültige Lizenz auf den FlashBuilder 4 oder eine CS5-Version hast.

@Omega Psi: Ich entwickle auch nativ für iPhone & Co. Habe mir eigens dafür vor gut 2 Jahren einen Apfelrechner kaufen müssen. Mit Objective-C entstehen zwar schlankere und damit auch performantere Apps. ABER auch diese IDE wird ja durch Apple ständig erweitert und ergänzt. Damit erweitern sich auch die Möglichkeiten für den Entwickler. Aber die entstehenden Apps werden damit auch hungriger nach Ressourcen. Gerade bei 3D-Spielen merkt man auf älteren Geräten (iPhone 3G und älter) sehr schnell die Grenzen.

Der iPhone-Packager für Flash muss nun quasi mit der SWF eine für das iPhone geeignete Projektor-Anwendung erzeugen. Wie das für eine Flash-Projektor-Anwendung typisch ist, schleppt die App dann natürlich auch alles mit, was für als Runtime-Umgebung gebraucht wird. Das bremst natürlich, weil der Bytecode der SWF entsprechend zur Laufzeit umgesetzt werden muss. Auf Android-Geräten steht die AIR-Runtime zur Verfügung. Hier stelle ich dann nur noch die eigentliche Flash-Anwendung bereit. Das ist dann natürlich noch mal um einiges fluffiger als auf dem iPhone.

Ansonsten rufe ich alle hier im Forum auf, in diesem Thread eigene Erfahrungen und Techniken zu dieser Thematik zu posten. Ich habe nur die Kombination Flash CS5/FDT berücksichtigt. Wer aber Erfahrungen im Zusammenhang mit dem FlashBuilder 4 oder gar mit Burrito beisteuern kann, ist herzlichst eingeladen dies zu tun. Auf diese Weise können wir hier einen zentralen Thread aufbauen, der allen hilft.

Gruß vom Flash Doc

[Omega Psi]

Zitat von Flash Doc

@Omega Psi: Ich entwickle auch nativ für iPhone & Co. Habe mir eigens dafür vor gut 2 Jahren einen Apfelrechner kaufen müssen. Mit Objective-C entstehen zwar schlankere und damit auch performantere Apps. ABER auch diese IDE wird ja durch Apple ständig erweitert und ergänzt. Damit erweitern sich auch die Möglichkeiten für den Entwickler. Aber die entstehenden Apps werden damit auch hungriger nach Ressourcen. Gerade bei 3D-Spielen merkt man auf älteren Geräten (iPhone 3G und älter) sehr schnell die Grenzen.

Das sind aber 2 paar Schuhe, du vermengst gar mehrere Aspekte.

Ich sehe es halt kritisch, wenn man nicht nativ arbeitet, sondern auf Transformationen AS3 -> Objective-C setzt. Auch wenn die Paradigmen der Sprachen ähnlich sind, so muss man dann doch sehen, dass gewisse Implementierungen nicht 1:1 übertragbar sind.

Wenn nun Entwickler ausschliesslich OpenGLES2 nutzen wollen als Beispiel, schliessen sie eine gewisse Gruppe von Nutzern aus.

Ich spreche mich ja auch nicht komplett gegen solche Tools aus, doch muss man manchmal einfach mal untersuchen, ob die Anwendung die man baut auch tatsächlich noch wie erwartet läuft, wenn sie auf iOS Devices deployed wird. Ich glaube einfach, das Laufzeitverhalten ist schwer einzuschätzen.

[Mr.Twister]

Genau dafür gilt es das System natürlich vorher zu testen. Vor allem auf die Performance. Und da das im Moment nur sehr umständlich möglich ist, lasse ich da auch noch die Finger von.

Wenn sich aber in ein paar Monaten herausstellt, dass die Performance auf einem iPad2 zufriedenstellend ist, sehe ich es als sehr gute Möglichkeit, viele Anwendungen (die von der Komplexität das System nicht überfordern) mit Flash zu entwickeln.
Native Anwndungen werden sicherlich trotzdem sauberer laufen, aber durch die Entwicklung mit Flash hat man einen Mehrwert, dem man dem Kunden auch erklären kann.
Z.B. dass man die selbe Anwndung auch im Internet verwenden kann.

[Omega Psi]

Haha, ja. Das ist dann wiederum ein guter Punkt.

[Nico B.]

Z.B. dass man die selbe Anwndung auch im Internet verwenden kann.

... oder auf Android-Geräten, oder auf Blackberry, oder auf Samsung Tv's, oder als Desktop-App ....

[Flash Doc]

Hallo,

@Omega Psi: Scheinbar ist es so, dass ich da 2 Paar Schuhe mit einander vermenge. Aber ich bin mir sehr wohl der Paradigmen in den beiden Welten (Native Welt mit Objective-C und Flash-Welt) bewusst. Daher bin ich sehr vorsichtig damit, Dinge, die ich mit AS3 geBaut habe, wie du sagst 1:1 in die native Welt zu übernehmen. ABER das ist auch nicht mein Ziel. Ich gehe immer von der zu lösenden Aufgabe aus. Da ich in beiden Welten hinlängliche Erfahrungen gesammelt habe, kann ich einschätzen, welche Mittel und Werkzeuge zum Einsatz kommen, sofern mir der Kunde in diesem Punkt die erforderliche Freiheit lässt. Das ist nicht immer möglich. Meist gibt der Kunde vor, dass die App mit nativen Mitteln entwickelt werden muss. Da kann ich dann zwar beratend auftreten, aber ich werden den Teufel tun und dem Kunden etwas aufzwingen. Der Kunde ist nun mal König.

Für mich heißt das, dass ich meine Erfahrungen in beiden Welten auf einem höheren Level bündeln muss, um bestimmte Dinge dann sowohl mit dem einen als auch mit dem anderen Mittel umzusetzen. Beispiel: Im Flash gibt es das DisplayObject als Superklasse für alle Klassen, deren Instanzen auf der Bühne platziert werden. Im Cocoa Touch Framework (Objective-C) gibt es die Klasse UIView, von der alle GUI-Elemente abgeleitet sind. Instanzen dieser Klasse und von Klassen deren Superklasse UView ist, kann man beliebig ineinander stecken und so ganz eigene GUIs aufbauen. Nimmt man nun auch noch Bitmaps und die CoreGraphics mit hinzu, dann hat man unter Cocoa Touch fast die gleichen Möglichkeiten wie mit Flash.

ABER und genau in diesem Punkt gebe ich dir unbedingt Recht: Man darf sich nicht dazu verleiten lassen, Apps aus der einen in die andere welt 1:1 zu übertragen. Es ist immer der Kontext der Aufgabenstellung, den man in der entsprechenden Welt umsetzt. Dabei kann man natürlich Erfahrungen aus der anderen Welt mit heranziehen.

Was das Thema Performance betrifft, so gebe ich euch allen Recht: Da muss man genau hinschauen und auch sehr genau testen. Ich habe bei der Nutzung des Flash Packagers für iPhone die Erfahrung gemacht, dass man sich die von Adobe in der Doku veröffentlichten StyleGuides genau anschauen sollte. Dort stehen eine Reihe von Goldenen Regeln, wie man eine Flash App effizient baut, so dass sie mit guter Performance läuft. Diese habe ich bei meinen Arbeiten verinnerlicht und das zeigt auch Wirkung.

Wichtig ist aber auch, dass man, wenn möglich, mehrere Plattformen für die Gerätetests heranziehen sollte. Das ist bei der Preislage der Geräte natürlich etwas schwierig macht aber unbedingt Sinn. Nur so können Schwächen in der Performance bei unterschiedlichen Geräteklassen aufgedeckt werden. Daher habe ich immer mehrere Geräte im Test. Dabei tun es auch Gebraucht-Geräte, die ich teils auch von Freunden und Bekannten erworben habe.

Wie schon ausgeführt: Bei den iOS-Geräten muss für Flash Apps immer auch die ganze Laufzeitumgebung mit auf das Gerät geschleppt werden, bei Android-Geräten entfällt dies. Ich habe die Erfahrung gemacht, dass die selbe App, die auf meinem iPhone nicht so ganz flüssig lief, auf meinem HTC Desire diese Performanceproblemchen nicht hatte. Mit dem zum AIR 2.6 SDK gehörigen Packager (ADT) hat Adobe aber genau in dieser Hinsicht inzwischen kräftig Hand angelegt.

Apropos Adobe: Vor fast einem Jahr, am 9.April 2010 brüskierte Apple die Flasher-Welt, indem Flash-Apps aus dem iPhone ausgesperrt wurden. Um den 12. April 2010 herum zog dann Adobe die Konsequenz und stellte die Weiterentwicklung des iPhone-Packagers ein und teilte mit, dass nunmehr andere Plattformen, wie z.B. Android stärker unterstützt werden. Am 17. September 2010 nahm Apple diese Sperre wieder zurück. Ich kann mir nun vorstellen, dass Adobe logischerweise erst ab diesem Termin die Weiterentwicklung des iPhone-Packagers wieder aufnahm. Daher mussten und müssen wir Adobe noch ein bissel Zeit geben, bis der iPhone-Packager wirklich soweit ausgereift ist, dass Flash Apps genauso performant laufen, wie native Apps. Soviel zur Ehrenrettung von Adobe.

Übrigens: Ich bin auch bei der FFK in der kommenden Woche. Wenn es sich ergibt, können wir dort auch gerne mal bei einer Tasse Kaffee unsere Erfahrungen austauschen.

Gruß vom Flash Doc

[Omega Psi]

Zitat von Flash Doc

Übrigens: Ich bin auch bei der FFK in der kommenden Woche. Wenn es sich ergibt, können wir dort auch gerne mal bei einer Tasse Kaffee unsere Erfahrungen austauschen.

Klar, sehr gerne!

[Master Wu]

interessanter thread.
ich bekomme auch immer wieder anfragen zur app-entwicklung.
Leider hab ich weder nen Mac, ein Iphone und noch nichtmal so ein Android-Teil

Noch ein paar Fragen die ich zum thema hätte:

Nach dem was ich hier lese, wär ein entsprechendes Handy wohl schon dringend nötig?
Am besten mehrere!?
Reichts nicht, wenn man sich z.b ein eher altes iphone holt, wenn´s da läuft, dann doch auch auf nem neueren, oder nicht?
Wie sieht es mit einer Testumgebung für Iphone/Android-Apps auf Windows aus?
gibts da was?

Wegen der Performance: Dass es bei Spielen Probleme gibt oder anderen grafisch aufwändigen GEschichten ist klar.
Aber kann man davon ausgehen, dass eher simple Geschichten (Formulare, die Daten ausspucken, maximal ein Bitmap herumschieben, mit Effekt belegen o.ä.) auch aus CS5 erstellt keine Probleme macht?

[Nico B.]

Nein, davon kannst Du nicht ausgehen. Adobe ist zwar im Moment stark am schraueb, aber selbs android apps laufen nicht so cool wie native. (Ist zwar logisch, aber trotzdem schade )


Thema Testgeräte:
Extra für die Erstellung von Apps mit Flash würde ich mir son Handy net holen. Kann mir nicht denken,d ass sich das rechnet - aber ich kenn natürlich Deine Auftragslage nicht.

(Ansonsten: Neues iPhone, Android fone, ipad)