List Efficiency

Following the examples I've been able to find, I've implemented an enyo.List, however, it sometimes causes elements that I know haven't changed to be refreshed (called from onSetupItem()).

I'm wondering if there is any way that I can avoid updating the item if I know it hasn't change? For example, is there a return value, or a flag, or is there is some other good way to handle it?

Currently I'm trying to replace data entries with the processed results, so I don't have to do any expensive data parsing again, but it still means changing contents or generating new components, so I'm wondering if there's a better way?

Comments

  • The way updates to items work in List is a little bit complicated. There are only so many items rendered at any time. There are two "pages", which each contain a number of rendered items. If you scroll down through the list, eventually the page at the top scrolls off, and is re-created below the former "bottom" page, then when that page scrolls off the top, it gets re-used as the next page down, etc, etc.

    So, if you scroll far enough down in the list, and then scroll back, you will get onSetupItem called for items you've already created before. There's no shortcut to be had here, because the List doesn't keep a copy of the data for the rendered items. Your application code is responsible for re-creating the items on demand.

    You can set the rowsPerPage property on the List, to tune the behavior to sove extent. A larger page size means that you have to scroll farther to cause the list to re-render items, but comes at the expense of greater latency when you actually do render.

    If you have a relatively small number of items, and rendering them is slow, then a Repeater is probably a better choice than a List.

    Other than scrolling items off the top/bottom, or resizing the List, you shouldn't see onSetupItem getting called arbitrarily. If you have a case where that's happening, I'd be interested in seeing it.
  • Thanks for the detailed explanation! In that case I'll just focus on swapping items in my data structures for the processed versions once they've been generated, this way setupItem() should only involve a quick setContent() or whatever, should save on memory at least since a ton of the data I'm dealing with is extraneous =)

    Never mind the comment about extra setupItem calls, I think that was a bug of mine instead,
  • There's an implicit assumption in List that whatever you do in onSetupItem needs to be very fast. We should probably be more specific about that.

    That method may get called called hundreds of times a second when you're scrolling very fast.
  • edited August 2012
    Tapping on a list item may also trigger a setupItem event -- it does that so you can update it with a highlight or other styling for the currently selected item (plus another setupItem to un-highlight the previously selected item), and it does it even if you don't actually need or want selection support (ENYO-603).
Sign In or Register to comment.