http://twitter.com/IE/status/10577927335 Ich glaube ich träume!
Archiv der Kategorie Allgemeines
IE kriegt H.264?
Mrz 16
Wenig Android Updates
Mrz 15
Die Geräte werden in Teilen weiterhin mit alten Version verkauft. Ja, warum wundert mich das jetzt nur nicht?
HTML5 for the rest
Mrz 11
http://daringfireball.net/linked/2010/03/11/html5media
Gestern hat Apple den in letzter Zeit häufige Methode umgedreht und selber eine Klage eingereicht – gegen HTC, gegen den derzeitigen Hauptkonkurrenten in Sachen technischer Geräte/Smartphones. Und entgegen Heises aktuellen Stand ist sehr wohl bekannt, um welche Patente es sich genau handelt – inkl. der ersten, unbestätigten Deutungen/Beispiele.
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?
Android: Kleines Stolpern?
Feb 16
Es gibt die ersten Anzeichen, das der große Vorteil des Android OS auch ein Nachteil ist: Die Offenheit, die Flexibilität und die – mögliche – Masse an Hardware bremst die Entwicklung eher. Problem: Nicht jedes Gerät ist gleich, nicht jede Funktion ist also da. Und nicht jedes Gerät ist unbedingt auf dem neusten Stand. Und ob nun wirklich jeder Benutzer das selbständig(!) aktualisiert?
“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.
Google, Mozilla.. und die Videos sind mal erste Klasse!
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.
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.
Aufgabe: Es muss via Flashvar eine URL an ein Flash übergeben werden, welches diese dann aufrufen und die Daten nutzen soll.
Problem: Die Flashvars bestehen auf einer Aneinanderreihung von {key}={value} Parametern (verknüpft mit dem “&”). Dabei muss {value} komplett urlencodiert sein. Also die *gesamte* URL als solche. Das Flash wiederum liest den Parameter ein, decodiert(!) den entsprechenden Flashvar-Parametern und führt ihn dann aus. Dazu kommt, dass die Javascript-Funktionen escape() u.a. nicht *ausreichend genug* sind, um alle Zeichen zu kodieren. Tests mit “*” oder “+” führen schweren Fehlern, bzw. zu veränderten Parametern.
Lösung:
Das erste Geheimnis ist simpel, aber wichtig. Die Kodierung muss *zweimal* angewendet werden. Das erste Mal für jeden Parameter der eigentlichen URL (ich gehe mal davon aus, das die Parameterschlüssel immer gültig gewählt sind) und das zweite Mal für die gesamte URL. Damit erhält das Flash nach der ersten Rückumwandlung der Flashvar immer noch eine URL, wo alle Inhalte kodiert sind.
Das zweite Geheimnis ist nicht ganz so trivial, allerdings gibt es auch hierzu Lösungen. Im Internet findet sich eine nette Gegenüberstellung der Methoden escape, encodeURI und encodeURIComponent. Kurzes Fazit: escape < encodeURIComponent. Aber auch letztere wandelt einige Zeichen nicht um, die bei der Verwendung mit Flash Probleme machen. Diese Zeichen (~!*()’) und das + müssen daher noch händisch kodiert werden.
function escapeAdvanced(s) {
var r = encodeURIComponent(s);
var replacements = {
'~': '%7E',
'+': '%2B',
'!': '%21',
'*': '%2A',
'(': '%28',
')': '%29',
"'": '%27'
};
for (s in replacements) {
if (replacements.hasOwnProperty(s)) {
r = r.replace(s, replacements[s]);
}
}
return r;
}
Für schönere Lösungen bin ich jederzeit offen 
Update: Mit UTF8 hat das ganze allerdings Probleme; wäre ja auch zu schön gewesen.
Im Zuge eins kommenden Artikels/Howto über Webapp Deployment/Build suche ich noch bestehende Lösungen, gerne auch Scripts a la Ant. Auf letzterem basiert auch meine bisherige Vorgehensweise..
Update: Inkl. dem Buildprozess.