Jan 20 2012

Adobe Flash – Important Bug – RSL & FlashVars

Tag: Actionscript,Adobe,Adobe Flash - bug or feature,AllgemeinKonstantin Elstner @ 09:16

Seit Adobe im Jahr 2010 Flash Professional CS5 vorgestellt hat, kommt es immer wieder zu einem aufttretenden Bug.
Die Möglichkeit FlashVars auszulesen existiert schon fast seit der Jahrtausendwende, Adobe scheint es aber zu lieben Entwicklern immer wieder Steine vor die Füße zu werfen, auch bei den FlashVars ist es nicht anders. Normalerweise sollten diese wie folgt auslesbar sein:

loaderInfo.parameters.xmlPath

Diese Codezeile würde die Variable „xmlPath“ wenn gesetzt auslesen.

Seit Flash CS5 kann es aber passieren das eben dieser Code „undefined“ zurück gibt, obwohl die Variable korrekt von außen gesetzt ist. Ein Umstand, der so gut wie jeden Entwickler in den Wahnsinn treiben kann.

Sollte das auslesen wie oben beschrieben einmal nicht funktionieren sollte man entweder:

parent.loaderInfo.parameters.xmlPath

oder wenn dies auch nicht zum Ziel führt:

parent.parent.loaderInfo.parameters.xmlPath

probieren.

 

Alternativ geht auch der Zugriff über root oder stage:

Global.xmlPath = root.loaderInfo.parameters.xmlPath

oder

Global.xmlPath = stage.loaderInfo.parameters.xmlPath

 

Warum dies notwenig ist?

Adobe hat mit Flash CS5 auch für die IDE das RuntimeSharedLibrary Feature eingeführt (kurz RSL), diese Technik kommt aus dem Flex Bereich und wird ua. für das TextLayoutFramework verwendet. Mit Hilfe von RSL können einzelne Klassen in SWZ Dateien gepackt werden, diese werden gesondert signiert und der User muss nicht zB. bei jedem Flex Anwendungsaufruf das komplette Flex Framwork laden, sondern nur die vom Entwickler integrierten Erweiterungen. Dies spart Traffic und kann auch in eigenen Klassen verwendet werden. Weitere Infos gibt es unter http://help.adobe.com/de_DE/FlashPlatform/reference/actionscript/3/fl/rsl/package-detail.html.

Damit die generierte SWF die bereitstehenden RSL-Dateien vor der eigentlichen Anwendung laden kann integriert Adobe automatisch einen RSL-Preloader. Da man bei Adobe stellenweise wohl nicht so viel Wert auf QM legt hat sich in diesem Preloader ein Bug eingeschlichen, der eben die Übergabe, bzw. die Weiterleitung der FlashVars verhindert, daher der Workaround via parent.loaderInfo.

Adobe ist über den Bug informiert, hat diesen aber auch in die Version CS5.5 übernommen, bleibt zu hoffen er wird in CS6 endlich gefixt, denn selbst ein unabsichtliches anlegen eines TLF basierenden Textfeldes in der IDE ruft die fehlerhafte RSL-Preloader-Mechanik auf die Tagesordnung.

http://forums.adobe.com/thread/644057


Nov 14 2011

Adobe stoppt die Weiterentwicklung des Flash Players Mobile

Tag: Actionscript,Adobe,FlexKonstantin Elstner @ 13:13

„Die Nachrichten über meinen Tod sind stark übertrieben.“
Mark Twain

1 ) Einleitung

Auf Grund der Nachrichten die in den letzten Tagen durch verschiedenste Medien geisterten, inklusive teilweise schlecht recherchierter Details, sehe ich es als notwendig an, dass Geschehene zusammen zu fassen und etwas Licht in die Sache zu bringen.

Vom Standpunkt der Entwickler und Agenturen aus, gibt es aktuell eine tiefe Unsicherheit darüber was passiert ist und was die verbreiteten Informationen für die Erstellung von Flash basierenden Produkten bedeutet.

An dieser Stelle möchte ich klar darauf hinweisen, dass die hier zusammengefassten Informationen, auf aktuellen Information von Adobe und seinen Community Managern basieren und von mir mit besten Gewissen zusammengefasst werden. Alle Fakten, Informationen und ähnliches lassen sich leider nicht als 100% Sicherheit für die Zukunft darlegen, andernfalls wenn ich die Zukunft 100% voraussagen könnte, dann wäre ich nicht Webentwickler geworden, sondern eher Aktienbroker oder Hellseher.

 

2 ) Was ist die Flash Platform?

Da Adobe stellenweise sehr unkontrolliert mit dem Wort Flash um sich wirft eine kurze Darstellung was unter der sogenannten Flash Platform zu verstehen ist.

Die Flash Plattform steht für alle Produkte, die auf der Adobe Flash Technik basieren. Die Flash Technik darf hierbei nicht 1:1 mit dem Flash Player gleich gesetzt werden, da der Flash Player nur ein Bestandteil der Flash Platform ist.

Unter der Adobe Flash Plattform werden zusammen gefasst:

  • Adobe Flash Player Desktop (Windows, Mac, Linux, Chrome OS)
  • Adobe Flash Player mobile ( bis Version 11.1 nur Android )
  • Verschiedenste „lite“ Flash Player für Handys
  • Die Adobe Integrated Runtime (AIR), Basis für die Erstellung von Apps für Desktop (Mac, Windows, Windows 8 (geplant), Linux (bis Version 2.6)), mobile Geräte (iOS, Android, QNX (RIM), Windows 8 (geplant)), Set-Top-Boxen und Fernseher (Stichwort Smart TV)
  • Adobe Flex (Framework für die Erstellung von Businessanwendungen)

Des Weitern gibt es über einen einfachen Texteditor hinaus verschiedenste Editoren:

  • Adobe Flash Professional
  • Adobe Flash Builder
  • Powerflasher FDT
  • FlashDevelop
  • Open Laszlo
  • JetBrains IntelliJ IDEA

 

3 ) Zusammenfassung der letzten Tage

