Apple, Flash – ich bin nicht alleine

Auch andere haben sich mit diesem Thema in den letzten Tagen befasst.

Zum einen gibt es einen Artikel auf TUAW, zum anderen auch einen umfangreichen Blogbeitrag. Gerade letzterer verfolgt ähnlich meinem Beitrag nicht nur die iPad/Flash-Thematik, sondern auch die allgemeine Performance in iPhoneOS als auch Mac OS X. Die herausragendsten Passagen sind sicherlich folgende.

Serlet didn’t name any specific guilty plugins. Just “plugins”. But during the week at WWDC, I confirmed with several sources at Apple who are familiar with the aggregate Crash Reporter data, and they confirmed that “plugins” was a euphemism for “Flash”.

In other words, in Apple’s giant pile of aggregate crash reports — from all app crashes on all Macs from all users who click the button to send these reports to Apple — Flash accounts for more of them than anything else.

Jo. Warum kommt das jetzt jedem so bekannt vor.. :( Ein weiterer Grund: Apple musste auf Adobe warten, bis die sich endlich mal dazu bequemen, eine 64-Bit-Version herauszubringen. Da das ja bekanntlich nicht der Fall ist, Mac OS X aber 64-Bit laufen soll.. musste eine entsprechende Abstraktionsschicht für Browserplugins (also ein eigener Flashprozess..) her. Die Alternativen wären gewesen: Kein 64-Bit-Safari oder gar kein Flash.

It’s a chicken-and-egg problem. Publishers use Flash for web video because Flash is installed on such a high percentage of clients; clients support Flash because so many publishers use Flash for web video. Apple, with the iPhone, is solving the chicken and egg problem. For the first time ever, there is a large and growing audience of demographically desirable users who don’t have Flash installed. If you want to show video to iPhone users, you need to use H.264.

Machtpositionen sind manchmal zu was nützlich.

Und zuletzt spricht er über die Performanceproblematik von Flash/Mac OS X*. Ingesamt doch ein bisschen interessant zu lesen.

* Da geht es um die Sache mit der fehlenden H.264-Unterstützung in Form einer Public API, Flash auf die Mac Hardware zugreifen kann. Während das natürlich unschön ist, erklärt das aber immer noch nicht die beschissenen Laufzeitverhalten. Wenn eine Flash-Anwendung keine (H.264)-Videos und hochauflösenden Bilder hat, warum sind die Performancestats so beschissen?

Apple und die Sache mit Flash [Update]

Nun wissen wir endlich alle, wie der neuste Wurf von Apple heißt: nicht iTablet, kein iSlate sondern iPad. Okay, eigentlich hätte man auch iPod Touch Pro nennen können, den mehr ist es – erstmal – auch nicht. Klar, ein größeres Display und die daraus resultierenden weiteren Möglichkeiten, die die Apps/UI damit bieten, sind es dann schon.

Weiterhin scheint sich Apple aber zu sträuben endlich auch Flash auf ihre mobile devices zu bringen. Während es bei der iPod Touch/iPhone-Palette durchaus verständliche Gründe aus Sicht der Performance und auch der Usability gibt, werden diese Gründe bei iPad natürlich geringer. Warum also sonst?

Performance

Leider haben Flashobjekte immer wieder die Angewohnheit, sowohl CPU- als auch RAM-lastig zu sein. Ob das nun ein Problem vom Flashplugin oder vom zuständigen Entwickler ist, das kann man so natürlich nicht sagen. Dazu kommt, dass Adobe sich nicht imstande sieht, für Nicht-Windows-Systeme eine ordentliche Version es Flashplayers herauszubringen.

Oder um es mal am Beispiel zu nehmen: Es ist definitiv nicht normal, dass ein Flashspiel wie Farmville auf einem iMac Core 2 Duo mit knapp 3Ghz und 4 GB Ram gerne mal 50-150% CPU und das Flash-Plugin alleine (also ohne Browser) über 200 MB beansprucht. Und zwar im “ohne Details”-Modus. Youtube-Videos sind da mit 40% und nicht nennenswertem RAM-Verbrauch gelinde gesagt überschaubar.

Diese Probleme könnten auch auf dem iPad oder iPhone auftreten, ein Umstand, den Apple definitiv vermeiden will. Performance-Killer sind nicht erwünscht (irgendwie auch verständlich).

User Interface (UI)

Flashanwendungen sind immer für eine Interaktion mit einer Maus konzipiert. Wie sollen die mit einem Touchpad harmonisieren? De facto bedeutet das, das eine Reihe von Flashanwendungen nicht “funktionieren”, weil das Plugin keinen richtigen Unterschied zwischen Bewegen und Klicken oder Rechtsklick vermitteln kann bzw. das “Mauszeigerziehen” überhaupt nicht in der Form vorhanden ist. Und iPhone/iPad spezielle Gesten sind komplett unbekannt. Eine große Inkonsistenz – und von Adobe habe ich in der Richtung noch nichts gehört. Das ist auch nicht im Sinne von Apple, die ein konsistentes System anbieten wollen.

Stichwort Konsistenz: Selbst die einzelnen Flashplayer haben alle eine eigene UI und Benutzerführungslogik: Zusammenfassend kann man wohl sagen, dass der Play-Button meistens links ist. Mal darf man zoomen, mal gibt es Vollbild, mal darf man spulen. Manchmal ist der Button rund, mal ist er eckig. Das passt ebenfalls nicht in die konsistente und einfache Welt des iPhones – und iPads.

Nicht zu vergessen sind natürlich noch diese “Hammer-Player-mit-jedem-Schnickschnack-der-möglich-ist”-Flashanwendungen, bei denen definitiv ein Koller vorprogrammiert ist.

Die Alternative, einfach die Funktionen zu reduzieren, ist natürlich eine Sache von Adobe und vom dem Entwickler. Und, nein, nicht wirklich eine Option (die genutzt würde).

Festzuhalten ist also: native App > Web App > Flash App

Flash für alles und nichts

Flash ist eins der meist verbreitesten Internetplugins, und tatsächlich haben viele Seiten ein Flash “versteckt”.

  • Werbung (und danach kräht außer der Werbebranche nun wirklich keiner nach);
  • komplexe Anwendungen (wie etwa auch o.g. Farmville), die wohl als native bzw. Device-optimierte App wesentlich besser geeignet wären;
  • Flashvideoplayer;
  • “Ich-wusste-es-nicht-besser”-Statements.

Letzteres sind Dinge wie Navigationsmenüs oder “Webseitenlogos” in Flash, die in der Regel ein gutes Statement zur Inkompetenz aufweisen. Der Großteil ließe sich mit HTML/CSS/Javascript auch lösen (und ja, das Web bietet auch kostenlose(!) Frameworks für Animationen) – und das zu einem Bruchteil der benutzten Browserperformance. Aber Unkenntnis und das Flash-Buzzword bieten halt leider viel Potenzial für solche Lösungen. Nur einige hoch angesetzten (oder utopisch?) Anforderungen müssten wirklich Flash nutzen; und natürlich nur aus Flash bestehende Anwendungen. Diese Webseitenbetreiber wissen aber auch, dass sie damit eine Reihe von Leuten ausschließen (und sei es nur mangels großem Display). Kann sich jemand wirklich und ernsthaft die ZDF-Mediathek als Flashanwendung vorstellen? Auf dem iPhone? Auf dem iPad? Letzteres vielleicht, aber auch nur wenn die Auflösung mitspielt, denn Flash hat stets eine fixe Größe. Eine native App würde wohl jeder vorziehen, wohl auch zu Recht..

Am Beispiel: Die gesamte Produktpalette von Google wäre sicherlich nicht so erfolgreich, wenn sie Lösungen aus Flash nutzen würde. Man stelle sich das vor, Google Mail oder auch Microsofts Outlook Web als eine große Flashanwendung. Unfassbar, jeder würde den Kopf schütteln.

Als Fazit: Alternativen – und was wohl dahintersteckt

Als eine die Alternative für Flash ist HTML5/CSS3 anzusehen, welches u.a. eine starke Unterstützung für “Anwendungen” im klassischen Sinne anbietet.; beispielsweise Datenbank-API, File-API und natürlich das Video-Tag. Apple ist auf den Zug aufgesprungen, als sie das iPhone (in der ersten Version, wohlgemerkt!) mit dem hauseigenen Browser WebKit ausstatteten. Unterstützt mit der Tatsache, dass sie ein paar Ergänzungen in ihrer MobileSafari im Vergleich zum normalen WebKit machen, besitzen iPod/iPhone/iPad damit einen leistungsstarken Browser. Nicht ohne Grund setzt auch Google in Adroid auf diese Browserengine, wenngleich mit anderer Javascriptengine.

Der Browser selber hat im Gegensatz zu Flashplugins (die quasi ja nur eine Schnittstelle zu einer anderen Anwendung herstellen) den großen Vorteil, dass sein UI durch das Betriebssystem gesteuert wird. Im Gegensatz zum Flash, wo dies jeder Entwickler selber macht.

Flashvideo? Brauchen wir nicht, der HTML5-Videotag macht’s möglich. UI-Effekte wie Transformationen (größer, kleiner, verschieben, Farbwechsel) mit Javascript oder sogar Flash? Brauchen wir nicht, geht mit CSS3. Eine Flashapp zum Speichern von Daten (serverseitig)? Braucht man nicht, geht auch mit HTML5/Javascript. Außerdem gibt es integrierte Offline/Online-Sync-Möglichkeiten.

Für mich sind mögliche Offline-Webanwendungen ein Killerfeature für mobile devices, denn warum soll “Netz nicht verfügbar” immer bedeuten, das ich jetzt machtlos bin?

Um wieder zum Anfang anzuknopfen: Man hatte natürlich gehofft, das Apple ein Flashplugin für das iPad anbietet bzw. es unterstützt. So wie es im Moment aber aussieht, ziehen sie – mehr oder weniger direkt – gegen Adobe in den Krieg und setzen dabei weiterhin komplett auf HTML5 bzw. auf native Apps. Da die Geräte – glücklicherweise – eine gewisse Machtposition im Sektor der online mobile devices besitzen, sind die Anbieter von Diensten auf Alternativlösungen angewiesen, falls sie die doch große (und vor allem: sehr wichtige) Zielgruppe nicht ausgrenzen wollen. Davon können im Ende alle profitieren, wenn die *** proprietäre Flashgeschichte schwindet und stattdessen kleine, Client-performante und offenere Lösungen entstehen.

Übrigens: Auch Google setzt bekanntlich auf HTML5. Nicht nur Google Gears wurde entwicklungsplanmäßig in die Tonne gehauen, sondern auch Neuentwicklungen entstehen alle im Fokus der HTML(5)-Features. Das neue Google Voice (leider ein unschöner US-only-Kandidat) bietet VoIP. Kein Flash, pures HTML/CSS/Javascript.

Und mal ehrlich: Vermisst jemand wirklich das Flashplugin auf dem iPhone? Oder: Nutzt jemand wirklich Flash auf einem anderen Smartphone so intensiv, das es notwendig ist? Wenn ja, für was?

Update, 29. Januar 2010

Tatsächlich gibt es Ansätze, wie man Multitouch und Gesten in Flash umsetzen kann. Denn eine Maus und einen Mauszeiger findet man auf Multitouchgeräten nicht – um Gegenteil: man hat mehrere Pointer. Das bedeutet aber nicht, das vorhandene Flashanwendungen das alle nutzen würde, haha. Zu früh gefreut.

Featurities meets Fallstrick: Die Spring Security 3.0 Konfigurationsodyssey

Mit dem Majorrelease 3.0 wurde dem Modul Spring Security eine Menge von neuen Features angeignet. Spring Security ist die Modulkomposition, welches für das Java Framework Spring quasi die gesamte Authentifizierung, Autorisierung, Legitimierung jedwegiger Art ermöglicht.

Leider wurden mit dem Release 2.x auf 3.0 eine Reihe von API-Changes vollzogen. Zugegeben, die waren auch sicher alle sinnvoll, weil Komponenten wie die Authentifizierung weiter geteilt wurden und man somit wesentlich flexibler ist, neue Anforderungen zu ermöglichen (Baukastenprinzip). Aber die Dokumentation ist – gesamtheitlich betrachtet – irgendwie immer noch mies und oft nicht aktualisiert. Oder man findet im Internet einfach nur (alte) Beispiele.

Die http-Direktive

Im Namespace von Spring Security existiert das Tagelement http, mit welchem man kurze, knappe und verständliche Konfigurationen anlegen kann. Der Vorteil liegt klar auf der Hand: Man muss nicht alle Beans, Listener und Provider anlegen, denn das geschieht automatisch. Tja, wären da nicht ein paar Einschränkungen in der Funktionsvielfalt.

Konkretes Beispiel: Remember Me

Just wurde das Minor-Release 3.0.1 veröffentlicht, und nur wenige Tage später zu erfahren, dass Remember Me kaputt sei. Egal, fahren wir erstmal weiter mit 3.0.0.

Laut Dokumentation ist es am einfachsten, wenn man die Direktive remember-me (Security Namespace) innerhalb der http-Direktive (Security Namespace) verwendet. Ohne irgendeine Angabe wird ein stinknormales, Cookie basiertes Tokenverfahren ohne (echten) privaten Schlüssel verwendet. Reicht für den ersten Einsatz erstmal auf, soll ja erstmal funktionieren.

Fehlermöglichkeit 1a: Man loggt sich ein, und es passiert nichts (kein “RememberMe”-Cookie).
Lösung: Wenn man einen eigenen Auth-Filter einsetzt, muss man diesem auch den RememberMe-Service “setten”. Außerdem muss der SecurityChainFilter (web.xml!) auch auf die login-Seite verweisen. Es dürfen auch keine Filter bei der Konfigurierung von intercepted Urls (speziell hier: login, logout) gemacht werden.

Fehlermöglichkeit 1b: Es passiert noch immer nichts?
Lösung: Vielleicht wurde vergessen, einen Parameternamen für den Request zu setzen. Der Standardname ist ein typischer Springname, der natürlich unschön ist. Und den kann man nicht über die RememberMe-Direktive setzen, also muss man eh einen eigenen Service definieren. Bäm. Referenzierung geht dann zwar noch, aber für mehr ist die RememberMe-Direktive dann nicht mehr zu gebrauchen.

Fehlermöglichkeit 2a: Man besucht die Seite ohne Login, aber mit Cookie – und die Loginseite kommt (Log sagt kein gültiger Auth).
Lösung: Man kann der Log trauen, wenn sie zwar beim Einloggen nun einen Token ablegt (kann man zum Beispiel sehr einfach mit diesem Firefox-Addon inkl. Editor(!) verifizieren), dieses aber beim erneuten Besuchen der Seite (bzw. ohne JSPSESSION-Cookie) nicht verwendet bzw. wird nicht erkannt. Schlussendlich half u.a. das Umbenennen der Userservices-Bean in “userService”. Außerdem sollte die Loginseite keinen Filter/Access haben (s.o.) Lieber 2x prüfen!

Fehlermöglichkeit 2b: Es erscheint eine Ausnahme, dass der Key falsch sei.
Lösung: Dazu muss man wissen: Sobald man eine individualisierte RememberMe-Konfiguration nutzt, wird auch der Key nicht mehr vernünftig auf alle Komponenten (Provider, Filter, Manager) gesetzt. Beim Anlegen wird also der eigene Key verwendet, beim Auslesen der Standardkey. Yes! (s.o.)

Fehlermöglichkeit 3: Man besucht die Seite ohne Login, aber mit Cookie – aber wie in 2 nur die Loginseite.
Lösung: Im Logger/Debugger kann man nun feststellen, dass zwar das Cookie gefunden wurde, das Token gefunden und validiert wurde aber dann keine Rechte existieren – aha? Wahrscheinlich fehlt im Provider noch ein zusätzliches Setting der Komponenten. Am besten von RememberMe Service/Filter/Provider jeweils alle möglichen Properties durchgehen. Jaja, wie gesagt.. ;)

