Safari blockiert Plugin ohne entsprechenden Hinweis?

Safari blockiert Plugins wie Flash und Java. Normalerweise bekommt man einen entsprechenden Hinweis:

es sei denn, man hat diesen Hinweis explizit deaktiviert. Manchmal erscheint der Hinweis allerdings nicht, und keiner weiß, warum. Eine erste Beobachtung: Wenn ich in den Entwicklertools (oder wie auch immer das beim Safari heißt) die Höhe des SWFs von 100% auf 99% ändere, dann erscheint der Hinweis. Vielleicht liegt’s an den 100%? Aber nein, steht das SWF schon beim Laden auf 99%, bleibt der Fehler. Es muss also am Repaint liegen, der durch die Änderung in den Entwicklertools ausgelöst wird.

Deshalb, die Lösung: Eine Millisekunde Verzögerung zwischen Seitenaufbau und Rendering des SWF

Plus: Safari scheint die Seite nach Freischaltung des Plug-Ins aus seinem Cache zu ziehen und dann irgendwie durcheinander zu kommen. Deshalb setze ich die folgenden Header für die Seite:

Dann geht’s.

Ich weiß, warum ich froh bin, mich mit diesem Crossbrowser-Gedöns nicht mehr (allzu oft) beschäftigen zu müssen m(

AS3: Lesbarer “link-report”

Mit dem mxmlc lassen sich “Link-Reports” erstellen; entfernt vergleichbar mit dem “Größenbericht” aus der Flash-IDE: Welche Klassen sind in meiner SWF enthalten, und wie viel Platz belegen sie. Die Compileroption dazu (in Ant-Schreibweise aus FDT):

Allerdings sind diese Linkreports schlecht lesbar. Ich möchte auf einen Blick sehen, welche Klasse der Grund dafür ist, dass mein SWF 2 MB statt 500 KB groß ist. Gut, dass es Theo Hultberg gibt: Der hat eine XSL geschrieben, um den Linkreport in eine verständliche Form zu bringen (hier der Blogeintrag und die lokale Kopie der XSL). Ant kann XSL von haus aus:

Das Ergebnis kann sich sehen lassen: Nach Größe sortiert und mit Verlinkung auf die Klasse/SWC

linkreport

[AIR] Art der Internetverbindung abfragen

Basierend auf diesem tollen Post (via Björn) ist folgende Funktion entstanden:

Den default-Parameter “*” zu verwenden macht allerdings fast nie Sinn; stattdessen benutze ich

  • “wifi” für WLAN
  • “en” für Ethernet
  • “mobile” für 3G usw

HTH

AIR Native Extensions mit FDT

AIR Native Extensions (ANE) erlauben das Verwenden von System-spezifischen Funktionen – hier das Gyroscope. Mit FDT 4.5 verwendet man sie wie folgt:

  1. Die .ane-Datei kopieren, und die Kopie in .swc umbenennen.
  2. Die .swc wie gewohnt in den Classpath einbinden.
  3. In den Projekteigenschaften -> “FDT Build Path” -> “Build Order” die SWC auswählen, und einen Haken bei “Use as Runtime Shared Code” setzen.
  4. Die Extension im Description-XML deklarieren: Entgegen der Vorlage der Powerflasher heißt der Knoten nicht <extension>, sondern <extensions>, und sieht für dieses Beispiel wie folgt aus:
    <extensions><extensionID>com.adobe.gyroscope</extensionID></extensions>
  5. Die .ane-Datei im Projekt ablegen, beispielsweise unter /bin/ane/
  6. Im Build-XML (das mit dem ADT-Compiler) folgende Zeilen hinzufügen:
    <arg value=”-extdir” />
    <arg value=”../bin/ane” />
  7. Kompilieren 🙂

Tipp, Quelle 1, Quelle 2 (PDF)

Flash auf dem iPhone: Eine AIR-Videoplayer-App in FDT 4.5

Neulich stand ein entsprechendes Projekt auf dem Plan. Meine erste iPhone-App, und meine erste umfangreichere AIR-Anwendung. Hier meine Anmerkungen zum Workflow:

Zum Aufsetzen des Projektes in FDT 4.5:

Zu AIR auf dem iPhone:

  • Evt. muss der Compiler-Parameter -swf-version=11 gesetzt sein. Ohne hatte ich einen 1014 Class not found (Quelle). Damit das übernommen wird, muss ggf. USE_PROJECT_COMPILER_ARGUMENTS auf false stehen
  • Für mehr Performance: AIR 3 verwenden (Danke, Björn!); wobei ich die playerglobal.swc direkt unter www.adobe.com/support/flashplayer/downloads.html gefunden habe
  • Einen Splashscreen (“Default.png”) fügt man im jeweiligen Ant-Script unter “Files to Package” unter der SWF ein: <arg value=”Default.png” />
    (Damit erklärt sich von selbst, wo man weitere ADT-Parameter hinzufügt). Bei mir liegt das Default.png parallel zur SWF in /bin/
  • In dem Zusammenhang: Wenn ich die App-Icons in /bin/icons/* liegen habe, dann füge ich die relativ zu /bin/ im Build-Skript (<arg value=”icons/icon512.png” />) und im Descriptorfile (<image512x512>icons/icon512.png</image512x512>) hinzu
  • Um die App bei Rückkehr zum Homescreen zu beenden, muss man in der ADL-Decriptor-XML unter iPhone.InfoAdditions “<key>UIApplicationExitsOnSuspend</key><true/>” hinzufügen (Quelle)
  • Wer das iPhone 3 und 4 verwenden will, muss unbedingt die unterschiedlichen Auflösungen im Auge behalten! Ich habe es nicht geschafft, einfach die höher aufgelöste SWF auf den kleineren Screen runterzuskalieren, sondern musste im Code darauf reagieren.

Zu Video (hier: StageVideo) auf dem iPhone:

  • Ein gutes Tutorial (inkl. Sourcen) von Thibault Imbert für StageVideo gibt es hier.
  • Für StageVideo-Wiedergabe muss der renderMode (siehe Descriptor-XML) auf “gpu” oder “direct” stehen – “auto” genügt nicht. “gpu” verringert aber die Performance der restlichen Anwendung; “direct” scheint OK zu sein. (PS: “direct” wird im XML-Kommentar nicht erwähnt; Quelle)

Fazit und offene Fragen:

  • Die Performance ist schlechter als nativ, aber absolut OK. Man muss ein wenig darauf achten, wie viel man parallel macht, aber wenn man das weiß, ist AIR eine echte Alternative.
  • Wenn ich sage “die Performance ist OK”, dann meine ich Code, der (abgesehen von StageVideo) nicht optimiert ist! Die Performance ist sicherlich noch besser, wenn man z.B. Stage3D verwendet
  • Sweet: Bis zum Verpacken in einer IPA hat man ein SWF, was Abstimmungen extrem einfach macht.
  • Ich habe es nicht geschafft, das StageVideo um 90° zu drehen, was laut verschiedener Quellen möglich ist. Wer einen Tipp hat, immer her damit!
  • Die gleiche Anwendung müsste auch auf Android exportierbar sein, das habe ich aber noch nicht ausprobiert

HTH,

Lennart