Adobe hat im Zeitraum 8.11.11 bis 11.11.11 ein massives Missmanagement im PR Bereich betrieben, es wurden unzureichende Informationen gestreut und keine klaren Erklärungen abgegeben. Der Auslöser war eine Vorabmeldung von ZDNET.com am 8.11, in der berichtet wurde, dass Adobe rund 750 Mitarbeiter weltweit entlässt. Ebenso wurde von ZDNET.com berichtet, dass Adobe den Flash Player mobile nicht mehr weiter entwickeln wird.

Die Meldung schlug mehr oder weniger ein wie eine „Bombe“, es ließ sich im Vorfeld nicht erkennen, dass Adobe einen solchen Schritt im Rahmen seiner umfangreichen Restrukturierung plant. Die gesamte Community wurde direkt und überraschend getroffen. Selbst in den Pre-Release Foren von Adobe, wo registrierte Entwickler Zugriff ab Vorab-Versionen des Flash Players und von AIR erhalten, gab es bis zu diesem Tag keinen Hinweis auf das Kommende. Es wurden teilweise noch Informationen für den nächsten Release des mobilen Players sowie weitere Entwicklungsschritte diskutiert.

Selbst die Adobe Community Manager, die für die Betreuung der Entwickler sowie der Weitergabe von Informationen an die Öffentlichkeit zuständig sind, wurden vorab nicht über diese Entscheidung informiert. Erst 4 Tage später gab es hier erste konkrete Statements und Informationen.

Da Adobe auf eine Äußerst miserable Art und Weise den Stop des mobilen Players bekannt gegeben hatte und im zweiten Atemzug verkündete, dass man sich nun voll auf HTML5 konzentrieren wollte und nur nebenbei anmerkte, dass ein wichtiger Focus auch die Erstellung von Apps via AIR sei, feierten viele Online Magazine Steve Jobs für seine „Vision“, des Flash freien mobilen Internets. Des Weiteren wurde die Abkehr vom mobilen Flash Player als des Ende des generellen Flash Players, bzw. dessen Beerdigung hingestellt.

Diese Meldungen wurden soweit aufgebauscht, bis die Meldung die Runde machte, Adobe hätte alle Flash Professional Entwickler vor die Tür gesetzt, was sich aber als Falschmeldung heraus stellte.

Man kann hier nur mit dem Kopf schütteln, der Ärger in der Community war immens.

 

4) Warum die Entscheidung richtig ist

Der mobile Flash Player wurde mehr als 10 Mio. mal herunter geladen, jedoch hat er sich nie so nahtlos in die Websites integrieren lassen wie es notwendig wäre. Es gibt etliche verschiedenste Geräteplattformen auf die alle Player hin optimiert werden müssen, dies kostet immens viel Zeit und Geld. Etliche mobile Geräte sollen einen schnellen Zugang zu Informationen wie Fahrpläne, Adressen, Preise, Nachrichten usw. zur Verfügung stellen, nicht unbedingt mit deluxe Medieninhalten um sich werfen, denn dies erwartet der User nicht mit seinem Gerät.

Neben diesen Punkten ist der mobile Flash Player eine Art App im Browser, dies führt dazu, dass Zoom- und Wischgesten, sowie weitere Multitouchgesten nicht sauber implementiert werden konnten, bzw. die Frage für den Browser beispielsweise war, will der Nutzer nun die Seite scrollen oder den Text im Flash.

Die mobilen Geräte sind zusätzlich in ihrer Leistungsfähigkeit sehr begrenzt, daher ist auch die Wiedergabe von zum Beispiel Videos in einer App in einem Browser eine sehr komplexe und leistungsintensive Angelegenheit. Nebenher liefern Seiten wie Spiegel Online keine für die Geräte optimierten Videos in der perfekten Größe aus, statt dessen an alle nur das Video, welches im Fullscreen am besten aussieht. Daher wurde exponentiell durch die Videogröße mehr Leistung verbraucht, als wirklich notwendig wäre.

Nur die wenigsten der aktuellen Seiten sind für die mobile Nutzung konzipiert und optimiert. Da verschiedenste Agenturen Flash als „Spezial-Effekt-Lösung“ ansehen, sind die meisten professionellen Seiten sehr sehr CPU intensiv. Dies mag auf einem aktuellen Desktop-Rechner möglich sein, führt jedoch bei mobilen Geräten, die die Hälfte bis ein Drittel der CPU-Leistung haben, im Vergleich zu einem Desktop-Rechner, zu einer zähflüssigen, Absturz gefährdeten Ansicht der Seite.

Grundsätzlich wäre hier zwar die Frage zu stellen, inwiefern Adobe, oder die Entwickler der Seite die Schuld trifft. Aber gerade solche Abstürze haben zu einer sehr sehr schlechten Wahrnehmung des Players bei den Usern geführt. Anbei bemerkt, auch eine native iOS Anwendung kann abstürzen, ebenso wie eine Android Anwendung, denn wenn der Speicher voll ist, dann ist er voll, und das geht mit jeder beliebigen Sprache.

Mit dem aktuellen Flash Player Version 11 wurde die Möglichkeit der Hardware-gestützen 3D Wiedergabe von Spielen, 3D Anwendungen usw. integriert, ebenso wird mit den nächsten Versionen Multithreading (1 Prozess kann auf mehrere CPU´s verteilt werden) eingeführt. Zur Entlastung des CPU’s wurde die Möglichkeit des Renderns von Video via der Hardware aktiviert, bei Desktop-Anwendungen sind 4 solcher Videos parallel möglich, auf den mobilen Geräten maximal 1 Video.

Wenn man einen 3D Egoshooter baut, so wird dieser kaum auf einem mobilen Gerät via des selben Codes nutzbar sein, bzw. wird sich der User schwer tun, statt mit der Maus, das Fadenkreuz via seines Fingers durch Antippen und auf dem Display wischen zu steuern. Daraus lässt sich ableiten, dass eine direkte Entwicklung des Flash Players Desktop parallel zu der mobilen Variante kaum realistisch umsetzbar ist. Eine Erkenntnis für die Adobe vielleicht etwas lange gebraucht hat.

Hätte es also je Sinn gemacht, einen schon durch seine Plattform und Art der Einbettung stark eingeschränkten Player weiter zu entwickeln, wenn der User von diesem das gleiche Verhalten wie von einem Desktop Flash Player erwartet?

 

5 ) Das mögliche Weiterleben des mobilen Players

