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

10.1

We found that your app does not comply with the Apple iOS Human Interface Guidelines, as required by the App Store Review Guidelines.

Specifically, we noticed your app only supported the top-right variant of the landscape orientation, but not the top-left variant.

While supporting both variants of both orientations, each with unique launch images, provides the best user experience and is recommended, we understand there are certain applications that must run in the landscape orientation only. In this case, it would be appropriate to support both variants of that orientation in your application, e.g., Home button right and left.

Addressing this issue typically requires only a simple and straightforward code modification. However, if you require assistance, theApple Developer Support Team is available to provide code-level assistance.

For more information, please review the Aim to Support All Orientations section of the iOS Human Interface Guidelines.

In our app settings we disabled “automatic rotation”, so the app was only supporting the landscape “top-right” mode. This was not a problem for Apple before iOS 5, but now apps with this settings are rejected.

I think Apple is right with this decision, but also I think, Adobe should support this out of the box. Maybe in a better world, it would be so

The solution for this problem is really simple:

import flash.events.StageOrientationEvent;
import flash.display.StageOrientation;

// enable autoRotation
stage.autoOrients = true;

// add the rotation event listener
stage.addEventListener(StageOrientationEvent.ORIENTATION_CHANGING, orientationChangingHandler);

// listener function
protected function orientationChangingHandler(e:StageOrientationEvent):void {
	// with e.afterOrientation you can get which orientation the screen would have after the rotation
	switch( e.afterOrientation )
	{
		// we want to prevent portrait modes so we stop the events
		case StageOrientation.DEFAULT:
		case StageOrientation.UPSIDE_DOWN:
			e.preventDefault();
			break;
		}
	}
}

This code will prevent that the application enters the portrait mode, if the future rotation is a portrait mode the event is stopped with e.preventDefault().

It is a good practice to set the initial autoOrients value to false in the publishing settings, otherwise the launch image will be rotated and you can not control it.

At this point, it is important that you do not try this code with an application which is compiled with the AIR 3.0 SDK, because, the adt compiler seems to be broken for the stage events.
If you try this code with AIR 3.0 it could be possible, that the StageOrientationEvent is never dispatched, so there seems to be a bug.

It will be working correct when you use the AIR 3.1 SDK.

It took same hours and hairs to find this annoying bug out -.-

“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/

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

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

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” );
}
}

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

Fragt man eine iPad-Entwicklung an, so muss man sich teilweise auf längere Wartezeiten von bis zu einem halben Jahr einstellen bis die Entwicklung überhaupt beginnen kann. Da der durch Apple indirekt klein gehaltene Entwicklerkreis stark gefragt ist. Die Einschränkung des Entwicklerkreises erfolgt mehr oder weniger direkt durch die von Apple vorgegebenen Entwicklerwerkzeuge. Zeitweise wurden auch “Cross-Plattform-Entwicklungstools” wie Unity3D, der Adobe iPhone Packager oder andere Tools verboten, später aber wieder zugelassen. Jedoch bleibt hier die Angst der Entwickler, dass auf diesem Wege entwickelte Programme im nächsten Quartal wieder gesperrt werden könnten. Dies schlägt sich neben den Wartezeiten auf freie Entwickler auch in den Tagessätzen nieder.

Doch steht man vor der Frage, ob man eine iPad-Anwendung in Auftrag geben will oder sollte, so ist der Eindruck, dass dies schon fast Pflicht sei, um den Anschluss nicht zu verlieren. Unter diesen Umständen sollte man aber auch hinterfragen wer denn eigentlich so alles ein iPad hat. In meinem Freundes- und Bekanntenkreis komme ich auf knapp 4 iPad-Besitzer die mir bekannt sind, wovon exakt eine Person dieses zu rein privaten Zwecken nutzt und der Rest aus dem Entwicklerumfeld kommt, daher aus meiner Sicht nicht “vollwertig” zählbar ist, da hier das Interesse aus beruflichen Gründen extrem gesteigert ist.

Wichtig ist bei der Betrachtung beziehungsweise bei der Überlegung der Entwicklung einer  ”iPad-App”, dass diese bei einer Produktion für das iPad auch nur auf diesem vollwertig nutzbar ist. Weitere Apple-Produkte wie das iPhone, AppleTV und die iPods, die auch auf iOS basieren, sind in der Regel auf Grund ihrer Displaygröße und der Geräteleistung kaum für die Nutzung der iPad-App geeignet.

