AS3: Optionales Injecten mit Robotlegs/SwiftSuspenders

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 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/OSMF: Bug im MediaPlayerSprite bei Browser-Resize

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

AS3/OSMF: Auf VideoElement zugreifen

Als Ergänzung zu neulich:

via

AS3/OSMF: Auf NetStream zugreifen

Letztendlich hat mir das nicht weitergeholfen, aber da ich recht lange danach googlen musste: So geht’s [Quelle]:

Auf LoadEvent.LOAD_STATE_CHANGE kann man wohl auch prüfen [Quelle], ka, ob das nötig ist:

FDT 5: Debugger per Ant starten [UPDATE]

Bevor ich das zum einhundertundelfzigsten mal suchen muss:

Analog dazu: Der Profiler

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.

AS3: GreenSock Loader (speziell XMLLoader)

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:

  • das Flag, um dieses Verhalten zu deaktivieren, lautet integrateProgress
  • in der XML definierte Loader werden nur dann erzeugt, wenn ihre Klasse bekannt ist. Um eine Klasse bekannt zu machen (zu “aktivieren”), gibt es bsplw. LoaderMax.activate()

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.

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