Nicht nur die Entwickler-Community fühlt sich im Moment zu Recht im Regen stehen gelassen, ebenso fühlt sich RIM (Research In Motion) mit seinem Tablett „Playbook“ vor die Wand gestellt. Etliche der Playbook-Anwendungen basieren von Haus aus auf Produkten der Flash Platform. RIM sieht den Flash Player mobil von daher als essentiell für seine Plattform an und will nun laut einem aktuellen Statement, die von Adobe angebotene Möglichkeit der Lizenzierung des Flash Player Mobile Quellcodes nutzen, um den Player für die eigene Plattform aktuell zu halten und weiter zu entwickeln.

Mal eine rein spekulative These:

Vielleicht erleben wir noch ein Wunder und Google entschließt sich für seine Android Plattform auch den Flash Player Mobile Quellcode zu lizenzieren und weiter zu entwickeln. Ich glaube zwar nicht daran, aber etliche Android Tabletts werben ja mit dem Argument, dass sie Flash Inhalte wiedergeben können.

 

6 ) Wie lange Flash Mobile noch wo existieren wird

Im Moment wird der Flash Player Mobile auf den Versionen Android 2.3 bis 4.x unterstützt, da selbst das gerade erscheinende Android 4.0 zu den Unterstützen Plattformen gehört, schätze ich die „Lebensdauer“ auf noch gut 1,5 Jahre, bzw. so lange wie die Geräte noch kein Android 5.0 installiert haben. Ob für alle Geräte wichtige Funktionen wie das hardwareunterstützte Video-Encoding verfügbar sein wird, kann ich nicht sagen.

 

7 ) Flash Player für Fernsehgeräte

Eher als Randnotiz ist nun bekannt geworden, dass der Flash Player Support auf Fernsehgräten ebenso eingestellt wird, da bisher nur recht wenige Geräte diesen überhaupt aktiviert hatten, dürfte dies kaum relevant sein. Unoptimierte Flash Inhalte ließen sich hier fast gar nicht verwenden, da hier die Steuerung des Zeigers via der Fernbedienung erfolgt, was zu einer sehr schlechten User-Erfahrung führt. Parallel wird aber AIR für die Fernsehgeräte entwickelt, dies wird in der Zukunft spannende neue schnell zu entwickelnde Anwendungen zu Tage fördern.

 

8 ) Widerstand der OS Anbieter

Nach Apples Nicht-Integration von PlugIns in ihren iOS Browser, hatte auch Microsoft bei der Vorstellung der ersten Windows 8 Preview angekündigt, dass im Internet Explorer, der in die Metro Oberfläche eingebaut ist, keine PlugIns unterstützt werden. Die Metro Oberfläche stellt eine vereinfachte touchoptimierte Benutzeroberfläche von Windows 8 dar, die vornehmlich auf den Tabletts zum Einsatz kommen wird. Der Internet Explorer in der klassischen Ansicht wird aber weiterhin alle PlugIns unterstützen. Ob die klassische Oberfläche auf den Tabletts zur Verfügung stehen wird, ist noch nicht bekannt.

Keine PlugIns heißt also kein Flash Player.

 

9 ) Buzzword HTML5

Im Rahmen der aktuellen Hysterie rund um die Einstellungen des mobilen Flash Players wird im Moment wieder geradezu inflationär mit dem Wort HTML5 um sich geworfen. An dieser Stelle könnte man lang und ausführlich erläutern was HTML5 ist, jedoch halte ich es kurz. HTML5 ist die Version 5 des HTML Standards, mit der einige neue Features eingeführt wurden wie das Canvas Objekt, in dem Inhalte „gezeichnet“ werden können, das Video Objekt, dass Videos ohne weitere PlugIns wieder geben kann, sowie etliche weitere kleinere neue Features.

Das HTML5 mit Animationen, 3D Transformationen etc., wie es im Moment gepusht wird, kann nur in Zusammenarbeit mit JavaScript in der gewünschten Form genutzt werden. Da derzeit noch nicht alle Browser diese „neuen“ HTML5 Features verwenden können, werden die meisten als „HTML5“ titulierten Anwendungen / Websites mit HTML4, Javascript und manch neuen HTML5 Features entwickelt.

Korrekt wäre daher eher der Begriff HJC, stehend für HTML+JavaScript+CSS. Ergo sind die meisten jetzigen Anwendungen HJC und es wird nicht schlagartig noch etwas Neues viel besseres kommen. Nur kleine Details werden erweitert, aber das was jetzt genutzt und gebaut wird, ist das was HJC ist, bzw. auch HTML5 genannt wird.

Fakt ist, dass HJC heute einen Entwicklungsstand und Möglichkeiten bietet, die Flash vor 8 Jahren schon geboten hat. Daher muss bei der Umsetzung, Planung und Strategie von HJC Sites rückwärts gedacht werden, es darf konzeptionell und reell nur das erwartet werden, was mit Flash schon im Player 8 und weniger ging. Mehr zu erwarten oder zu verkaufen wäre fatal.

 

10 ) Die Zukunft von Flash im Browser

Der primäre Focus bei der Entwicklung von Flash in Hinblick auf die Zukunft liegt auf den Schwerpunkten Rich Media Experiences – Dinge mit Flash zu bauen, die mit HJC nicht möglich sind oder etwas so zu bauen, dass es in allen Desktop Browsern gleich aussieht. Parallel wird die Flash Platform als Gamingplatform ausgebaut, daher werden wir mehr und mehr 3D Spiele basierend auf Flash sehen. Ebenso wird in nicht all zu ferner Zukunft der Flash Player auch via Gamepad bedienbar sein. Auch bei der „high class Videowiedergabe“ wird Flash präsent bleiben. In Sachen einfache animierte Website wird HJC Flash mehr und mehr verdrängen, ebenso werden in Zukunft die allseits beliebten Flash Werbebanner auf HJC wechseln.

 

11 ) Apps – das bessere Internet

Da sich das Web gerade bei den mobilen Geräten wieder mehr zu einer klassischen Informationsplattform hin entwickelt, stellt sich die Frage wie man dem User die höhere User Experience zur Verfügung stellen kann. Die Hemmschwelle auf einem mobilen Gerät eine Anwendung zu installieren, ist recht gering, auch die Installation selber, als Prozess, gestaltet sich auf mobilen Geräten recht einfach im Gegensatz zu bisherigen Installationen auf Desktop-Systemen.