Als Entwickler oder als Kunde, der einen iPad-Einstieg plant, sollte man seine Entscheidung dafür oder dagegen nach “vernünftigen” ökonomischen Gesichtspunkten fällen, bzw. rein rational. Da sich kaum noch jemand des durch Apple kommunizierten Hypes entziehen kann, ist es wichtig rein rationale Fakten offen zu legen und auf die Verkaufszahlen zu schauen. Diese werden nach meiner Meinung leider viel zu wenig kommuniziert. Apple selbst hält sich sehr bedeckt bei der Veröffentlichung solcher Zahlen, wenn es sich nicht gerade um den Quartalsbericht, der Pflicht ist, handelt, oder um einen brillanten Verkaufsstart.

Definition der Zielgruppe

Laut Statista(1) ist die Kernzielgruppe des iPads wie folgt zu definieren:

Geschlecht
Rund zwei Drittel der iPad-Nutzer sind männlich.

Alter
Das iPad spricht Interessierte altersübergreifend bis 60 Jahre an.

Einkommen
Das iPad ist sehr beliebt bei Besserverdienern, sie stellen aber nicht die größte Zielgruppe dar.

Medienausgaben
iPad-Nutzer geben durchschnittlich 1,5-mal so viel für mediale Inhalte aus wie der durchschnittliche Onliner.

Apple-Besitz
Wer ein iPad kauft, besitzt schon andere Produkte von Apple. T-Mobile-Nutzer sind in der iPhone-Gruppe leicht überrepräsentiert – Grund hierfür ist iPhone.

Hierbei handelt es sich um die Kernzielgruppe. Um jedoch einen regulären Schnitt zu erreichen, muss auch generell der Casual User (Gelegenheitsnutzer) beachtet werden. Da das iPad sich sowohl vom Schüler bis hinauf in die Zielgruppe 60+ eignet, vertrete ich die These, dass für einen verhältnismäßig korrekten Wert zur Ermittlung eines potenziellen Userkreises im Schnitt die Formel Bevölkerung eines Landes * 0,5 angewandt werden kann. Im Hinblick auf die zukünftige “Computernutzung” zeichnet sich ab, dass sich generell Tablets im privaten Bereich als zukünftiges primäres Gerät zum Konsum von Webinhalten und Lean-Forward Medien (interaktive Medien) entwickeln werden.

iPad-Verkaufszahlen 2010

2. Quartal (Verkaufsstart):
3,37 Mio. (2)
(Iphones 8,4 Mio., iPods 9,41 Mio.)

3. Quartal:
4,19 Mio. (3)
(Iphones 14,1Mio., iPods 9,05Mio.)

4. Quartal (inklusive Weihnachtsgeschäft):
7,33 Mio. (4)
(Iphones 16,24 Mio., iPods 19,45 Mio.)

Apple hat somit im Jahr 2010 (seit April) 14,89 Mio. iPads verkauft, parallel wurden 38,74 Mio. iPhones und 37,91 Mio. iPods verkauft.

Aussicht 2011

Laut Digitimes (5) hat Apple für das Jahr 2011 rund 65 Mio. Displays für das iPad 2 bei seinen Zulieferern bestellt. Parallel läuft die Produktion des iPad 1 aus. Es lässt sich daher ableiten, dass Apple von einem Absatz von bis zu 65 Mio. iPads im Jahr 2011 ausgeht. Interessant ist hierbei, dass die Analysten nur von Verkaufszahlen von 21 Mio. (Piper Jaffray’s Gene Munster (5)) bis 45 Mio. (Brian White Analyst bei Ticonderoga Securities (5)) ausgehen. Interessant hierbei ist auch der Blog von Philip Elmer-DeWitt. Da Apple bisher nicht übermäßig falsch lag, halte ich ca. 50 Mio. verkaufte iPads für realistisch.

Verhältnis und Reichweite

Um eine durchschnittliche Reichweite / Verbreitung des iPads zu ermitteln, liste ich im Folgenden die Länder, in denen das iPad erhältlich ist, sowie deren Einwohner laut Wikipedia.org auf:

• Australien – 21,9 Mio
• Belgien – 10,8 Mio.
• Deutschland – 81,8 Mio.
• Frankreich – 65,4 Mio.
• Großbritannien – 61,5 Mio.
• Niederlande – 16,5 Mio.
• Hongkong – 7 Mio.
• Japan – 127,4 Mio.
• Irland – 4,5 Mio.
• Italien – 60,3 Mio.
• Kanada – 34 Mio.
• Luxemburg – 0,5 Mio.
• Mexiko – 112,3 Mio.
• Neuseeland – 4,4 Mio.
• Österreich – 8,4 Mio.
• Schweiz – 7,8 Mio.
• Singapur – 4,7 Mio.
• Spanien – 47 Mio.
• USA – 311 Mio.

