Bleibt eigentlich zu dem Patentblödsinn nur zu sagen:

• Dem Unternehmen Apple bleibt wie allen anderen nichts anderes übrig, als weiter Patente zu registrieren. Würden Sie es nicht machen, schnappt sich ein anderes Unternehmen das Patent und man wird selber verklagt.
• Die Unternehmen müssen ihre Patente verteidigen und einsetzen, ansonsten wäre das Patent ja irrelevant.

Eins muss man aber schon sagen: Es ist wirklich bemerkenswert, wie die anderen Hersteller – HTC ganz vorne – seit 2007 ihre Produktlinien verändert haben. Natürlich ganz uninspiriert von der Konkurrenz!!!11 Die liebe “Apple-Konkurrenz” sollte lieber mal ihre Hausaufgaben machen und überlegen, warum sie die doch so alten und nicht wirklich neuen Techniken nicht selber derartig revolutionär entwickelt haben. Abgesehen von der Touch-Steuerung gab es fast alles vorher, wenn auch nicht im Mobil-Computer-Bereich.

Und zum Schluss: Wer als Konkurrent versucht, das iPhone-Dilemma nur mit einer technisch überlegenen Kopie zu entgegnen, der hat immer noch nicht verstanden, wie der Erfolg zustande kam. Technik ist nicht alles. Wen interessieren heute noch Ghz im Prozessor?

“a good point”:

New Android devices are being announced and shipped in bunches. HTC, Samsung, Dell, Verizon and others have phones on the way. Each has different hardware, and different software, than the others.

We’ve spoken with a number of high profile Android application developers. All of them, without exception, have told me they are extremely frustrated with Android right now. For the iPhone, they build once and maintain the code base. On Android, they built once for v.1.5, but are getting far less installs than the iPhone.

Link: techcrunch.com

Es ist durchaus mühselig, wenn man als Entwickler eine große Anzahl von Funktionen/Features nicht voraussetzen kann, weil nicht jedes Gerät alles kann bzw. das Softwareupdate nicht ausgeführt werden kann, darf, muss, will, sollte. => Komplexität in der Entwicklung.

Den Artikel habe ich über folgenden Text gefunden:

First, there are the obvious issues of fragmentation. Android itself is already having to deal withthis problem, as various device manufacturers and carriers lag behind in rolling out the latest system updates, and developers are forced to tweak their applications to accommodate the differences in each device. And these are phones that are on the same platform. With the WAC — which is actually supposed to “unite a fragmented marketplace” — these fragmentation problems will probably be much, much worse.

Every time the WAC platform is updated, you’ll probably have to wait for your phone’s operating system maker to update their software. And you’ll have to wait for your carrier to deploy it in an OTA update (if they don’t push these over the air, then most people will probably never update and the market will get even more fragmented). Even if these updates are painless, developers will have to deal with dozens, or even hundreds, of different devices. They’ll have to take into account the myriad display resolutions, input options (does it have a keyboard or trackball?), and processing power available. Does the device support background applications? How about GPS? You get the picture.

Link: techcrunch.com

Die Alternative ist natürlich auch nicht berauschend: Der Entwickler konzentriert sich nur auf einige wenige Geräte bzw. Versionen.

Und dann kommen da ein paar große Kinder, die gemerkt haben, das ihr Sandkasten zunehmend kleiner wird, und glauben – sie könnten das Problem lösen. Mit mehr Komplexität Vielfalt. Ja ne ist klar.

Inspiration

http://www.thechromesource.com/google-pushing-html5-for-the-future/

Stuart Parmenter:

We’ve decided to disable plugin (not to be confused with add-ons, which are supported) support for this release.  The Adobe Flash plugin used on many sites degraded the performance of the browser to the point where it didn’t meet our standards.

Siehe

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?

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.

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.

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