Es wird nun vermehrt die These vertreten, dass dem User via der App der eigentlich reichhaltige mediale Inhalt entgegen gebracht werden sollte / kann. Im Grunde ist die App als erweitertes Internet zu verstehen, wo dem User aber erst zumindest aus Kommunikationssicht vermittelt werden muss, dass ihm die App einen Mehrwert bietet.

Parallel hat die App den Vorteil, dass ein stärkerer User-Kontakt geknüpft wird, da er so „ein bleibendes App Icon“ auf dem Desktop hat. Des Weiteren ist die Möglichkeit für den Entwickler und den Content-Provider gezielt auf das mobile Gerät hin zu optimieren immens groß. Der Inhalt der vormals im Netz via Flash Player für alle Plattformen halb gebacken war, da meist nur für den Desktop-PC optimiert, kann mit einer App nun gezielt für die jeweilige Plattform aufbereitet und optimiert werden und führt so hoffentlich zu einem besseren Eindruck bei dem User.

Aus dieser Sicht betrachtet, ist es sehr zu begrüßen, dass Adobe sich strategisch dafür entschieden hat die Entwickler innerhalb des Webbereichs vom Flash Player Mobile ab zu ziehen und unter anderem mehr in Ressourcen für die Weiterentwicklung der Adobe Integrated Runtime (AIR) zur Verfügung zu stellen.

Mit Hilfe von AIR ist es möglich Anwendungen für verschiedene Plattformen wie Windows, Mac, iOS, Android, QNX und SmartTVs zu schreiben. Je nach Plattform kann ein und der selbe Code ohne Probleme für die unterschiedlichen Plattformen verwendet werden, es sind nur noch Detailoptimierungen notwendig. So haben wir mit Hilfe dieser Basis schon verschiedene Flash Magazine gebaut, die als Flash Variante im Web bereit stehen, aber in identischer Form auch für Android Tabletts und die iPads bereit gestellt werden konnten.

Adobe selber vertraut auf diese Plattform, so dass die verschiedenen Touch Apps wie Photoshop Touch, Collage, Debut, Ideas, Kuler und Porto, die Adobe nach und nach in die Creative Suite CS6 integriert, auf AIR basieren.

 

12 ) Empfehlungen für Entwickler

Im Rahmen des Hypes um HTML5 liegt es nahe jedem Flash-Entwickler zu empfehlen sich ausführlich mit den möglichen Szenarien auseinander zusetzen. Generell sollte keine ablehnende Stellung gegenüber HJC eingenommen werden. Man sollte sich aber zugleich vor Augen führen, dass HJC in der Entwicklung dem Stand von AS2 (ActionScript 2.0) entspricht.

Adobe plant laut der Roadmap im 2. Quartal nächsten Jahres den Flash Player 12 zu veröffentlichen. Es soll in Zukunft alle 2-3 Monate eine Version x.x erscheinen, daher erscheint im nächsten Schritt 11.2 und AIR 3.2.

Circa im Mai nächsten Jahres soll die Creative Suite 6 erscheinen. In dieser ist eine komplett aktualisierte Flash IDE enthalten, deren wichtigste Neuerung ist, dass nun mit jedem beliebigen Flash Player im Browser debuggt werden kann. Somit verliert der Interne Flash Player der IDE an Bedeutung, bzw. wird man durch diesen nicht mehr in der Entwicklung eingeschränkt. Ebenso wird mit der CS6 Edge als offizielles Produkt eingeführt. Die Flash IDE erhält einen direkten HTML5 Export, der nahtlos mit Edge in Kombination laufen wird. Man sollte aber von diesem Crosscompiling nicht eine 100%-ige Lösung erwarten. Flash erhält weiterhin verschiedene Erweiterungen, die es ermöglichen werden, Spritesheets für die schnelle Animationserstellung in HTML5 aus Timeline-Animationen zu generieren.

Ab Flash Player 12 wird eine Flashseitige Implementation der von Javascript bekannten Webworker Schnittstelle verfügbar sein. Spätestens mit dem 12er Release, gehe ich von einer kompletten Integration von Stage3D auf den mobilen Plattformen in AIR aus.

Kleiner Hinweis zum Thema Flex: wie nun bekannt wurde, wird Flex wie PhoneGap als Opensource erklärt. Adobe will nach ersten Plänen Flex ab Version 4.6 unter die Apache Lizenz stellen, sowie das komplette interne Entwicklungsteam von Flex abziehen, Flex soll von da an von der Community weiterentwickelt werden. Adobe will sich ab diesem Punkt nur noch auf den Support der Community fokussieren.

Wer sich für die Anwendungsentwicklung via AIR für die mobilen Plattformen interessiert, sollte zuerst prüfen, ob er über eine gut ausgeprägte Kenntnis von AS3 verfügt, ein „Ich kann AS2 sehr gut, aber hab mich bisher nur mäßig mit AS3 angefreundet“ wird hier nicht ausreichen. Man sollte Speicherorientiert arbeiten, sich intensiv mit dem GarbageCollector beschäftigen, sowie über die Möglichkeiten schnell ungenutzten Speicher frei zu geben. Kenntnisse in der Androide Entwicklung und / oder Objektive c sind von Vorteil, gerade im Hinblick auf die Erweiterungen von AIR via den Native Extensions. Für die Entwicklung von AIR für iOS ist es generell notwendig über einen Mac zu verfügen, da nur via XCode ein korrektes Debugging möglich ist, bzw. nur so wichtige Konsolen-Ausgaben zur Verfügung stehen, die ein frühzeitiges Erkennen von Speicherproblemen ermöglichen.

Generell gilt, dass die Geräte-Simulatoren, zwar für einen Basistest von Code ausreichend sind, jedoch die Entwicklung definitiv mit einem echten Testgerät erfolgen muss.

 

13 ) Schlusswort

