1 |
/path/to/flex/bin/swfdump /path/to/my.swf > swf_info.txt |
PS: Die Actionscript-Version kann man hier herausfinden, bzw. manuell
Injects sind in Robotlegs 1.x/SwiftSuspenders 1.x erst mal verbindlich, so wie ich eine entsprechende Aussage von Till Schneidereit verstehe. Ein [Inject] führt dann zu einer Fehlermeldung:
Error: Injector is missing a rule to handle injection into property “myProperty” of object “[object MyClass]”. Target dependency: “com.acme.some.package::MyInjectType”, named “”
Der dort verlinkte Custom Build (Downloadübersicht siehe hier) enthält SwiftSuspenders 2, und das erlaubt optionale Injects. In meinem Test funktioniert das übrigens ohne ein “(optional=true)”, wie im oben verlinkten Thread vorgeschlagen – der Inject ist einfach null.
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(
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); } } } |
Bevor ich das zum einhundertundelfzigsten mal suchen muss:
1 |
<fdt.startDebugger projectname="my_project" switchperspectiveonbreakpoint="true" /> |
Analog dazu: Der Profiler
1 |
<fdt.startProfiler projectname="my_project" /> |
UPDATE: Eine CoreException wie
org.eclipse.core.runtime.CoreException: could not build project
kann man mittels Project->clean beheben; ein
BUILD FAILED
/xxx/yyy/zzz/build/build.xml:123: java.lang.NullPointerException
liegt vermutlich an der Flex-Version. Ich habe das erfolgreich für einige Versionen unter 4.6 getestet, für 4.6 muss man die flex-sdk-description.xml ändern.
GreenSock bietet primär natürlich Tweening-Krams. Aber auch die Loader sind nicht schlecht – wenn man damit zurecht kommt, dass sie mehr als nur Laden können. Der VideoLoader bsplw. ist quasi auch ein Video-Player.
Ähnlich der XMLLoader: Der lädt erst mal eine XML, aber darüber hinaus parst er diese XML und erzeugt & startet alle darin in der entsprechenden Syntax definierten Loader. Per default! Dazu zwei Anmerkungen:
integrateProgress
In Kombination führt dies zu echt mies zu findenden Bugs: “Normalerweise” kenne ich an der Stelle, an der die XML geladen wird, nur den XMLLoader – denn der lädt die XML. Das heißt, in der XML definierte XMLLoader werden immer erzeugt und ausgeführt, denn integrateProgress
ist per default true. Alle anderen in der XML definierten Loader werden zwar theoretisch ebenfalls erzeugt, aber nur, wenn ihre Klassen bekannt sind (sie “aktiviert” wurden)! Fügt man in einen jahrealten (sic!) Prozess einen XMLLoader in eine XML ein, dann wird der (und nur der) plötzlich ausgelöst… unschön.
HTH.
🙂
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