Deep Dive into Flex Mobile Item Renderers

Editor's Notes

• #2: Welcome to Deep Dive into Flex Mobile Item Renderers.\n
• #3: My name is Jason Hanson. If you are interested in learning more about me, what I do, or have questions after this presentation please feel free contact me via Twitter, my blog, or web site.\nA little about me. I have been building for the Flash Platform since 1999, back when I used FlashScript and really had no idea what I was doing. I have stuck with the platform for the past 10+ years, started working with Flex Builder 2 when the beta came out and have been building projects with Hero / Burrito since August of 2010.\n
• #4: \n
• #5: If you bet bored during the presentation and want to look at some of the code samples you can check out some stuff I posted up at my web site. There are also some Android APK files there you can install and play with on your Android 2.2 device running AIR 2.6.\n
• #6: \n
• #7: There is a new project type in Flash Builder 4.5; Flex Mobile Project. This type of project should be selected when building Mobile Flex applications that will take advantage of the mobile-optimized Spark components. This session will focus on targeting AIR for Android. \nEverything I am going to talk about from this point forward assumes that you are working with Flash Builder 4.5 and Flex SDK 4.5 (v. i6 or greater) with code in a Flex Mobile Project. Certain new classes and skins are included in only the mobile libraries that are added to the class that when creating a Flex Mobile Project.\n\n
• #8: Many of the components used in mobile Flex development are the same as the Spark components you use for any app. The mobilecomponents.swc contains components and skins that have been optimized specially for mobile use-cases. You do not need to learn a whole new component set.\n
• #9: So, rendering a list of items is hard. There are all those little images and little bits of text, star icons, etc. \nNot only do you have to render all that for one item, you usually need to support anywhere between 1 item and 10,000 items. Yes, my QA team always seems to run a test with 10,000 list items ...\nNext Slide.\n
• #10: Scrolling a List of Items is Harder.\nNow, after you have the list rendered the user is going to want to scroll it. And that is where the problems start. Scrolling on a modern computer is pretty straight forward these days. Mostly we just brute-force our way through it all and don’t have too many issues. \nWhen it comes to mobile our computing resources often very restricted, AND the users get to use their fingers to swipe scroll. Instead of just ‘click to scroll up’ / ‘click to scroll down’ actions, we need to support a crazed 14 year old treating our scrollable list as practice for some new finger breakdancing fad that I, unfortunately, will never be cool enough to perform.\nBottom line, users expect immediate response to tactile gestures.\n
• #11: I cannot stress enough how important smooth and responsive scrolling is for the lists in your apps. A poorly written itemRender can ruin a whole app. If you only have time / budget to optimize one part of your application I strongly suggest spending the time writing efficient and fast itemRenderers\n
• #12: \n
• #13: If you have written components before, or read about component lifecyle, you may know that there is a whole list of ‘stuff’ that happens when RENDER kicks off. Some of that ‘stuff’ can be really expensive.\nThat is fine if I am doing it once, but if I am doing it 30 times a second for 6 items at a time I start to run into trouble. Every line of code in my ItemRenderer may be firing off over 100 times a second during a quick scroll of a long list. It is important to make every line of code count.\nNote that in the code we will be looking at today updateDisplayList() calls both drawBackground() and layoutContents() to make each easier to override without having to duplicate as much code as you would in overriding updateDispalyList() (Thanks! Adobe SDK team!)\n
• #14: It turns out a regular Spark ItemRenderer written in MXML is just not fast enough to for most mobile devices. To get around this some smart SDK devs at Adobe spent months optimizing the Spark List scrolling behavior and creating new ItemRenderers optimized specifically for mobile. The scrolling performance you may have seen in the MAX builds last fall has greatly improved. The rest of this talk will go into that.\n\n\n
• #15: While the Spark class ItemRenderer.as is still a good choice for easily creating itemRenderers for desktop and web apps there are some things about it that are not a good fit for mobile. It extends Group, and that brings along a decent amount of baggage when it comes to layout. It also encourages use of relatively expensive convenience features like states, binding, and relative layouts. In the ItemRendererSample project you can see an example of an MXML ItemRender for comparison.\n
• #16: \n
• #17: Here are the stars. Shiny new classes to learn about. During the beta process documentation really did not keep up with the code that was been written / changed each iteration. So, I just dove right in to reading the SDK code line by line to see what was going on. Building custom mobile item renderers is much easier now then it was in the early builds thanks to an attentive and responsive dev team at Adobe many of the pain points have been resolved. Hopefully I can save you some of the pain I went through today by explaining what these new super-star classes do and how / when to use them. If you get nothing else of of this session today hopefully it will be the names of these classes to read up on later.\n
• #18: Let’s look at some code. I am going to show off the code for the itemRenderer we saw a few slides back, do a quick tour, and then dive into the new classes I just mentioned. \n(show MobileShoppingCart > ItemPreviewImageRenderer.as)\n\n
• #19: Ahh, my good old friend TextField. For all the wiz-bang features that TLF text primitives have to offer TextField performs better in lists on Mobile. StyleableTextField adds a few handy features. Like \nsetting a styleDeclaration or styleName.\n
• #20: Exposes setting of the styleName property and the setStyle() method to easily change the style of the text.\n
• #21: The default itemRenderer for lists in mobile is the LabelItemRenderer. It was created specifically for rendering text in a List.\n
• #22: Here is an example of what the LabelItemRenderer looks like with default styles. \nTake a look at the way the itemRenderer is declared in MXML. This is a very convenient way to set styles and properties on your itemRenderer without impacting performance. Please note that this is different then writing an entire itemRenderer in MXML syntax. This code only instantiates the AS3 component. This is a great place to set the styles.\n
• #23: Base component that does not bring as much baggage that ItemRenderer does by extending from UIComponent.\nThere is rather limited support for styles. If it is not in the list above, the style is probably not supported. You may be able to set it in MXML or CSS, but it will do nothing at runtime.\nNothing too fancy, just renders that data property as a String. \n
• #24: Use IconItemRenderer when your item renderer has an image. Notice it extends from LabelItemRenderer\n
• #25: Here is an example of what the default IconItemRenderer might look like. Notice the image on the left is the ‘icon’ and the image on the right is the ‘decorator’.\nNotice the convenance of setting properties on the itemRenderer when instantiated in MXML syntax.\n
• #26: \n
• #27: I am not going to get too far into BitmapImage, but just be aware that it is a high performance component that performs well in mobile itemRenderers. It does not extend from DispalyObject and is a bit tricky to use. \nSide Note: using Image component, or wrapping BitmapImage in a Group is a simpler way to go, just a bit less optimal. \n
• #28: Last in, first out cache system added to Flex Framework. It is used to cache the bitmaps loaded in IconItemRenderer. If you have had to load lots of images in Flex before you probably have written a similar caching system in the past. Nothing super-fancy here. Note, however that it implements IContentLoader so that it can be used as ‘source’ value for Image components.\nYou can set the iconContentLoader to a ContentCache instance on IconItemRenderer.\n
• #29: Usage from IconItemRenderer. The imageCache object is set to the iconContentLoader so that images that get loaded are also cached. Handy!\n
• #30: \n
• #31: \n
• #32: If your itemRenderer has more then two bits of text and two images you will need to make a custom one. You have some options here. If your itemRenderer will be similar to either LabelItemRenderer or IconItemRenderer I recommend extending that class. Otherwise start with UIComponent and follow the structure of one of those default item renderers.\n
• #33: Component written in AS3 tend to perform better as item renderers when compared to components written in MXML. Use AS3. LabelItemRenderer and IconItemRenderer are highly optimized component, take advantage of what you can from those classes by extending or copying.\n
• #34: So I built a custom item renderer. I showed it in a screenshot a few slides back. I am going to detail out how I went about that.\nFirst I decided to extend IconItemRenderer since it would be easy to reuse some of the displayObjects. Next I wrote a custom component for displaying the star rating.\n
• #35: \n
• #36: \n
• #37: \n
• #38: \n
• #39: \n
• #40: set defaults in constructor\noverride createChildren()\noverride createLabelDisplay()\noverride createMessageDisplay()\nset labelFunction\nset messageFunction\nset iconFunction\noverride layoutContents()\noverride measure()\n
• #41: \n
• #42: \n
• #43: setElementSize() and setElementPosition() are helper methods that underneath the hood call the appropriate methods to change the size or position -- setLayoutBoundsSize() / setLayoutBoundsPosition() in many cases. Alway try to use these methods when resizing or positioning components.\nAlways call setElementSize() before setElementPosition()\n
• #44: \n
• #45: \n
• #46: \n
• #47: \n
• #48: \n