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 } );
