Air Applikation und flashlog.txt

Friday, June 24. 2011

Unter XP war das alles gar kein Thema, die installierte Air Appl. schrieb ihre Traces in die Datei flashlog.txt und gut. Aber auf Linux? Denn natürlich trat der Fehler, den ich suchte, nur auf, wenn die Anwendung unter Linux lief...

Ich dachte zunächst, dass auch für AIR der installierte flashplayer entscheidend sei (und für Linux 64 baut Adobe keinen debug-flashplayer). Aber in einer vm mit Mint/32, debug-flashplayer, korrekter mm.cfg und allem blieb die Air trotzdem stumm.

Etwas Suchen musste ich schon bis ich hier den entscheidenden Hinweis fand: 
cd /opt/$applName/share/META-INF/AIR
touch debug

(Für $applName natürlich den Namen der jwlg. Applikation einsetzen...) Die Appl. neu starten und nun schreibt sie ihre traces brav nach ~/.macromedia/Flash_Player/Logs/flashlog.txt

Mit Flex 3 eine air app als Installationspaket packen geht ja erstmal ganz leicht, Project/export release build  und der wizzard macht es. Anschliessend sind (appName).swf und (appName)-app.xml in der .air, die letztlich auch nur ein .zip mit kleinen Extras ist.
Hakelig wurde es mir erst, als ich zu diesen beiden noch weitere Dateien  (und Verzeichnissbäme) zufuegen wollte.

Relevante Einträge im properties-wizzard sind 'Flex Compiler / Compuiler options: Copy non embedded files to output folder ' und dann im export release build - wizzard die letze Seite, wo man zu integrierende Ressourcen auswählen kann. Wenn sie denn gelistet werden. Was dort gelistet wird, gilt. Die Regeln dafür, was dort gelistet wird, sind nicht eben intuitiv. 

Basis dessen ist der Ordner (projektOrdner)/bin-release. Was man vor einem release build in einen solchen Ordner kopiert oder linkt, wird im dann erzeugten .air enthalten sein.
Problem gelöst - nur leider: als naechstes wird der ganze Folder bin-release gelöscht und neu aufgebaut, mit dem Minimal-'Content  (appName).swf und (appName)-app.xml . Alles, was man da gesammelt hat, ist weg, und wenn man (wie hier, mit unterliegendem ext-Dateisystem) die Inhalte des bin-release per symLink eingestellt hat, ist auch gleich noch die Quelle des Links gelöscht. Einfach super. Alle Versuche, per Ownership oder Permissions oder HardLink oder was dies Löschen zu verhindern, führen zu bitterlichen Message-Boxen und sonst nirgendwohin.

bin-release ist hier also ein - mittelfristig gesehen - dynamisches Verzeichnis und definitiv nicht der Ort, um irgendwas wichtiges abzulegen / anzusiedeln. Es gibt ein best practice / howto von adobe, das ernstlich empfiehlt, bei jedem release-build die Dateien/Ordner hier neu einzukopieren. Ja danke, man nennt sowas glaub' ich Sollbruchstelle. Oder broken design, oder so...
Faktisch ist die Quelle für den Aufbau des dynamisch erzeugten bin-release der Inhalt des src/, aber...:

  • Verzeichnisse oder Verzeichnisbäume, die nicht wenigstens eine 'akzeptable' Datei enthalten, werden ignoriert
  • *.as und *.mxml sind *nicht akzeptabel*
  • wenn man also, wie ich, die Sache mit einem 'leeren' Verzeichnisbaum und einem Verzeichnis mit zwei .as testet, sieht man nichts.

Entfernt in dem Zusammenhang: Ein Blog - Labor zu headless building on Linux

In einem früheren Eintrag hatte ich ja mal über die Mühen der Installation von Adobe Air unter 64 Bit Linux geschrieben, irgendwie habe ich es dann doch hinbekommen. Ich arbeite derzeit selbst an eine air app und brauchte es. Ok, mein debian squeeze kde 4.4.5 listet mir nun unter K / utilities den Ad. Air Installer, mit dem ich mir ein *.air package installieren kann. Läuft, wunderbar, beim naechsten Versiönchen will ich den neuen Stand installieren: geht nicht, eine app dieses Namens sei schon vorhanden. Mh, das lässt sich ändern, kurz mal auf /opt/ und da steht die App, F8 und weg ist sie. - Von wegen!

