I think the browser can store objects already? Perhaps there is some way to do that, but I could not find anything for localStorage: ' The keys and the values are *always strings* (note that, as with objects, integer keys will be automatically converted to strings). '
The LSO version is an emulation of Flash, so needs AMF to match behaviour. But it doesn't cover everything from the flash version. I made a separate version ' SharedObjectJSON' that uses JSON, and has no AMF dependency: https://github.com/apache/royale-asjs/blob/develop/frameworks/projects/MXRoyale/src/main/royale/mx/net/SharedObjectJSON.as I'd also suggest the JSON version would be probably a good option for new projects that don't need strongly typed instances serialized. I used TDD for working on those. Both of the implementations are tested across swf and js, but I did not add tests to the CI build tests, and I can't remember all the reasons why now, but some tests required manual page refresh to test automatic flush etc. On Fri, Jan 31, 2020 at 8:42 AM Alex Harui <[email protected]> wrote: > Hi Carlos, > > I probably don't understand your use case. I would not recommend to new > projects to use AMF to store data locally. I think the browser can store > objects already? And I would think the difficulty of re-coding > SharedObject.setProperty to LocalStorage.setItem would be worth the effort. > > I must be missing something. > -Alex > > On 1/30/20, 11:35 AM, "Carlos Rovira" <[email protected]> wrote: > > Hi Alex, > > I tried this and reverted the commit since it has more things to be > considered. LSO can be considered part of the AMF set of code, and > depends > on AMF classes that are currently in MXRoyale, for that reason Greg > created > there and not in Storage. These classes will need to be refactored out > of > MXRoyale as we already planned months ago. Right now we need to > exclude CSS > from MXRoyale, to avoid mess with other CSS. Another reason for me (and > maven users) is to avoid have APIs that you don't need (a thing that I > know > is not very important for you or others that could prefer all APIs at > hand, > but that I care for). > > A side from that I think MXRoyale needs to focus on MX and SparkRoyale > on > Spark, as well someday hope I can create MXRPC that have all RPC, > HTTPService, LSO,... If you remember we already talked about this > months > ago, and I tried, but was more time at that moment, and needed to left > the > work in a branch. > > LSO is a flash class and has the benefits of use AMF encoding and > decoding, what > I think is a cool feature to consider (many not for others) and > there's no > MX counterpart, is now part of the emulation due to the AMF issue, but > will > need to be in MXRPC lib. > > I tried LSO for the TodoMVC.com example I'm working on (since is part > of > the specifications in the todomvc.com site), and did not want to add > to the > pom MXRoyale to not confuse new comers, anyway, there's no way for > now, and > we need to left as is. > > Anyway I'm very satisfied with the example since we can see Royale is > now > very robust in many aspects :). Hope to finish it soon and share. > > Thanks > > Carlos > > > > > El jue., 30 ene. 2020 a las 18:28, Alex Harui > (<[email protected]>) > escribió: > > > I don't know if it would be more "general" since it would be > > Flash-specific, but re-use of code from Storage is always a great > goal. > > The MXRoyale components re-use quite a bit of code from Basic. > > > > Taking a quick look at the ASDoc, SharedObject offers both Local and > > Remote flavors and a "connect(NetConnection)" API which is probably > not > > needed for locally storing some data and would drag in dependencies > for > > NetConnection emulation from MXRoyale. Meanwhile, > > org.apache.royale.storage.LocalStorage seems to have a similar API > to the > > subset of SharedObject that folks would actually use for a local > > SharedObject, so the MXRoyale emulation of SharedObject would > probably > > subclass or wrap LocalStorage. > > > > Of course, I could be wrong... > > -Alex > > > > On 1/30/20, 9:05 AM, "Harbs" <[email protected]> wrote: > > > > Possibly a MX version with Flash APIs should use a more general > > version from Storage? > > > > > On Jan 30, 2020, at 5:45 PM, Alex Harui > <[email protected]> > > wrote: > > > > > > I don't know LSO or the Storage SWC that well, but there is > some > > sort of LocalStorageProvider.as file already in Storage. > > > > > > IMO, if you are planning to 100% emulate the Flash LSO, that > should > > go in MXRoyale. A more platform-independent API for local storage > should > > go in Storage. I don't know what is already there. > > > > > > My 2 cents, > > > -Alex > > > > > > On 1/30/20, 7:23 AM, "Carlos Rovira" <[email protected]> > > wrote: > > > > > > Hi, > > > > > > I was searching for some Flex counter part to the LSO > classes in > > MXRoyale > > > but didn't find anything. > > > So if nobody opposite I'll move to the Storage library that > seems > > its > > > natural place. > > > > > > Thanks > > > > > > -- > > > Carlos Rovira > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccc1c807e7d384b049dda08d7a5bb7e22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637160097012240946&sdata=doNhtJw5LONR6bmpJcrzQVaERP2KV0ydXTFnjwFVHWU%3D&reserved=0 > > > > > > > > > > > > > > > > -- > Carlos Rovira > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccc1c807e7d384b049dda08d7a5bb7e22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637160097012240946&sdata=doNhtJw5LONR6bmpJcrzQVaERP2KV0ydXTFnjwFVHWU%3D&reserved=0 > > >