Hingegen dem aktuell verbreiteten Medienhype rund um den mobilen Flash Player ist noch lange nicht von einem Tod des Flash Players auszugehen. Der Schritt die mobile Variante nicht mehr weiter zu entwickeln ist korrekt, er steht aber trotz allem weiterhin für die aktuellen Plattformen wie gehabt zur Verfügung. In Zukunft gilt es aber genauer zu prüfen, was mit welcher Technik gebaut wird. Dies erfordert eine klar Kommunikation dem Kunden gegenüber und setzt eine umfangreiche Bedarfsanalyse sowie eine direkte Auseinandersetzung mit dem Inhalt der produziert werden soll, voraus.

Es werden sich in den nächsten Monaten keine gravierenden Änderungen zeigen, aber es muss klar und offensiv kommuniziert werden. Es ist an dieser Stelle aus meiner Sicht sehr schade zu hören, dass im Moment einige Projekte gestoppt werden, da sich die Entscheidungsträger in den Unternehmen stark verunsichert fühlen.

Ein blindes Vertrauen in das angebliche Allheilmittel HTML5 ist aber nicht förderlich, ich verweise an dieser Stelle auf die starken Probleme bei der Produktion von HTML Magazinen für das iPad, hier ist mit geringen Speicher und stellenweise dadurch bedingte Probleme bei der Performance zu kämpfen, was sich meist mit nativen Anwendungen spielend leicht beheben lässt.

 

Quellen zum Weiterlesen:

Mike Chambers (Flash Platform):
http://www.mikechambers.com/blog/2011/11/11/clarifications-on-flash-player-for-mobile-browsers-the-flash-platform-and-the-future-of-flash/

Cantrell (generell):
http://blogs.adobe.com/cantrell/archives/2011/11/my-thoughts-on-flash-and-html-as-expressed-in-an-email-to-tech-news-today.html

Deepa Subramaniam (Flex)
http://blogs.adobe.com/flex/2011/11/your-questions-about-flex.html

Gunnar Klauberg ( Überblick der Änderungen – Offizielle Adobe Solutions Blog Deutschland)
http://blog.adobe-solutions.de/adobe-flash/gamification-erobert-unternehmen-und-flash-ist-noch-lange-nicht-tot/

LG Smart TV goes on the charm offensive, appeals to Adobe developers
http://www.engadget.com/2011/10/04/lg-smart-tv-goes-on-the-charm-offensive-appeals-to-adobe-de/


Jul 26 2011

Adobe Flash – bug or feature – No multitouch gestures on android

Tag: Actionscript,Adobe,Adobe Flash - bug or feature,AllgemeinKonstantin Elstner @ 00:09

After I wrote in one of my last posts about the missing stageVideo on Android devices. Today I want to write about another missing feature.

A very nice „gimmick“ of android is the multitouch feature, swipe to left or right to go to another „site“, swipe down to scroll and so on. Adobe write in there actionscript 3.0 api documents, that this feature would be available to all multitouch devices with one exception, the mac os trackpad is not supported:

Note: The Multitouch feature is not supported for SWF files embedded in HTML running on Mac OS.

