1 |
/path/to/flex/bin/swfdump /path/to/my.swf > swf_info.txt |
PS: Die Actionscript-Version kann man hier herausfinden, bzw. manuell
OSMF 2.0 hat einen Bug: Ich positioniere ein MediaPlayerSprite mittig auf der Bühne und skaliere es so, dass es eine gewisse Fläche immer füllt. Das Video darf links/rechts oder oben/unten aus der Fläche rausragen, solange die Fläche gefüllt ist (“scale proportional outside”).
Wenn ich allerdings den Browser ganz schmal ziehe, sehe ich unregelmäßig andere Ausschnitte des Videos. Die x-Position des MediaPlayerSprites stimmt genau, das Video darin aber nicht.*
Und, noch abstruser: Wenn ich den Browser am Rand anfasse und skaliere, dann verhält sich das Video anders, als wenn ich den Browser in der Ecke anfasse. Darauf muss man auch erst mal kommen; das sollte man sich merken für’s nächste Projekt.*
*getestete Flash Player Versionen: 11.x (nicht alle), 12.0
Wie auch immer: OSMF 1.6 hat diesen Bug ebenfalls, OSMF 1.5 allerdings nicht. Dafür sieht das Video in 1.5 unschön aus; offenbar ist smoothing nicht gesetzt. Es ist nicht ganz offensichtlich, wie man an das Video eines MedaPlayerSprites rankommt, aber das soll hier nicht das Thema sein 🙂 Weitere Einschränkung: StageVideo gibt es erst ab OSMF 1.6 – vielleicht liegt der Bug also auch im StageVideo?
HTH
Letztendlich hat mir das nicht weitergeholfen, aber da ich recht lange danach googlen musste: So geht’s [Quelle]:
1 2 3 4 5 6 7 8 9 10 11 |
mediaPlayer.addEventListener(LoadEvent.LOAD_STATE_CHANGE, onLoadStateChange); private function onLoadStateChange(e:LoadEvent) { if(e.loadState == LoadState.READY) { var nsLoadTrait:NetStreamLoadTrait = mediaPlayer.media.getTrait(MediaTraitType.LOAD) as NetStreamLoadTrait; var ns:NetStream = nsLoadTrait.netStream; } } |
Auf LoadEvent.LOAD_STATE_CHANGE kann man wohl auch prüfen [Quelle], ka, ob das nötig ist:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
mediaPlayerSprite.mediaPlayer.addEventListener( MediaPlayerCapabilityChangeEvent.CAN_PLAY_CHANGE, capabilityHandler); private function capabilityHandler(event:MediaPlayerCapabilityChangeEvent):void { if(event.type == MediaPlayerCapabilityChangeEvent.CAN_PLAY_CHANGE) { if (mediaPlayerSprite.media.hasTrait(MediaTraitType.LOAD)) { mediaPlayerSprite.media.getTrait(MediaTraitType.LOAD) .addEventListener(LoadEvent.LOAD_STATE_CHANGE, onLoadStateChange); } } } |
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
Wer Fehler a la
identifier vor xmltagstartend erforderlich.
oder anderen kryptischen Kram bekommt, sollte die XML so einbinden:
1 2 3 4 5 6 7 8 |
[Embed(source="assets/myXml.xml", mimeType="application/octet-stream")] private var EmbeddedXml : Class; private var _myXml : XML; // ... var ba : ByteArray = (new EmbeddedXml()) as ByteArray; var s : String = ba.readUTFBytes( ba.length ); _myXml = new XML( s ); _myXml.ignoreWhitespace = true; |
Also: mimeType beachten, und dass die eingebettete Klasse nicht direkt auf XML gecastet wird. Außerdem ignoreWhiteSpace, das’ ja klar 🙂
Es ist recht einfach, ein komplettes Projekt als SWC zu kompilieren: Rechtsklick auf’s Projekt -> Run as -> FDT SWC Library (Quelle). Ein Ant-Skript wäre schöner, aber grundsätzlich ist es so erst mal einfach. Was die Sache nämlich an anderer Stelle verkompliziert, ist der allseits beliebte Fehler 1047:
Parameter initializer unknown or is not a compile-time constant.
bzw.
Parameterinitialisierer unbekannt oder keine Kompilierungszeit-Konstante.
Dieser tritt dann auf, wenn man eine Konstante als default-Übergabe-Parameter nutzt, und die Klasse mit der Konstante erst nach dieser Klasse kompiliert wird. Oder so. Es gibt haufenweise Einträge dazu im Bug-Tracker, teilweise schon jahrealt, leider ohne Ergebnis. Die längste Antwort von Adobe (die nicht “OK, wird noch mal geprüft” lautet) ist “Wäre schwierig zu implementieren, machen wir nicht.”^^
Deshalb folgende Lösungsansätze:
Das nervt mich gerade extrem, hat jemand eine bessere Lösung?