flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Wright <twri...@yesco.com>
Subject Garbage Collection Concern
Date Thu, 10 Oct 2013 15:14:45 GMT
I have a question about garbage collection in reference to a technique I've
used on a fairly regular basis.
Perhaps this is bad form, but this is what I've been doing nonetheless.

So this is as close to what I've been doing as possible, let's consider a
mobile app in my example of this method.

Say I have a mobile MXML view with a list that covers the screen. Within
this list, I have multiple list items displayed as itemrenderers.

Now, each list item has different "click" areas on it - for example, if you
tap the "X" on the far right, it will delete the list item, if you click
the ">" area of the list item, it will play the item's function, if you
click on the rest of the item, it will bring up an edit window wherein one
can edit the details of the list item.

Because of these multi-function items, I can't use the list's native item
selection and click handlers, instead I have to handle the item's functions
from within the itemrenderer (perhaps this is where I go wrong, but this
seems to be the only way)

Now, within the item renderer, I have something like this:

private var LIV:ListItemsView;

protected function initializeHandler(event:FlexEvent):void{
    this.LIV = this.parentDocument.parentDocument as ListItemsView;

protected function openItemEdit_clickHandler():void{
  this.LIV.openItemEdit(this as ListItem);

protected function deleteMedia_clickHandler(mediaObj:Object):void{

protected function deleteItem_clickHandler():void{
  this.LIV.removeListItem(this as ListItem);

And so on. So, my question is - by calling functions of the parent view
from within the list item's itemrenderer, am I creating garbage collection
problems? Second - is there a better way to handle this, or is this legit?

Thanks :)

*Thomas Wright*
Software Engineer
Extension: 1054
Office: [801] 464.4600

Corporate Division

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message