Adobe loves Apple

Adobe startet “We Love Choice”-Kampagne und attackiert damit die Firmenpolitik von Apple. Insbesondere geht es darum, dass Apple Software-Entwicklern vorschreibt, mit welchen Technologien Apps für das iPhone und das iPad entwickelt werden dürfen. Dabei werden die Adobe-Technologien Flash und AIR nicht unterstützt. Adobe bekennt sich in der Kampagne zu einem Technologie-Mix, Open-Source und einer freien Software-Auswahl für Entwickler und Anwender. In einer ganzseitigen Anzeige in der FTD heißt es plakativ: “We love apple … We love apps … We love the web … We love HTML5 … We lova all platforms … What we don’t love is anybody taking away your freedom to choose what you create, how you create it, and what you experience on the web“. Sehr gelungen und recht haben sie! Nicht frei wählen zu können, welche Technologie für eine Problemstellung die Beste ist oder einfach welche einem persönlich am Besten liegt, schränkt stark ein, nervt(!!!) und wird am Ende Apps mit schlechterer Qualität hervorbringen.

Apple hingegen beansprucht für sich, ausschließlich auf freie Web-Standards wie HTML5 zu setzen. In einem Showroom demonstriert Apple die Leistungsfähigkeit von HTML5 und will damit zeigen, dass das Flash-Plugin für effektlastige Webseiten nicht (mehr) notwendig ist. Witziger Weise muss derzeit zum Betrachten der Beispiele nicht nur ein Plugin, sondern ein vollständig neuer Webbrowser installiert werden, wenn man nicht eh Safari zum Browsen verwendet (sicherlich werden zukünftig andere Browser die HTML5-Unterstützung nachziehen). Weiterhin ist es fraglich, ob HTML5 tatsächlich die technischen Möglichkeiten für RIAs bietet, die mit der Flash-Plattform möglich sind. In einem Artikel im RIABlog zum Beispiel wird ein Vergleich der beiden Technologien gezogen und der Siegeszug von HTML5 in naher Zukunft bezweifelt. Eher eine friedliche Co-Existenz wird prognostiziert, bei der in Sachen RIA die Flash-Plattform eine wichtigere Rolle spielt.

Adobe kontert gegen Apple, dass Flash in allen Webbrowsern abspielbar ist, das Plugin kostenlos zu Verfügung steht und Flash-Anwendungen frei mit dem Open-Source Flex-SDK entwickelt werden können. Für Flash-Beispiele präsentiert Adobe einen eigenen Showroom.

Abgesehen von der Technologie, geht es natürlich sowohl Apple als auch Adobe bei diesem Streit um Marktanteile. Es ist offensichtlich, dass Apple auf seinen mobilen Endgeräten Adobe-Technologien aus rein wirtschaftlichen Beweggrunden verbietet. Der App-Store soll die Quelle aller iPhone/iPad-Software sein. Apple möchte die Softwareverbreitung kontrollieren und am Ende kassieren. Schon OK… selbst schuld wer sich solche eingeschränkte Hardware kauft. Aber… nervig ist es für Software-Entwickler, die mit ihren Produkten mehrere Plattformen bedienen wollen. Die fangen jetzt an parallele Entwicklungen für Apple-Produkte zu bauen. Irgendwie erinnert mich das an die Zeiten des IE5, als Webseiten für den verfluchten, jedoch weit verbreiteten Mircosoft-Browser faktisch aus anderem HTML-Code bestand, als für alle anderen. Was für ein Aufwand! In diesem Sinne: I LOVE CHOICE und die Entwicklung mit Flash/Flex mag ich zumindest ziemlich gerne.

Ein visueller Vergleich der beiden Firmen Apple und Adobe gibt es unter: http://eserrano.com/treble-click/Apple-Flash-infographics.html Und für alle die auch vom Apple-Hype genervt sind und auf Flash im Browser nicht verzichten wollen: es gibt auch offene Tablet-PC mit Flash-Unterstützung wie zum Beispiel das WeTab.

Use PureMVC - Drink Mate: Zwei Flex-Frameworks im Vergleich

Zugegeben: Dies wird jetzt kein fairer Vergleich! Von PureMVC bin ich begeistert - vom MATE-Framework halte ich nicht viel, außer “mal ganz Interessant einen anderen Weg zu sehen”. Leider bin ich zur Zeit in einem langfristigen Projekt an MATE gebunden. Einen Weg dieses Framework einzusetzen habe ich bereits in einem anderen Artikel in diesem Blog zusammengefasst und dabei einen ersten Vergleich zwischen MATE und PureMVC gewagt. Nun, knapp 3 Monate später hat sich mein erster Eindruck des MATE-Framework bestätigt: Es ist ein experimenteller Weg und für große Kundenprojekte einfach nicht sinnvoll! Hier eine Zusammenfassung, warum ich PureMVC immer vorziehen würde. [Read more →]

RubyAMF-Checklist

AMF ermöglicht es, einen besonders performanten Datenaustausch zwischen einer clientseitigen Flash- und einer Server-Anwendung zu realisieren. Die AMF-Datenpakete sind sehr klein und garantieren auf diese Weise eine geringe Übertragungszeit. Weiterhin wird das Format vom Flash-Player standardmäßig unterstützt, sodass die Serialisierung und Deserialisierung der Datenobjekte schnell und vor allem automatisch vorgenommen wird. Die Konvertierung in das Nachrichtenformat (und zurück zum Objekt) wird vom Flash-Player übernommen und erfordert keine zusätzliche Implementierungen oder Bibliotheken. Serverseitig nimmt ein AMF-Gateway die Client-Anfragen entgegen, konvertiert den Datenstrom in die entsprechenden Datenobjekte und delegiert diese zur gewünschten serverseitigen Objekt-Funktion (im Fall von Rails zu einer Action eines Controllers). RubyAMF ist ein solcher Gateway. Durch die Installation des entsprechenden Plugin in ein Rails-Projekt kann der Gateway eingerichtet werden. Das so genannte Class-Mapping ermöglicht es, dass die Objekte auf der entsprechenden Gegenseite richtig typisiert ankommen. In dem Fall, dass der Datenaustausch funktioniert jedoch das Class-Mapping fehlschlägt, kommen die Daten-Objekte als anonyme Objekte vom Typ Object in der Flash-Anwendung an. Zur Erleichterung der Fehlersuche, hier eine kleine Checkliste.

