also keep in mind virtualization use in Lists. Just one more cog in The Wheel That Depends
Douglas Knudsen http://www.cubicleman.com this is my signature, like it? On Wed, Sep 7, 2011 at 3:21 PM, Nick Middleweek <n...@middleweek.co.uk>wrote: > ** > > > Alex, > > That's a good idea... What's your thoughts on approach to implement a > shared Button? > > Would you create it at the parent view level and inject into the IR's using > some kind of IFactory or perhaps attach it to the data property? > > > Cheers, > Nick > > > > On 7 September 2011 17:27, Alex Harui <aha...@adobe.com> wrote: > >> ** >> >> >> Yes, it is a set of trade-offs. Deferring until you know you need it is >> best for memory and startup time, but you have to pay for the adding later. >> You can cache the button so you don’t always create a new one. You can >> even share a button between all renderers if you want. >> >> >> >> On 9/7/11 5:42 AM, "ganaraj p r" <ganara...@gmail.com> wrote: >> >> >> >> >> >> >> With toggling the visibility property you are creating 1 Button per Item >> Renderer. >> >> When you are creating an object each time a user's mouse is over it, and >> then deleting it when its out, you are creating 'n' number of objects and >> deleting them , the new objects need to be garbage collected. >> >> The initial load is going to be more ofcourse, but then its a set number >> since you are only going to be creating a set number of buttons. >> >> On Wed, Sep 7, 2011 at 10:23 AM, Nick Middleweek <n...@middleweek.co.uk> >> wrote: >> >> >> >> >> >> >> Alex, >> >> Just checking/ thinking... But if I go down the visibility route and >> addChild( x ) up front in createChildren() would I be consuming more initial >> memory than if I addChild( x ) as and when I needed it? >> >> In my case, I have 15 columns, using the same renderer and 40 rows so >> that's 600 extra buttons that would be created that are initially set >> visible = false; >> >> I'm assuming they are all in memory and when scrolling, this could impact >> scroll performance. >> >> >> Or is adding/ removing children dynamically and making each Item Renderer >> go through it's update cycle more expensive? >> >> >> Cheers, >> Nick >> >> >> >> >> On 6 September 2011 19:48, Alex Harui <aha...@adobe.com> wrote: >> >> >> >> >> >> >> States are still available in the MX way. You can also hide and show >> instead of add and remove. >> >> Known children should be created in createChildren or in states. But >> otherwise, you have to create them when you know you need them. The List >> components create them in updateDisplayList since that’s when they finally >> know how many to create. >> >> >> >> On 9/6/11 10:48 AM, "Nick Middleweek" <n...@middleweek.co.uk < >> http://n...@middleweek.co.uk> > wrote: >> >> >> >> >> >> >> Thanks for this... So I'm extending UIComponent, does this mean I'm doing >> it the MX way? >> >> Cheers... >> >> >> On 6 September 2011 14:38, Haykel BEN JEMIA <hayke...@gmail.com < >> http://hayke...@gmail.com> > wrote: >> >> >> >> >> >> >> Hi Nick, >> >> if you use Spark components and the child components you want to add are >> fixed and known, e.g. a 'close' button that should be visible on mouse-over, >> then I would use skin states and manage visibility of the components in the >> skin. >> >> Haykel Ben Jemia >> >> Allmas >> Web & RIA Development >> http://www.allmas-tn.com >> >> >> >> >> >> On Tue, Sep 6, 2011 at 10:28 AM, Nick Middleweek <n...@middleweek.co.uk < >> http://n...@middleweek.co.uk> > wrote: >> >> >> >> >> >> >> Hi, >> >> I've been trying to find the correct 'place' to create new components >> after the parent component is UPDATE_COMPLETE. >> >> During initialisation, we create child components in *createChildren()*but >> where/ when should we create them for e.g. in response to a mouseOver or >> a mouseClick event? >> >> Is it simply 'ok' to *this.addChild( *myNewButton *)* in a MOUSE_EVENT >> function handler or should I be setting some dirty flag to trigger off an >> invalidation and then add the button in a lifecycle override function? >> >> >> Thanks, >> Nick >> >> >> -- >> Alex Harui >> Flex SDK Team >> Adobe System, Inc. >> http://blogs.adobe.com/aharui >> >> > > > -- > Sent by Nick Middleweek ( { email: n...@middleweek.co.uk, mobile: +44(0)774 > 035 5424, blog: http://www.middleweek.co.uk } ); > > > >