Der Installer rödelt jetzt eine Weile und meldet dann, es habe ein Problem gegeben, sowas wie Fehler 1, und ich solle doch mal den Autor der Appp fragen. Fein! Wer immer sich solche Texte ausgedacht hat, in meinen Augen hat er sich eine rekursive Bastonade verdient. Wenn man sich schon die Mühe einer Messagebox macht, warum kann da dann nicht etwas stehen wie " schauen sie doch mal in $LogDatei, wo wir die richtige Fehlermeldung für sie versteckt haben"

 cat ~/.appdata/Adobe/AIR/Logs/Install.log  in meinem Falle, und dort findet sich dann auch der Text zur Fehlernummer: 
error 1  error: dpkg: Fehler beim Bearbeiten von /tmp/FlashTmp.xme90K/setup.deb (--install):; Versuch, »/opt/airBase/share/mimetype« zu überschreiben, welches auch in Paket  airbase.6eb066ed6af4d1c4f05c36654e32b365cae9a188.1 v1 ist;

Aha, deshalb das anfängliche Rödeln: der Air Installer hat das .air in ein .deb umverpackt und an dpkg übergeben. 
dpkg -l|grep airbase (der momentane Arbeitstitel meines vorhabens) zeigt mir das installierte app,
dpkg -r PAKETNAME
macht es weg und dann tut auch der Installer wieder.

Nun, es geht auch mit Software-Center/Installierte Anwendungen und jemand hat sogar einen speziellen Uninstaller for Adobe AIR geschrieben.

In einem Flex3-Projekt sollen die Bitmaps jetzt nicht mehr, wie vorher, zentriert in ihren Rahmen gecroppt stehen, sondern mit Scrollbalken. Mein alter Weg war, wie in der Adobe Referenz empfohlen, eine UIComponent zu erzeugen, der ich die Bitmap als Child gab und die ich wiederum als Child dem Canvas anfügte. Ging soweit wunderbar, aber wenn die Bitmap nun nicht mehr maskiert war und der Canvas sie hätte scrollen sollen, ignorierte er das stattdessen und zeigte sie aus dem Rahmen lappend an. Obwohl clipContent=true gesetzt war.

Die Lösung fand ich in einem Blog : 

var myBitmap:Bitmap = new Bitmap(myBitmapData);
var myImage:Image = new Image();
myImage.source = myBitmap;
myCanvas.addChild(myImage);

Die Magie liegt hier darin, die source - property zu setzen

Flex3 SDK doesn't like 64Bit Java

Monday, March 7. 2011

I stumbled over this when I I had to fix a little something on an older project Flex3 and a certain part needed to get compiled by mxmlc.exe. But it wouldn't, all the path names etc. looked just fine but mxmlc wouldn't even start.  All I got was a message in the command line interface like:

Exception in thread "main" java.lang.UnsupportedClassVersionError: flex2/tools/Compiler (Unsupported major.minor version  48.0)
        at java.lang.ClassLoader.defineClass0(Native Method)
        at java.lang.ClassLoader.defineClass(Unknown Source)
        at java.security.SecureClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.access$100(Unknown Source)
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClassInternal(Unknown Source)

And why flex2? Google didn't help much, I found a thread in the Adobe Knowledge base with a matching description but no useful answer, the OP got the advice to edit the build.xml file but it didn't solve his problem and looking at mine it looked just fine.

It took me ages of search until I found someone mention  64 Bit difficulties: and yes, move the sdk and projekt files to a 32 bit environment in a vm and it compiles nicely.

What is it with adobe and 64 bit: no flash debug player on linux, no air runtime on linux and the mxmlc dompiler doesn't even run on 64 bit Windows.  

(Page 1 of 2, totaling 8 entries) » next page