In der Summe verfügen die genannten Länder über 987,2 Mio. Einwohner. Multipliziert man die Einwohnerzahl mit dem bei der Zielgruppe genannten Faktor von 0,5 so erhalten wir 493,6 Mio Zielpersonen. Daraus lässt sich ableiten, dass zum 1.1.2011 rund 3% der potenziellen Nutzer über ein iPad verfügten. Sollte Apple im Jahr 2011 wirklich 50 Mio. iPads innerhalb der genannten Länder absetzen, so hätten zum 1.1.2012 64,89 Mio. User ein iPad. Dies wären somit rund 13,15% aller potentiellen Nutzer. Würde man die volle Einwohnerzahl als Basis verwenden, hätte das iPad bei diesen Zahlen 2011 eine Marktdurchdringung von 1,5% und 2012 von 6,58%.

Appstore Bedingungen

Um ein Produkt für das iPad, iPhone oder iPod zu vertreiben, führt kein Weg an dem Appstore von Apple vorbei, nur über diesen darf und kann Software für die genannten Geräte vertrieben und installiert werden. Die einzige andere Alternative wäre ein Jailbreak, der mit einem Hack des Gerätes einher geht. Apple hat hierbei die Funktion eines Gatekeepers und lässt nur Software nach einer ausführlichen Prüfung zu. Zu gleich sichert sich Apple so auch eine Abgabe von 30% des Verkaufspreises der App. Eine solche Prüfung kann zwischen 5 Tagen bis zu 4 Wochen andauern.

Aktuell zieht Apple viel Unmut der Verlage auf sich, da Apple nun vorgegeben hat, dass für ein Zeitungsabo im Appstore Abgaben zu entrichten sind und dieses nicht über den Verlag vertrieben werden darf. Alleine Apple hat das Recht des Abovertriebes und behält alle Abonnentendaten für sich. Eine zielgerichtete Werbung für die Verlage ist so nicht möglich. Ebenso entfällt die Möglichkeit “Printabokunden” eine kostenlose digitale Ausgabe zur Verfügung zu stellen, beziehungsweise wird dies unterbunden (7).

Solche Maßgaben und andere Restriktionen werden mit jeder neuen iOS-Version verändert oder erweitert:

Apple iOS 4.0 (April 2010)
Anwendungen für iOS dürfen nur noch in Objective-C, C, C++ geschrieben werden, die Nutzung von Crosscompilern wird untersagt (8).

Apple iOS 4.3 beta (September 2010)
Eingeschränkte Aufhebung der im April eingeführten Beschränkung:
“[...] Insbesondere lockern wir alle Beschränkungen der Entwicklungswerkzeuge zum Entwickeln von iOS Apps, so lange die dadurch entstehenden Apps keinen Code herunterladen. [...]” (9)

November 2010
Zeitweise Ablehnung von Apps von Radio-Stationen da diese so sinnvoll seien wie eine “Furzapp”. (10)

Januar 2011 Richtlinien für den Mac App Store
“[...] Apple weist darauf hin, dass auch Applikationen abgelehnt werden, wenn sie Funktionen abdecken, für die es bereits viele andere Applikationen im App Store gibt. Abgelehnt werden gegebenenfalls auch Apps, die “nicht sehr nützlich sind” oder nicht auf Dauer unterhaltsam sind. Auch Java ist dabei nicht erlaubt. [...]” (11 & 12)

Neben den genannten Restriktionen kommt es immer wieder zu Ablehnungen aus teilweise nicht rational nachvollziehbaren Gründen. Apple und besonders Steve Jobs fühlen sich als “Eltern” des Appstores und versuchen so den User geradezu zu erziehen. Es wurden schon Apps gesperrt / nicht zugelassen, oder im Nachhinein entfernt, weil sie zu politisch waren, zu viel Haut gezeigt wurde, ein Feature oder die Software eine Funktion besaß, die auch die von Apple installierte Software bot.

