Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>As far as I can tell from the code you show, the easiest solution to your problem would be to work with two separate ItemRenderers: one that renders text and the other that renders images. You can do this using the <a href="http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/spark/components/SkinnableDataContainer.html#itemRendererFunction" rel="nofollow">SkinnableDataContainer#itemRendererFunction</a> property instead of <code>itemRenderer</code>.</p> <p>The List with the new property:</p> <pre><code>&lt;s:List id="myList" dataProvider="{dp}" itemRendererFunction="getItemRenderer" /&gt; </code></pre> <p>The function that returns a factory for the right ItemRenderer.</p> <pre><code>private function getItemRenderer(item:Object):IFactory { if (item.msg_type == "text") return new ClassFactory(MyTextItemRenderer); if (item.msg_type == "image") return new ClassFactory(MyImageItemRenderer); } </code></pre> <p>In these two different ItemRenderers you can then display your data as you wish.</p> <hr> <p><strong>Edit:</strong> why it's OK that the <code>dataChange</code> event fires every time you scroll.</p> <p>There is in fact nothing wrong with your approach as you describe it, although I would argue that the <code>itemRendererFunction</code> approach allows for better separation of concerns. I could tell you that you can turn the unwanted behavior off, simply by setting the <a href="http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/spark/components/List.html#useVirtualLayout" rel="nofollow">List#useVirtualLayout</a> property to <code>false</code>.</p> <pre><code>&lt;s:List id="myList" dataProvider="{dp}" itemRenderer="myItemRenderer" useVirtualLayout="false" /&gt; </code></pre> <p>Though this will do what you ask for (i.e. create the ItemRenderers only once), that would not be good advice. There is a good reason this property is set to <code>true</code> by default. </p> <p>When virtual layout is used, item renderers are created only as they are needed, i.e. when they come into view and need to be displayed to the user. This allows you to load thousands of items without performance loss. </p> <p>Let's say you load 1000 value objects: that doesn't take up much memory or CPU. But now you want to render them. If you don't use virtual layout an item renderer will be created for all of them up front, which means thousands of graphic elements and thousands of event listeners (how many exactly depends on your setup). Now <em>that</em> is going to hurt performance on a slow computer.</p> <p>If you do use virtual layout only - say - 10 item renderers will be created at once. If the user scrolls down, the next 10 will be created and the ones that just disappeared from the view are removed and eventually garbage collected. So you see: what you may have perceived as something that was bad for performance at first, is actually a very good thing.</p> <p>So I would advise you not to do what I just told you. Unless perhaps you would have a situation where you knew there would never be more than a very limited number of items in your List. Then you may consider not using virtual layout.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload