1 |
/path/to/flex/bin/swfdump /path/to/my.swf > swf_info.txt |
PS: Die Actionscript-Version kann man hier herausfinden, bzw. manuell
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
1 2 3 4 |
function embedFlash() { swfobject.embedSWF("myApp.swf", "flashcontent", "100%", "100%", "11.1.0"); } setTimeout(embedFlash, 1); |
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:
1 2 3 4 5 |
<?php header("Cache-Control: no-cache, must-revalidate"); header("Pragma: no-cache"); header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); ?> |
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(
🙂
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):
1 |
-link-report=${basedir}/build/link-report.xml |
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:
1 2 3 |
<target name="process link report"> <xslt in="${basedir}/build/link-report.xml" out="${basedir}/build/link-report.html" style="${basedir}/build/lib/link-report.xsl"/> </target> |
Das Ergebnis kann sich sehen lassen: Nach Größe sortiert und mit Verlinkung auf die Klasse/SWC
Wessen FDT beim “pre-launch check” hängen bleibt, der möge sein Eclipse auf 3.7.2+ updaten. Quelle, via. Funktioniert erstaunlich gut – während ein lauffähiges FDT normalerweise nach dem Update nicht mehr geht, war es dieses mal andersherum^^
Basierend auf diesem tollen Post (via Björn) ist folgende Funktion entstanden:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
public static function getEnabledState( networkInterface : String = '*' ) : Boolean { var isEnabled : Boolean = false; if( NetworkInfo.isSupported ) { var interfaces : Vector. = NetworkInfo.networkInfo.findInterfaces(); var item : NetworkInterface; for each( item in interfaces) { trace( 'network interface "' + item.name + '" active: ' + item.active ); switch( true ) { case networkInterface == '*' && item.active: isEnabled = true; break; case item.name.toLowerCase().indexOf( networkInterface ) != -1 && item.active: isEnabled = true; break; } } } return isEnabled; } |
Den default-Parameter “*” zu verwenden macht allerdings fast nie Sinn; stattdessen benutze ich
HTH
Connecting Arduino Prototyping board to Adobe AIR through an ANE, via
UPDATE: Moved to GitHub
AIR Native Extensions (ANE) erlauben das Verwenden von System-spezifischen Funktionen – hier das Gyroscope. Mit FDT 4.5 verwendet man sie wie folgt:
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:
Zu Video (hier: StageVideo) auf dem iPhone:
Fazit und offene Fragen:
HTH,
Lennart