Typsicheres speichern in Local Shared Objects

SharedObjects (Local SharedObjects) können aud vielfältige Weise benutzt werden, um Daten auf dem Rechner eines Users abzulegen. Meist handelt es sich dabei um einfache Statusinformationen oder ein paar Settings. Eigentlich sind SharedObjects aber dafür gedacht, es verschiedenen Anwendungen aus einer Domain zu ermöglichen Daten untereinander auszutauschen.

Verständlich aber ärgerlich ist dabei, daß eine Anwendung zwar sämtliche Datentypen erst mal in das local SharedObject (LSO) speichern kann, die lesende Anwendung jedoch bei komplexen Datentypen jedoch die gesamte Struktur nur als Typ „Object“ interpretiert. Beim lesen der Daten muss man sich folglich mit untypisierten Objekten herumschlagen oder diese wieder mittels einer parsing-Routine in korrekte komplexe Datentypen umwandeln.

Das ist jedoch nicht nötig, wenn man diese komplexen Datentypen mit zuästzlichen Meta-Informationen versieht. Das funcktioniert genau so wie beim Austausch von Daten mit einem Webservice oder einem Flash-Media-Server. Die betreffenden Klassen bekommen einfach in ihrer Klassendefinition ein Metatag [RemoteClass(alias="de.aboutflash.vo.MyType")] mit einem Alias. In der Zielanwendung muss man nun nur noch mittels registerClassAlias dieses Alias auf eine entsprechende Klasse mappen.
flash.net.registerClassAlias("de.aboutflash.vo.MyType", de.aboutflash.vo.MyType);

Ab sofort kann die lesende Anwendung diese Datentypen wieder so interpretieren wie die Schreibende.

Ich habe dazu ein kleines Beispiel angelegt, welches ihr euch hier anschauen könnt.
Beispielanwendungen: normale vs. typsichere Local SharedObjects

Bug bei Verwendung des booleschen Operators "&&" in MXML

Flex hat mich heute damit verwirrt, daß ich immer einen Compilerfehler bekam, wenn ich folgendes Statement im MXML-Code verwenden wollte:

Der Compiler beschwerte sich darüber mit folgender Meldung The entity name must immediately follow the '&' in the entity reference.
Eigentlich soll hier ganz simpel zwei boolesche Werte zu einer Aussage verknüpft werden, aber da diese Verknüpfung im Kontext des MXML-Dokuments stattfindet, meint der Compiler hier eine ungültige HTML-Entität wie " oder < zu entdecken.

Man kann sich damit behelfen, die &-Zeichen als HTML-Entität & zu maskieren.

Dieser Bug ist in Adobes Flex Bugtrack (#SDK-12930) bereits beschrieben aber in der aktuellen Release des Flex-SDKs ist er noch nicht behoben.

Flex 3.0 und AIR 1.0 sind fertig

Angekündigt für März ist Adobes Flex 3.0 SDK sowie AIR 1.0 Runtime nun fertig und stehen zum Download bereit. Ebenso ist auch der dazu passende Flex Builder erschienen und kann in zwei Versionen (Standard / Professional) erworben werden. Die Preise liegen mit 213,- bzw. 594,- EUR im Rahmen des Erwarteten – und Adobe-unüblich umgerechnet kaum höher, als die aktuellen Dollar-Preise in den USA. 😉 Warum allerdings in Deutschland ein Download im Gegensatz zum klassischen Versandpaket ca. 10,- EUR teurer ausfällt, bleibt ein Rätsel.

Gegenüber der günstigeren Standard Edition bekommt man im Professional Paket den Profiler sowie das (früher extra zu erwerbende) Charting-Modul dazu.

Data Binding: Array vs. ArrayCollection

Eines der mächtigsten Features in Flex ist die Darstellung von Daten aus dem Model auf der GUI der Applikation per Data Binding. Wenn man Daten in einfachen Properties speichert und diese mit dem [Bindable] Metatag versieht, wird ein daran gebundenes GUI-Element über einen Event von der Änderung benachrichtigt. Ist diese Property aber ein Array, bekommt eine daran gebundene Komponente nicht mit, wenn diesem Array ein Element hinzugefügt wird. Um einen Refresh der Liste zu bewirken, muß man manuell (z.B. innerhalb einer setter-Methode) ein myList.invalidateList() vor der Änderung des Array-Inhalts ausführen. De Nachteil hierbei ist, daß man in der setter-Methode eine Referenz zu der darstellenden Listenkomponente halten muß. Das wiederspricht aber dem Prinzip der Trennung von Datenmodell und View.
Weiterlesen

Debuggen von Flex-Applikationen

Flex Builder 2 besitzt eine einfach zu bedienende Debug-Funktion. Eine Flex-Applikation wird als Flash Debug-Movie gestartet und der Flexbuilder/Eclipse wechselt in die Debug-Ansicht und startet das kompilierte Movie in einem Standalone-Flash(debug)player.

Manchmal ist es jedoch notwendig, ein Movie in einem anderen Kontext (z.B. gestartet von einer anderen Anwendung) zu debuggen. Normalerweise hat man keine Möglichkeit, den Debugger einfach zu starten und später einen Movieclip mit ihm zu verbinden.
Weiterlesen