I think there are two different use cases here I think there is a common use case where you have a flexible ui that needs to save the positions of hdividedbox and vdividedbox positions and the column widths of datagrids, stuff like that, so that users can customize a flexible view to their tastes or screen size and have it stay that way per machine. You access the app on your netbook and you get one layout, you access the app from your desktop, you get another, even though your data is the same on both.
In this case you're staving state that is important, but not so important that you want to save it in a database and which is dependent on the client anyway. 100kb is a lot of space for stuff like that and for pure flex apps it would be good to just have a localpersistent metadata tag that you can apply to properties of a component and have it be managed with a global manager to deal with size limitations and to make it easier to manage and less error prone. I think that something like that make a lot of sense for the framework to handle and would be pretty easy to do. I think the core problem Nick is dealing with is much different, since what's really creating the problem is the page refreshes that are forcing the components to reload the actual data as well as any semi-ephemeral view state information. In this case I think it's the portal frameworks responsibility to reduce the page refreshes by, say, hiding and showing the elements that house the flex components rather than refreshing that part of the page. And yet after doing the first part, it obviously wouldn't be difficult to also allow the components to cache their actual data providers as well and to compress them, as a second, though less frequently used option, and one that might eventually force folk to bump up their local shared object store for a large app like Nicks. This would also enable offline use of apps and potentially even the saving of changes when offline to make when the user comes online again. Once again it would be easy to do and in this case it might be too easy to do, because it might get overused, but by implementing this it would even make the development of serverless apps very easy and radically reduce bandwidth use in cases like Nicks, though I don't see any way around bumping up the local shared object storage long term, unless everything is going to be saved and maintained at the server level. On Thu, Jan 26, 2012 at 7:23 AM, Nick Collins <ndcoll...@gmail.com> wrote: > In that case you are talking about AIR, though, which is a different beast > from the Flash Player in terms of sandbox limitations. Within the browser > player you have limitations on how much data you can store in a shared > object before it prompts the user ( if I recall correctly it is 100kb) to > ask if it can use more. The ideal user experience would be that it happens > completely transparently to the user. In essence, it "just works". > > > > On Wed, Jan 25, 2012 at 10:32 AM, Frank Altomare <lost...@gmail.com> > wrote: > > > It seems like this may be pretty well handled in Flex Mobile with View > > states. Flex gives you some options for how to cash the current view > state > > as well as to write anything you need to a SharedObject. > > > > I'm not sure how much of this is handled by the OS but in my experience > it > > has worked pretty well > > > > On Wed, Jan 25, 2012 at 11:26 AM, Alex Harui <aha...@adobe.com> wrote: > > > > > > > > > > > > > > On 1/25/12 8:14 AM, "Nick Collins" <ndcoll...@gmail.com> wrote: > > > > > > > > > > > > > > One of the major issues is that of persisting the state of the Flex > > > > application. In a portal environment, one of the core concepts is the > > > idea > > > > of being able to bounce around between pages and having your portlets > > > hold > > > > their state so that when you go back to them, you can pick up right > > where > > > > you left off. With a large Flex application, this is nay to > impossible. > > > > Sure there are all kinds of tricks you can do with LSO's, > deep-linking, > > > > etc. to simulate it, but I would like to see some of the more > > enterprise > > > > focused functionality like this be brought into the framework, or at > > > least > > > > taken into consideration so that it is not quite so cumbersome. > > > > Unfortunately, I also realize that in order to accomplish this in the > > > most > > > > elegant manner, we would likely need changes to the runtime itself. > :-( > > > How is this done in the HTML/JS/CSS stack? > > > -- > > > Alex Harui > > > Flex SDK Team > > > Adobe Systems, Inc. > > > http://blogs.adobe.com/aharui > > > > > > > > > > > > -- > > Francis Altomare, > > >