Fehlermöglichkeit 4: Das Ausloggen (beispielsweise logout.html) hat nach Aktivierung von Rememberme plötzlich keine Auswirkungen mehr.
Lösung: Zwar wird die Seite gefunden, aber es wird kein “Logout” gemacht. Auch hier sollte man prüfen, ob ein SecurityChainFilter (web.xml) auch für die logout-Seite greift.

Fehlermöglichkeit 5: Das Besuchen der Seite wirft einen Fehler (ggf. “mit weißer Seite”), dass keine neue Session erstellt werden kann.
Lösung: Richtig, nach einem Request ist ja dann auch zu spät. Das Attribut create-session in der Direktive http sollte daher auf “ifRequeried” gestellt sein.

Fazit:

  • SecurityChainFilter immer prüfen
  • Intercepted Urls prüfen
  • RememberMe-Direktive innerhalb der http-Direktive ist quasi abgesehen von der services-ref unbrauchbar.

Anmerkung:

Natürlich kann man sich das Problem mit den SecurityChains vom Hals schaffen, indem man stupide ein /* filtert. Das hat jedoch zur Auswirkung, das Spring Security auch jeden verdammten Request anguckt; bei zusätzlichen (statischen) Inhalten wie Javascript, Stylesheets, Bildern, Flash u.ä. ist das ein Overhead, der unnötig ist.

Merke: Verwende in (Hibernate) Mappings keinen Spaltennamen wie “primary”. Denn wird er nicht überschrieben – etwa über die @Column-Annotation – kann es zu gar nicht lustigen Problemen in der DB führen, auch HSQLDB. Versteckt irgendwo in der Tracelog.

Hintergrund: Ist natürlich ein SQL-Schlüsselwort.

Diplomarbeit – Quo vadis?

Unsere betreuende Professorin der FH Köln bietet eine Weiterentwicklung/Fortführung unserer Diplomarbeit an, vor allem hinsichtlich Erweiterungen der graphischen Darstellung (andere Graphen, neue Graphen) sowie neue Arten von “Mustern”. Bei Interesse einfach bei ihr melden.

Unabhängig davon habe ich selber damit angefangen, das Projekt nach zubauen neu zubauen. Das Projekt steckt allerdings noch in den “anfänglichen Anfängen” ;) und konkurriert daher noch nicht wirklich als Fork o.ä. Voraussichtlich wird die Neuentwicklung auch zunächst nur zum Sammeln & Analysieren sein, und die Daten entsprechend exportieren können, damit es mit dem vorhandenen Programm kompatibel ist. Aber wie gesagt, noch ist da nichts zu sehen.