itemRendererRecycler.update is weird

edwinliang

please uncomment the test area, 'haha' will output 8 times in console

import feathers.layout.VerticalLayout;
import feathers.data.ArrayCollection;
import feathers.data.ListViewItemState;
import feathers.controls.Label;
import feathers.controls.dataRenderers.LayoutGroupItemRenderer;
import feathers.utils.DisplayObjectRecycler;
import feathers.layout.VerticalLayoutData;
import feathers.controls.ListView;
import feathers.layout.TiledRowsLayout;
import feathers.controls.Application;

class UIWApp extends Application {
	public function new() {
		super();

		// recycler.update is weired
		// please uncomment the test area, 'haha' will output 8 times in console
		//---- test-start ----//
		// var viewLayout = new VerticalLayout();
		// viewLayout.gap = 1;
		// layout = viewLayout;
		// layoutData = new VerticalLayoutData(100, 100);
		//---- test-end ----//

		var iconTileView = new ListView();
		iconTileView.backgroundSkin = null;
		iconTileView.layout = new TiledRowsLayout();
		iconTileView.layoutData = new VerticalLayoutData(100, 100);
		var recycler = DisplayObjectRecycler.withFunction(() -> {
			var itemRenderer = new LayoutGroupItemRenderer();
			var label = new Label();
			label.name = 'label';
			itemRenderer.addChild(label);
			return itemRenderer;
		});

		recycler.update = (itemRenderer:LayoutGroupItemRenderer, state:ListViewItemState) -> {
			var label = cast(itemRenderer.getChildByName("label"), Label);
			label.text = state.data.text;
			trace('haha');
		}
		iconTileView.itemRendererRecycler = recycler;
		addChild(iconTileView);

		iconTileView.dataProvider = new ArrayCollection([{text: 'test1'}]);
	}
}

joshtynjala

This is normal behavior, actually. There are a couple of things that are resulting in multiple calls to update().

1) The ListView validates twice. This will lead to update() being called at least twice for each item renderer too.

First, VerticalLayout used by the Application needs to validate the ListView once to get its ideal height measurement. Though you set percentHeight to 100.0, the final calculated height may be affected by the heights of other children in the container. Later, when percentHeight is used to calculate the final height of the ListView, the ListView needs to validate a second time. I suppose that VerticalLayout could be optimized for the case where only one child is added to the container, but honestly, it's not really that expensive.

If the ListView will be the only child in the container, you may be able to use a different layout instead of VerticalLayout in the Application, if you want to avoid the second validation. AnchorLayout might be a good choice because it also supports percentWidth and percentHeight.

2) When a scrolling container (such as a ListView) validates, it needs to measure its content to determine whether scroll bars are required or not. This tends to be more expensive on desktop than on mobile because desktop scroll bars force the content to be resized when they are displayed, while mobile scroll bars are simply displayed on top of the content without resizing it.

Validating a scrolling container basically has two passes. First, to measure the content, which involves determining whether scroll bars are required or not. Then, to apply the final layout based on the scroll bars. Due to certain quirks that I'm not going to dive into right now, it may measure the content twice before applying the final layout. So that's actually three passes. 3 * 2 = 6.

For some reason, the first validation of the ListView needs an extra measurement and layout. I don't have time to explain exactly why this is happening, but this results in two more calls to update(). 6 + 2 = 8. (It may be possible for me to optimize away these last 2 updates in a future version of Feathers UI, actually).

edwinliang

Thanks for your explanation in detail

Zeus25971

Not sure if open a new thread or asking it here (feel free to move it whenever you consider it). But regarding the itemRendererRecycler. I just found that there is no Destructor method to override (at least is not documented and I peeked (not in deep ) the lib code but I couldn't find it ). That should be extremelly important, I have several listeners inside the inherited class, and will remain in memmory if I can't destroy it correctly.

joshtynjala

DisplayObjectRecycler has a destroy method. This is called to clean up an old item renderer when it won't be used by the ListView anymore.

However, there is currently one issue that needs to be resolved in a future update to Feathers UI. The destroy method is not currently guaranteed to get called in all cases when the ListView is no longer used. Currently, to ensure that it gets called, you must set the itemRendererRecycler property to a new value, and validate the ListView.

listView.itemRendererRecycler = DisplayObjectRecycler.withClass(ItemRenderer);
listView.validateNow();

You mention an "inherited class", though, and that makes me think that you aren't adding listeners inside the DisplayObjectRecycler.create method. In that case, it wouldn't make sense to use DisplayObjectRecycler.destroy. Most likely, you should add an Event.REMOVED_FROM_STAGE listener inside your custom item renderer class, and remove any listeners that might cause a memory leak in there. If you make that change, you'll probably want to add the listeners in an Event.ADDED_TO_STAGE listener instead of the constructor or initialize() (assuming that's where you added them previously).

Zeus25971

Hello. That;'s great. Not sure how I would implement it doing but Event.REMOVED_FROM_STAGE gave me the path I am going to take. Thanks a lot.