1. Die Klassen müssen in der RubyAMF-Config-Datei (config/rubyamf_config.rb) für das Mapping registriert werden.

2. Die Datenobjekte in Rails und Flash müssen die gleichen Attribute besitzen. Die Schreibweise in snake_case oder camelCase kann variieren, jedoch muss RubyAMF dazu entsprechend konfiguriert werden.

3. Bei ActiveRecord-Objekten muss die Datenbank-Migration ausgeführt worden sein.

4. Die ActionScript-Klassen der Datenobjekte müssen als RemoteClass registriert sein. Bei der Metatag-Variante ist darauf zu achten, dass [RemoteClass(alias="ObjectAlias")] direkt vor oder über der Klassen-Deklaration steht.

5. Die ActionScript-Klassen der Datenobjekte müssen in das Flash/Flex-Projekt importiert werden.

6. Die Klassen müssen in den ActionScript-Code importiert werden (!!!).

Blitzschneller Rails-Flash-Datenaustausch via AMF

AMF steht für Action Message Format und bezeichnet ein Binärformat zur Serialisierung von ActionScript-Objekten. Das Format wird nativ vom Flash-Player unterstützt und ermöglicht einen besonders performaten Remote-Datenaustausch zwischen einer Flash- und einer Backendanwendung. Serverseitig wird ein AMF-Gateway benötigt, der sie Serialisierung und Deserialisierung des Datenstroms vornimmt und die entsprechende Objektfunktion aufruft. Um diese Art der Datenübertragung mit einem RubyOnRails-Backend nutzen zu können, steht RubyAMF unter einer leicht modifizierten MIT-Lizenz als Gateway-Plugin zur Verfügung.

Im aktuellen Railsway-Magazin (Ausgabe 06.2009) habe ich einen Artikel veröffentlicht, in dem der praktische Einsatz von RubyAMF beschrieben wird. Insbesondere wird auf das Class-Mapping eingegangen. Durch das Class-Mapping-Verfahren ist es möglich, dass Flash-Datenobjekte direkt als ActiveRecord-Objekte im Rails-Backend zur Verfügung stehen und weggespeichert oder aktualisiert werden können. [Read more →]

Deep-Linking in Flash- und AJAX-Anwendungen

Seitenmetaphern im WWW sind eine Verkettung einzelner Webseiten, die jeweils genau einen Zustand darstellen. Auf traditionellen Internetseiten wird bei einer Nutzeraktivität eine neue Webseite geladen, die einen neuen Zustand repräsentiert. Jede Seite und damit jeder Zustand kann durch eine URL adressiert werden. Durch den Einsatz von Flash- und AJAX-Anwendungen werden diese Seitenmetaphern durchbrochen, da die Client-Anwendungen unterschiedliche Zustände annehmen können. In solchen Anwendungen kann eine Kommunikation mit dem Server stattfinden, ohne dass die Seiten-URL wechselt. Durch diesen Umstand werden die typischen Browser-Funktionen “Seite vor” und “Seite zurück”, sowie die History-Anzeige außer Kraft gesetzt. Weiterhin können die Zustände der Anwendung nicht über eine URL adressiert oder als Bookmark gespeichert werden. [Read more →]

Was soll das Command-Pattern?

Wenn man lernt objektorientiert zu Programmieren, bekommt man eine einfache Faustregel an die Hand: Objekte sollen die Realwelt abbilden. Zur Klassen wird alles was ein Nomen ist. Attribute legen die Eigenschaften dieser Nomen fest, sind also in der Regel die Adjektive. Und Funktionen stellen die Verben da, die eine Handlung beschreiben.

Sobald man jedoch das Verständnis für OOP erworben hat, rückt diese Regel stark in den Hintergrund. Man beschäftigt sich mit “sauberer” Programmierung und einer Trennung der Zuständigkeiten zwischen Darstellung, Daten und Logik (MVC-Architektur), sowie einer losen Kopplung zwischen diesen Programmteilen. Besonders merkwürdig kommt einem das Command-Pattern vor, ein durch die GoF beschriebenes Verhaltensmuster. [Read more →]

SemKingPeng - Datenvisualisierung

Nachdem der Zoo Berlin dank Eisbär Knut einen Medienhype und weltweite Berühmtheit erlangte, stellen nun die angelockten Menschenmassen immer wieder erstaunt fest, dass der Zoo auch noch andere Tiere besitzt. Um diese multimedial zu präsentieren, hat sich der Studiengang Medieninformatik an der Technischen Fachhochschule Berlin im Sommensemester 2008 mit Besucherinformationssystemen im Zoo Berlin beschäftigt.

Mit zwei Kommilitonen habe ich an dem Projekt SemKingPeng gearbeitet. Wir haben einen Prototyp für eine Software entwickelt, wie sie im Pinguinhaus auf einem Touch-Display-Terminal zum Einsatz kommen könnte. Die Datenvisualisierung und Navigation in unserem Projekt erfolgt mit dem Einsatz von multimedialen Hypertext. [Read more →]