This content has been marked as final. Show 6 replies
None that I have ever heard of. Client memory is the only physical limit i can imagine.
> None that I have ever heard of. Client memory is the only physical limit i can imagine.
Thanks for the reply.
Can you elaborate a little?
If I am using Defered Creation for the ViewStack children so that they
are only instantiated as they become active, is there still potential
for problems with client memory? Or is this just going to help start-up
Once instantiated, but no longer visible, are children still in memory?
so if I have 100 children for example, and the user goes through them
linearly from child 1 through 100, by the time no 100 is instantiated,
does the client machine now have all 100 in memory? Can I remeove them
from memory if so?
Thanks for any help.
"Once instantiated, but no longer visible, are children still in memory? " Yes
"Can I remeove them from memory if so". No
If that is a realistic scenario, you should probably look into "modules" or using SWFLoader.
> "Once instantiated, but no longer visible, are children still in memory? " Yes
> "Can I remeove them from memory if so". No
> If that is a realistic scenario, you should probably look into "modules" or
> using SWFLoader.
I thought it was possible to dynamically remove (or add) children? Would
that not cause it to be removed from memory?
I am not currently familiar with modules, so I will read up on that.
I am looking at creating a paging structure to create eLearning in Flex,
so 100 'pages' is possible. My initial idea was to use a ViewStack for
this but I am not sure now if this is the best approach.
Yes, yo can dynamically add and remove childern and they will be garbace collected if you are very careful about removing all references, including event listeners.
It depends on how complex each page is. I would implement it using ViewStack, with each page an individual component. Keep the components loosely coupled from the parent, by using events and bindings for data communication. This way, If you find later that you have performance issues, you can keep the outer UI framework, most of the navigation code, and all of the component code, and only have to change how the components are rendererd.
And actually, you might have only a single "Page" component, whose content is data-driven .
Are your page components going to be wildly different in interactivity? If not, then make them data-driven. This will eliminate your memory concerns entirely.