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
can you post the code plz?
It’s already online. Please click on the link on the bottom of this article to open the example applications. Then you can use [Right click] > „View Source“ to download the sources.
Thanks!
Is it also working for Remote Shared Objects?
Yes, that’s what it was made for.
Also you can use ObjectUtil.copy(yourObjectInstance) on a any class instance that has an [RemoteClass] meta tag set to create a new (type safe) copy of that class instance.
Without that, ObjectUtil.copy(yourObjectInstance) would create a generic object with all member variables from the copied class instance as properties of the copy. Both ways have their pros and cons.
This is scary.For the last two weeks I’ve been working on aidndg features to a flash portion of a large retail website. The code is written as if someone started out with 10 different ideas of how to properly program (50% of the code lines miss the semi-colon). Dozens of design patterns thrown together. 30% of the classes doesn’t seem to be used. One of the main .fla’s contain tons of files for different campaign sites done by the same production company.Then it’s as if the code has gone through the washing machine a few times, totally whacked. And yet it magically works.I have in short time gone from making small banners to dealing with this, so I’m learning a lot and your posts have somehow synced with my current experiences, that’s what’s so scary!Today, for the first time, I wrote a specific helper class just for this project alone, although it’ll be useful later on.Class is called ChildSupport, and you simply feed it a DisplayObjectContainer and it parses through it and recursively lists all children, optionally the x & y values of the children and also you can choose how many levels deep you want to go.(At first I ran it on the whole project container and it of course timed out with hundreds of movieclips filling flashlog.txt).Nothing groundbreaking, but for me it’s huge, and quite fun indeed! While at the same time I was worried I was straying too far from the main objective. Again, you’re nailing it spot on in your post!Are you sure you don’t want to come to Stockholm and work with us? In code nerd land, I’d probably want to marry you.Keep the blog alive, it’s awesome!