(source: http://help.adobe.com/en_US/FlashPlatform/beta/reference/actionscript/3/flash/ui/Multitouch.html)

 

These days we were working on a flash magazine, which we also optimized  for use with tablets. Our client, for whom we has produced successfully an Android AIR magazine demo, asked us if we could integrate swipe gestures for left and right to switch the sites. I said to him, maybe it is possible, I would check it out and call him back. So I adapted our magazine to test the support of multitouch.

The first thing we struggled over is the fact, that Adobe may thought, when developing Flash CS5.5, that there would be no differences between the Flash Player 10.0 and Flash Player 10.1. Very interesting I think 😉

If you are going to try code like this in Flash Player 10.0:

1
2
3
import flash.ui.Multitouch;
[...]
Multitouch.inputMode = MultitouchInputMode.GESTURE
import flash.ui.Multitouch;
[...]
Multitouch.inputMode = MultitouchInputMode.GESTURE

Flash will publish your swf without any problems. But if a user with a flash player > 9.x and < 10.1, the flash player will hang without any visible error to the user.

With hang I mean, totally hang, after excuting this lines of code the complete SWF file will stop working. If you try this code with a 10.0 debugger player you get a General Error, and afterwards the code excution stops. So be sure, that this SWF will be only delivered for users with flash palyer 10.1 or greater.

This problem occurs for all multiouch related events and gestures!

A workarround is very simple implemented … simply check with an if-condition which version of the flash player the user has:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// this function will return true if the flash player version is 10.1 or greater
function get multitouchSupported():Boolean {
var vAr:Array = Capabilities.version.split(",");
 
if( Number( vAr[0].split(" ")[1] ) < 10 ) {
return false;
} else if( Number( vAr[0].split(" ")[1] ) > 10 ) {
return true;
}
 
if( Number( vAr[1] ) > 0 ) {
return true;
}
 
return false;
}
// this function will return true if the flash player version is 10.1 or greater
function get multitouchSupported():Boolean {
var vAr:Array = Capabilities.version.split(",");

if( Number( vAr[0].split(" ")[1] ) < 10 ) {
return false;
} else if( Number( vAr[0].split(" ")[1] ) > 10 ) {
return true;
}

if( Number( vAr[1] ) > 0 ) {
return true;
}

return false;
}

or check which CPU the device has:

1
2
3
if( Capabilities.cpuArchitecture == "arm" ) {
// code to excute
}
if( Capabilities.cpuArchitecture == "arm" ) {
// code to excute
}

 

The second thing I deiscovered for my self, is that it seems, like it is impossible to use multitouch events like the TransformGesture or the general MultiTouch-Actions if your app is running in a browser on an Android device. On my test devices, a Samsung Galxy I9000 (Android 2.3.3) and a Samsung Galaxy Tab 10.1v, there was no multitouch support in the browser. I tested the support with this simple lines of code:

1
2
3
4
5
if( Multitouch.supportedGestures == null || Multitouch.supportedGestures.length == 0 ) {
trace( "no multitouch support");
} else {
trace( "multitouch available");
}
if( Multitouch.supportedGestures == null || Multitouch.supportedGestures.length == 0 ) {
trace( "no multitouch support");
} else {
trace( "multitouch available");
}

The same code traces „multitouch available“ if the code is running as a AIR app on this devices.

I hope, that this will be changed in a feature release of the flash player.

 

In short:

– Take care, that code like the following is only excuted in a flash payler greater or equal to 10.1, otherwise the SWF will stop working

1
2
3
import flash.ui.Multitouch;
[...]
Multitouch.inputMode = MultitouchInputMode.GESTURE
import flash.ui.Multitouch;
[...]
Multitouch.inputMode = MultitouchInputMode.GESTURE

– On Android devices there is at this time no multitouch support available in the browser


Jul 07 2011

Renewing an Adobe AIR Developer Certificate

Tag: Actionscript,Adobe,FlexKonstantin Elstner @ 18:10

If you are glad to support an Adober AIR application with a lifespan of a few years there will came the time point where you have to update developer certificate, because their lifespan is over. It is very important, that you get all necessary information about this step. Also it is important that you mark this date in your calendar. If you don’t want to become in trouble at the moment of update.

If you do not plan this point exactly maybe all your clients or the customers of your client has to manually install this new update, because the auto update will not work.

Maybe Adobe did not believe, that an AIR application would be used over years, otherwise the update process would be even better.

In the first months or years of Adobe AIR it was nearly impossible to change to a new certificate, because if you switched your certificate AIR would not trust your application. So the update process fails and there would come an error code like „Error# 16816“ during the installation.

The background is that with every renew of your certificate your publisher ID (after AIR 1.5 deprecated) is changing, but the shown name of the developer is the same.

Since AIR 1.5 Adobe provides a „solution“, with the „adt“ command line tool you can sign your application with the old certificate after signing it during packaging with the new certificate. Adobe calls this „migration„. It is important to know, that this migration is only possible during the first 6 months, after the lifespan of the old certificate is over. If you have to provide an update after this 6 months, you can not do a „migration signing“ of your app and so Adobe AIR will not allow the user an update of your app. The only way would be an uninstall and afterwards a new install of your app.

Example of the migration commands on mac os:

/Applications/Adobe\ Flash\ Builder\ 4.5/sdks/4.5.1/bin/adt -migrate -storetype pkcs12 -keystore /Users/USER_NAME/PATH_TO_OLD_CERTIFICATE/xxx.p12 /YOUR_APP_FILE.air /YOUR_MIGRATED_APP_FILE_NAME.air

 

In short:

  • mark the date when your certificate expires in your calendar
  • get your certificate as early as possible
  • provide an update immediately after you got the new certificate

More informations about available adt commands:
http://help.adobe.com/en_US/air/build/WS901d38e593cd1bac1e63e3d128fc240122-7ffd.html
http://help.adobe.com/en_US/air/build/WS5b3ccc516d4fbf351e63e3d118666ade46-7f72.html
http://livedocs.adobe.com/flex/3/html/index.html?content=CommandLineTools_5.html


Jul 06 2011

Adobe – bug or feature: No stageVideo on Android 3.0.1 & 3.1?

Tag: Actionscript,Adobe,Adobe Flash - bug or featureKonstantin Elstner @ 21:20

Today I experimented with the new stageVideo, which is available since Flash Player 10.2. It is a very nice technique, where the video is rendered through a pipe by the gpu. So the cpu consumption is quite 10 to 20 percent playing a full HD video instead of 50 percent or more. Even it reduces the energy consumption.
On a mobile chip-set like the Tegra from Nvidia the video playback should be very smooth in theory.
Adobe has announced this technique at the Adobe Max last year. In January Adobe said it would be available with Android 3.0.
So I thought it would be the right time to check it out now on my Galaxy Tab 10.1v.

But surprise:
No stageVideo is available in Flash Player 10.3 on Android 3.0.1.
No stageVideo is available in Adobe AIR 2.6 on Android 3.0.1.
And last but not least no support of stageVideo in Adobe AIR 2.7 on IOS.

What happened?

Adobe has quite updated the release informations for stageVideo.

At this developer FAQ (modified 28 March 2011):
http://www.adobe.com/devnet/devices/articles/optimization_features_fp101.html

And at this site too (modified 4 April 2011):
http://www.adobe.com/devnet/devices/articles/mobile_video_encoding.html

Adobe informs, that stageVideo would be available with Android 3.0.1 …

But at this shortly updated main site (tab mobile features):
http://www.adobe.com/products/flashplayer/features/
Adobe told us, that the stageVideo would be not available until Android 3.1.

Hardware-accelerated video presentation (requires Android 3.1)

Enjoy beautiful, smooth playback of high-definition H.264 video content powered by Adobe® Flash® technology across the web in both embedded and full-screen mode using Android™ tablets with Android 3.1, like the Motorola XOOM. Adobe Flash Player leverages the Stage Video hardware-accelerated video pipeline to provide higher frame rates and less power consumption, building on the efficiency of hardware-accelerated H.264 decoding.

Note: Hardware-accelerated video presentation support will only be available with Android 3.1 and is not supported on earlier versions of Android.

I like the note *irony*.

What a pity and what a great way of communication.

Thanks Adobe.

I hope stageVideo will be truly supported on Android 3.1. At this time I can not test it, because I have no Android 3.1. Playing a h264 video with cpu based rendering is quite a pain.

And by the way: should not Flash Player 11 released in mid 2011?

 

[Update]

Today I updated my Galaxy Tab 10.1v to Android 3.1 with Flash Player 10.3.185.25 … also no stageVideo support. Can somebody confirm this with other devices?

Testlink is:
http://d-ssl.de/svTest/

Player is based on OSMF 1.6.

Code to check stageVideo support:

try {
console.appendText( „availabe stageVideo pipes: „+stage[’stageVideos‘].length+“\n“ );
} catch(e:Error) {
return;
}
for( var i:int; i < stage[’stageVideos‘].length; i++ ) {
if( stage[’stageVideos‘][i].videoWidth > 0 ) {
console.appendText( „pipe „+i+“: video size: „+stage[’stageVideos‘][i].videoWidth+“x“+stage[’stageVideos‘][i].videoHeight+“\n“ );
}
}


Jul 06 2011

Beware of Flash Builder 4.5 and Flex SDK 4.5

Tag: Actionscript,Adobe,FlexKonstantin Elstner @ 08:56

A few weeks ago I did the mistake (?) and upgraded to Flash Builder 4.5. At first to say, the product is nice, but the Eclipse bugs are niggling. But a thing I can do not understand is:

Why Flash Builder 4.5 only supports the Flex SDK 4.5?

For myself as a developer who has some long time projects, this is a frustrating point. If you are working on a big project you can not simply switch to a new SDK, ony why Adobe think it is great. You have to make some pretests to be sure that is working very fine.

Believing in Adobe, which is sometimes the biggest mistake what I can do, I simply upgraded a bigger business project to the 4.5 Flex SDK.

First I was struggling about some changes in the AIR descriptor file. Updating the name space is a simple part, but finding out why it has problems with the version-tag takes some time. Afterwards I was smarter and did know, that with AIR 2.6 the version-tag was changed to „versionNumber“. Really ease to change, but beware of the things behind:

The changing from version to versionNumber is not a simple wording change, it is the evolution to the knew AIR 2.6 update process. A thing, which I did not found at the release notes.

For this new update process you have to update your complete update-implementation, and this is a 2-steps-process, because at first you have to provide an small update, which make it possible for your application to use this new update process. After this step it is possible for you to provide application updates, which are based on Flex 4.5. If a user is not using the app for a long time, they will get two updates short behind.

I think for myself Adobe should make a better communication of ugly problems like this. In the tech-notes, the Adobe technicals for there self wrote, that this process is not simple.

 

http://kb2.adobe.com/cps/873/cpsid_87300.html


Dez 08 2010

Actionscript – Zeichenabstände bei dynamischen Textfeldern beibehalten

Tag: Actionscript,AdobeKonstantin Elstner @ 15:41

Bei einem letzten Projekt mussten wir mit statischen Textfeldern arbeiten und haben dabei einige interessante Tweaks kennen gelernt.

An dieser Stelle ein Trick bezüglich dynamischer Textfelder, die in der IDE erstellt wurden und später mit Inhalten befüllt werden. Etliche User berichten, dass in diesem Fall die Einstellungen für den Zeichenabstand (manchmal) und den Zeilenabstand (immer) verloren gehen, dies lässt sich sowohl in Actionscript 2.0 wie auch 3.0 wie folgt umgehen:


import flash.text.TextField;

import flash.text.TextFormat;

var tf:TextField = this.textfeldInstanz;
var txtFormat:TextFormat = tf.getTextFormat();

tf.text = „Lorem ipsum et minim causae persequeris sit, ea diam habemus nam. Ad pri laudem epicuri“;

tf.setTextFormat( txtFormat );

Der Trick besteht darin – das Textformat vor dem Setzen des neuen Textes auszulesen und nach dem Setzen des neuen Textes wieder auf das Textfeld anzuwenden. Setzt man einfach nur den neuen Text, so wird das Textformat in den Punkten Zeichen– und Zeilenabstand auf die Standardwerte zurück gesetzt.


Dez 07 2010

Adobes FLVPlayback korrekt stoppen

Tag: Actionscript,AdobeKonstantin Elstner @ 20:23

Wenn man als Actionscript-Entwickler ohne viel Aufwand ein Video einbinden möchte, gibt es aktuell neben Drittanbietern zwei Angebote / Lösungsansätze die direkt von Adobe kommen:

OSMF ist Adobes neues Mediaframework, das mehr oder weniger leistungsstark ist, jedoch setzt dies mindestens den Flash Player 10 voraus, daher ist es leider noch für viele Flashprojekte nicht die erste Wahl.

Daher bleibt für eine „schnelle“ Umsetzung meist nur die FLVPlayback Komponente. Aus persönlicher Erfahrung weiß ich, dass diese freundlich formuliert, so einige unschöne Features hat, bzw. stellenweise mangelhaft ist.

Eines der wohl größten Probleme ist das Szenario, dass der User ein Popup mit einem Video öffnet, der Player startet, aber bevor der Player die eigentliche Wiedergabe visuell startet, schließt der User schon das Popup. Nun beginnt aber plötzlich im Hintergrund der Sound des Videos zu laufen.

In der Regel würde man den Player versuchen wie folgt zu stoppen:

playerInstanz.stop();

Dies greift aber noch nicht, wenn der hinter dem Video stehende Netstream / VideoPlayer sich noch versucht zu verbinden, dies passiert häufig bei größeren progressiven Filmdownloads.

Adobe hat es leider nicht für notwendig gehalten eine destroyMethode bei zu packen.  Beim internen Handling eines Videos verfährt die Adobe FLVPlayback Komponente wie folgt:

  • VideoURL wird gesetzt
  • Ein Netstream / VideoPlayer-Objekt wird erstellt, dem Event-Listener für alle verschiedenen Events wie Complete, Connect, IOError etc. hinzugefügt werden
  • Das Netstream / VideoPlayer-Objekt wird dem internen Array „videoPlayers“ hinzugefügt
  • Erst bei Connect- oder einem Error-Event ist das Netstream / VideoPlayer-Objekt durch die public Methoden der FLVPlayback Komponente steuerbar

… daher wird die FLVPlayback Komponente vor dem Connect-Event über die public Methoden angesteuert, so laufen diese Befehle ins Leere. Setzt man die FLVPlayback Komponente gar auf NULL, so verbleibt der laufende Stream als verweislose Instanz im Speicher bis der Garbage Collector diese bereinigt. Bis dahin ist jedoch der Sound des Videos hörbar und der Netstream / VideoPlayer nicht mehr kontrollier- oder stoppbar.

Bryan Grezeszak war so freundlich und hat sich dieses Problems mit seiner Klasse FLVPlaybackUtils angenommen.

FLVPlaybackUtils verfügt über eine public Methode:

  • reset(vid: FLVPlayback) – Stoppt alle laufenden Videos der FLVPlayback Komponente und resettet diese, sodass nur noch ein „frischer“ interner Netstream / VideoPlayer vorhanden ist

Endlich keine verbleibenden Videogeister mehr!

Enjoy


Mai 07 2010

Adobe Flash CS5 ein kurzes Review

Tag: AdobeKonstantin Elstner @ 17:57

Ich fasse mal die für mich wichtigsten Verbesserungen zusammen, aus der Sicht eines Mac Users nach einer Woche Produktiveinsatz, wobei ich noch nicht komplett alles getestet habe.

Die besten neuen Features:
– Das Text Layout Framework
– Crosslinking zum Flash Builder (bei Editierung / Öffnen von Klassen fragt Flash ob diese im Flash Builder editiert werden sollen)
– Codehints und Autocomplete auch für externe Klassen (Must Have)
– Direkte Bearbeitung von Bildern aus der Bibliothek in Photoshop und Speichern direkt in die Datei

– XLF Dateiformat – perfekt für die Versionierung
– Zentrale Verwaltung der eingebetteten Schriftarten (Menü Text > Schrift Einbettung)

Performance & Stabilität:
– Ich habe in dieser Woche kein einziges mal erlebt, dass die Flash IDE abgestürzt ist, kann mir daher ständiges Speichern wieder abgewöhnen
– Die Flash IDE wurde deutlich in Sachen CPU-Last überarbeitet, früher hat Flash mit ein paar offenen Dateien schnell mal im Hintergrund eine CPU-Last von 20-30% gehabt, jetzt zw. 5 und 10%

Das schlechteste neue Feature:
– Community Help Center als Ersatz der klassischen Hilfe – bisher absolut schrecklich

Fazit:
Adobe Flash CS4 hatte einige Neuerungen im Gepäck, war dafür auf Mac und Windows CPU hungrig und instabil.
Flash CS5 hingegen läuft ruhig und stabil. Viele kleine Änderungen (Photoshoplinking, Flash Builder Crosslinking) erleichtern die Workflows und bringen eindeutig mehr Erleichterungen im Alltag. Ein meiner Meinung nach ‚Must Have‘.

[Update]

– 1 Absturz in 3 Wochen Nutzung

weitere geniale Neuerungen:

  • endlich Aktualisierung der Schriften ohne Neustart
  • Anzeige der Größe der Datei-SWF-Größe im Eigenschaftenfenster (traumhaft wenn es auf die KBs angkommt)

Mrz 19 2010

LocalConnection’s Domain übergreifend

Tag: AdobeKonstantin Elstner @ 10:21

Vor zwei Tagen stolperte ein befreundeter Flashentwickler über das Problem der LocalConnection über mehre Domains hinweg in Actionscript 2.0. Er bekam die Verbindnung einfach nicht zum laufen.

Wie ich nun mal bin, fand ich das Problem gleich sehr interessant und testete auch gleich ausführlich.

Wir setzten den Dokumentationen entsprechend zum Test:

System.security.allowDomain(„*“);

Auch gab es im Internet die Angaben, dass auf allen Servern die crossdomain.xml notwendig wäre, was sich aber als Unsinn heraus stellte.

Nach kurzer Zeit fand ich dann jedoch in den Dokumentationen von Adobe den eigentlich wichtigen Punkt, der meiner Meinung nach in der Actionscript 3.0 Dokumtation beiweitem übersichtlicher dargestellt ist:

Different domains with predictable domain names. When two SWF files from different domains communicate, you need to allow communication between the two domains by calling the allowDomain() method. You also need to qualify the connection name in the send() method with the receiving LocalConnection object’s domain name:

// receivingLC is in http://www.domain.com/receiving.swf
receivingLC.allowDomain(‚www.anotherdomain.com‘);
receivingLC.connect(‚myConnection‘);

// sendingLC is in http://www.anotherdomain.com/sending.swf
sendingLC.send(‚www.domain.com:myConnection‘, ‚myMethod‘);

Different domains with unpredictable domain names. Sometimes, you might want to make the file with the receiving LocalConnection object more portable between domains. To avoid specifying the domain name in the send() method, but to indicate that the receiving and sending LocalConnection objects are not in the same domain, precede the connection name with an underscore (_), in both the connect() and send() calls. To allow communication between the two domains, call the allowDomain() method and pass the domains from which you want to allow LocalConnection calls.

Flash speichert lokale Daten in jeweiligen ‚Ordnern‘ pro Domain, dies gilt für LocalSharedObjects und LocalConnections. So ist sichergestellt, dass sich Daten von verschiedenen Domains nicht gegenseitig überschreiben können, bzw. das ein Actionscript nicht Zugriff auf Daten anderer Domains erhält.

Wird nun eine LocalConnection erstellt, so wird der LocalConnection ein Prefix bestehend aus der Domain voran gestellt zB. wird ‚myConnection‘ zu ‚www.domain.com:myConnection‘ gewandelt, selbiges gilt auch für Actionscript 2.0.

Will man diesen Automatismus umgehen weil man zB. nicht weiß wie die unterschiedlichen Domains auf dem Zielserver heißen werden, so muss man den Namen der LocalConnection einen Unterstrich voranstellen, daher ‚_myConnection‘, mit diesem Unterstrich weißt man den Flash Player an die LocalConnection als globale LocalConnection zu handeln. Der Flash Player fügt in diesem Fall nicht die Domain als Prefix hinzu. Zusätzlich muss aber auch allowDomain für die LocalConnection gesetzt werden:

myLC.allowDomain(‚*‘);

Hinweis

Die Domain die als Prefix verwendet wird ist nicht die des Servers auf dem die SWF eingebettet wurde, sondern die Domain des Servers der die SWF hostet.

Sicherheitshinweis:

An dieser Stelle sei an zumerken, dass mit allowDomain mit einer Wildcard (‚*‘)  immer mit Vorsicht gearbeitet werden sollte und die übergebenen Daten exakt geprüft werden sollten. Denn hier besteht die Gefahr von Sicherheitslücken, da über eine LocalConnection auch binäre Daten gehandelt werden können. So wäre ein Szenario denkbar, in dem ein Hacker, gezielt SWF’s auf LocalConnecntions prüft, diese dekompiliert, sich die Schnittstellen und Übergabewerte anschaut und so bald er einen Schwachpunkt findet versucht diesem Clip per LocalConnection manipulierte Daten unterzuschieben.

SWFBridge: Easier AS3 to AS2 Communication

Grant Skinner war so freundlich und hat uns Flashentwicklern ein kleines Geschenk gemacht, er hat die Class SWFBridge zur Verfügung gestellt, mit der sich in Knapp 4 Zeilen Code LocalConnections erstellen lassen, auch zwischen Actionscript 2.0 und 3.0 SWF’s. Kein nerviges Testen mehr ob die Synchronität klappt und ewiges Loopen … ein echtes must have:

http://www.gskinner.com/blog/archives/2007/07/swfbridge_easie.html


Nächste Seite »