Problematisch sind die Lizenzbedingungen auch für Software die aus dem Opensource-Bereich kommen. So musste unter anderem der freie VLC Media Player wieder entfernt werden, da sich die AGB des Appstores nicht mit der GPL-Lizenz des Players vereinen ließen. “[...] Die Unvereinbarkeit von GPL und den Geschäftsbedingungen (AGB) des App Store sei nun gelöst – wenn auch auf dem harten Weg, so Denis-Courmont. [...]” (13).

Es kann daher gut möglich sein, dass eine Anwendung im finalen Stadium doch noch von Apple abgelehnt wird. Zwar ist man bei Apple bemüht mittlerweile zumindest einen Katalog mit Gründen, warum eine App abgelehnt werden kann, aktuell zu halten. Aber es gibt keinen Garant dafür, dass die erstellte Software selbst bei Einhaltung aller Punkte frei gegeben wird. Ebenso müssen auch Updates der Software zur Prüfung eingereicht werden, ein Tipp- oder Grafikfehler lässt sich so nicht eben mal schnell beheben.

Fazit

Ziel dieses Artikels ist es nicht, eine Bewertung des iPads vorzunehmen oder eine Empfehlung auszusprechen. Er soll als Entscheidungshilfe dienen und zugleich eine Basis für weitere Recherchen darstellen. Im Jahr 2011 wird der “große Run” auf die Gerätegruppe der Tablets beginnen. Auf der CES 2011 in Las Vegas wurden verschiedene Android basierende Alternativprodukte gezeigt, die im Laufe dieses Jahres verfügbar sein werden. Samsung erreichte im letzten Jahr mit seinem Galaxy Tab die 1 Mio. Marke. Der Android Marketplace ist frei und ohne Restriktionen durch Google zugänglich. Android-Apps können direkt über eigene Websites zugänglich gemacht werden.

Der App-Store von Apple ist Fluch und Segen in gleichem Maße. Es gibt so einen zentralisierten Vertriebsweg der sehr gut durchdacht ist, dem hingegen wirken die Marketplaces für Android noch recht unprofessionell. Jedoch heißt eine Platzierung im Apple App-Store nicht gleich, dass die Software auch sofort von jedem geladen und installiert wird. Das Eigenmarketing für die Anwendung ist nach wie vor notwendig. Es ist teilweise fast schon fraglich, ob ein Link von der eignen Website zum Apple App-Store nicht gleich den User auch zu anderen Konkurrenzprodukten führen könnte.

Der definitive Gewinner ist Apple im Hinblick auf den App-Store. Ob man selber Erfolg hat, bleibt im eigenen Verantwortungsbereich. Die Goldgräberstimmung – als man noch mit einer Bierglas-App reich werden konnte – ist vorbei, der Markt ist stark gesättigt. Ob sich eine Investition zum aktuellen Zeitpunkt lohnt, oder ob man lieber warten sollte wie sich die Android basierenden Tablets in diesem Jahr positionieren werden, das ist die Frage. Zu empfehlen wäre aus meiner Sicht am ehesten eine “Cross-Over-App”, die beide Systeme bedient.

Sicher ist nur, Apple ist und bleibt der Marktführer bei den iPads.

Quellen

1 ) http://de.statista.com/berichte/199/ipad-wird-in-deutschland-neuen-millionen-markt-schaffen/statista/pq/
2 ) http://www.apple.com/pr/library/2010/07/20results.html
3 ) http://www.apple.com/pr/library/2010/10/18results.html
4 ) http://www.apple.com/pr/library/2011/01/18results.html
5 ) http://www.digitimes.com/news/a20101228PD212.html
6 ) http://blogs.forbes.com/elizabethwoyke/2010/10/06/analyst-sees-45-million-ipads-in-2011-next-gen-ipad-launching-soon/?boxes=Homepagelighttop
7 ) http://www.macmania.at/ipad/gratis-zugang-zeitungsabos-apple-verboten/
8 ) http://www.macnotes.de/2010/04/12/iphone-os-4-0-apple-untersagt-nutzung-von-crosscompilern-auch-von-adobe-flash/
9 ) http://www.apple.com/de/pr/library/2010/09/09statement.html
10 ) http://radiomagonline.com/currents/news/apple_rejects_radio_apps_1122/
11 ) http://www.golem.de/1101/80539.html
12 ) http://www.engadget.com/2010/10/21/apples-mac-app-store-review-guidelines-posted-will-photoshop/
13) http://www.heise.de/newsticker/meldung/VLC-media-player-aus-App-Store-entfernt-1165910.html

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.

• Die FLVPlayback Komponente
• Open Source Media Framework (OSMF)

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 destroy-Methode 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