My colleagues from the Enterprise team were busy updating the Tour de Flex application to Flex 4.6 and they have published it to Android Market and the Apple App Store.

What’s cool about this project is that it is a three-in-one type of product: you can learn how to use Flex, you can experience the performance of the Flex framework on mobile devices firsthand, and you can check the source code and learn how to build awesome mobile projects. Here is the project home page and you can get the source code from here (you’ll need Flash Builder 4.6 to import the project).

And if you’re looking for the app on the stores search fom “Game of Flex” and not Tour de Flex!

I’ve been receiving a number of emails on this topic lately. It seems there is little information out there about how to move from development to production with a Flex and PHP application. Here is a simple checklist that could help you, especially if you are doing this for the first time. Please note that I presume you used the Data Services (wizards) to connect the Flex client to PHP services.

1. Make sure you have Zend Framework on your server. If you don’t, install it
2. Make sure you change MySQL credentials and server IP/name used by your PHP scripts to connect to the database
3. Copy the PHP services folder to your server. Then test these services. If they don’t work check the MySQL credentials or look for dependencies (maybe your PHP services use other PHP classes that you forgot to copy to your server)
4. Edit the amy_config.ini file and make sure the path to the Zend Framework is OK and set production to true
5. Edit the Flex services to point to your live server gateway.php. In the services folder of your Flex project you will find _Super_something.as files. In the constructor you will find a line like this:

   _serviceControl.endpoint = “http://localhost:10088/MobileFlexPHP-PHP/public/gateway.php”;
   Copy that line and then open the class that extends this _Super class and paste the line in the constructor. Then change the URL to reflect your server setup

6. Copy the bin-release/ folder to your server (you should choose the export release for your project; this will create a SWF file smaller than the debug version)

That’s it! If I missed something please drop a comment!

As many of you probably know we made a few announcements last week that are quite interesting – let’s put it that way :). What made things even more interesting for Ryan and me is that we were right in the middle of the tour on mobile development (and we are still on tour for that matter). So we got your feedback first hand.

The good news is that last night the Flex team posted an update that adds more context and details about how Adobe plans to move Flex to Apache Software Foundation. And in short the essence of this update is that we still support Flex and Flash Builder; they won’t go away and we are not killing them. Here are some quotes from the post:

What specifically is Adobe proposing?

We are preparing two proposals for incubating Flex SDK and BlazeDS at the Apache Software Foundation.

In addition to contributing the core Flex SDK (including automation and advanced data visualization components), Adobe also plans to donate the following:

• Complete, but yet-to-be-released, Spark components, including ViewStack, Accordion, DateField, DateChooser and an enhanced DataGrid.
• BlazeDS, the server-based Java remoting and web messaging technology that enables developers to easily connect to back-end distributed data and push data in real-time to Flex applications.
• Falcon, the next-generation MXML and ActionScript compiler that is currently under development (this will be contributed when complete in 2012)
• Falcon JS, an experimental cross-compiler from MXML and ActionScript to HTML and JavaScript.
• Flex testing tools, as used previously by Adobe, so as to ensure successful continued development of Flex with high quality

Adobe will also have a team of Flex SDK engineers contributing to those new Apache projects as their full-time responsibility. Adobe has in-development work already started, including additional Spark-based components.
Isn’t Adobe just abandoning Flex SDK and putting it out to Apache to die?

Absolutely not – we are incredibly proud of what we’ve achieved with Flex and know that it will continue to provide significant value for many years to come. We expect active and on-going contributions from the Apache community. To be clear, Adobe plans on steadily contributing to the projects and we are working with the Flex community to make them contributors as well.

You can read the whole post/update here. And drop a comment if you have something to share!

There are many places where you can optimize your code especially when working on mobile applications. In this post I will focus on caching images using the spak.core.ContentCache class (part of the Flex framework).

Right from the Flex documentation, you can see ContentCache could be useful:

Provides a caching and queuing image content loader suitable for using a shared image cache for the BitmapImage and spark Image components.

Why cache images?

So why would you cache images? Every time you set a new source for a Spark Image or a BitmapImage object a new flash.display.Loader object is created to load the image bytes.

Now, let’s suppose you display a list of items and each item has an image (could be an icon or could be a picture). Each image is hosted on a remote server so it has to be downloaded. Finally, some of these images are the same for different items in the list (for example for a Twitter client it is quite common to see many entries with the same avatar; each entry represents a tweet from the same user and the avatar is the same in this case).

If you don’t use a caching mechanism, you will notice that as you scroll through the list it will take some time to load images. And the same could happen for images stored locally especially if they are not very small. While waiting for images to load and be displayed the first time is OK (and there isn’t much to do other than preload them) waiting for the same image every time it is displayed is quite annoying.

Here comes the ContentCache class. This class stores the bytes loaded (actually it stores the LoaderInfo object used for loading each image) and every time an image must be loaded it first checks the cache; if is not there then it goes through the loading process. If it is cached already, then it provides the LoaderInfo object.

How do you use the ContentCache class?

You can enable caching for your Spark Image or BitmapImage objects quite easy. All you have to do is to create an instance of ContentCache and set this instance to the contentLoader property of the BitmapImage or Image object. Other than this, it’s business as usual. When you want to load an image you just set the source property of the Image or BitmapImage object and the ContentCache object will take care of the rest.

There is one thing you must be aware of: if an image was changed after it was cached and the source is the same then you have to invalidate the cache yourself in order to see the new image. Otherwise you will see the old version. When you want to remove an image from the cache you use the removeCacheEntry() method and pass the source for the image you want to invalidate in the cache.

You control the number of cached images using maxCacheEntries property (the default value is 100).

Let’s see a simple example:

private var cache:ContentCache = new ContentCache();

private function setImage(source:String):void {
   //if we didn't set the cache
   if ( !img.contentLoader ) {
       img.contentLoader = cache;
   }
   //set the image source
   img.source = source;
}
...
<s:Image id="img"/>

Using ContentCache with Lists

The Flex framework has a built-in list item renderer that supports images: IconItemRenderer. This is perfect for displaying lists that have images and text. By default the IconItemRenderer uses a ContentCache object to cache the images. However the ContentCache instance is not shared across all the item renderers.

What do I mean? A Flex mobile list uses virtualization. This means that if the list displays 10 items at once it will create about 11 item renderer instances and reuse them. So even if the list has 1,000 items to display only 11 item renderers will be created. Next, each item renderer instance will use a ContentCache instance to cache the images. So in total there will be 11 ContentCache instances. This means that it could happen to have an image already displayed by the list but because it was cached by a different ContentCache instance than the one used by the current item it will be loaded again.

The IconItemRenderer class uses a static property to hold an instance of the ContentCache. This means that the same image cache will be used by your list. However, if you have a second list or you use multiple item renderers for the same list, by default, it will be used another instance of ContentCache. The easiest way to fix this is to first create a single ContentCache instance (you can use the Singleton pattern here):

Then you extend the IconItemRenderer and set this Singleton as the contentLoader object:

When you build from scratch a list item renderer that uses images, you can use the same approach.

Obviously this technique can be used for other places as well not only for lists.

Drawbacks

As with any caching or pooling technique there are trade-offs. You have to find a fine balance between not caching any images and caching all the images. By default the ContentLoader is set to cache 100 entries. But this doesn’t mean that it is the best value.  It all depends on how big the images are and how much memory you want to use for caching. So be sure you take this into consideration when caching images.

Ever wondered how to create a modal dialog window in Flex mobile applications? For example, you may want to ask the user for a confirmation when he performs a delete operation or maybe to select an item from a list. Well, if you don’t know how to do it, then read on.

Flex has a class that just does this: SkinnablePopUpContainer. SkinnablePopUpContainer extends SkinnableContainer class and has a very simple API you can use in order to “open” and “close” the dialog.

Understanding SkinnablePopUpContainer

Because SkinnablePopUpContainer extends the SkinnableContainer it is extremely easy to create any kind of dialog window you want. You can create a new MXML component that extends the SkinnablePopUpContainer. Then you set a layout manager that works for you (VerticalLayout, HorizontalLayout). And finally, you add the UI components you need – labels, buttons, lists, and so on.

Suppose you want to create a simple alert window that looks like this:

Here is the code to implement this (as a new MXML component that extends SkinnablePopUpContainer):

<?xml version="1.0" encoding="utf-8"?>
<s:SkinnablePopUpContainer xmlns:fx="http://ns.adobe.com/mxml/2009"
    xmlns:s="library://ns.adobe.com/flex/spark"
    backgroundColor="0x898989">

    <s:layout>
        <s:VerticalLayout horizontalAlign="center"/>
    </s:layout>

   <s:Label text="The contact was saved" width="100%" textAlign="center"/>
   <s:Button label="OK" width="100%" click="this.close()"/>
</s:SkinnablePopUpContainer>

The API for controlling the SkinnablePopUpContainer is pretty simple:

• To open or display the window you create a new instance and then call the open() method of SkinnablePopUpContainer. This method has two arguments. The first argument is the display object container where it will be created. The second argument is a flag that tells Flex if the window will be modal or not.
• To close the window and send data from the window to the application you use the close() method of SkinnablePopUpContainer. This methods also has two arguments. The first argument is a flag. You can set this to true if, for example, the user clicked the OK button, and false otherwise. If you want to send some data back to the application you use the second argument. For example, if you have a TextInput in your dialog and you want to send the text you will use this second argument.
• To listen for the close event and read the data sent from the SkinnablePopUpContainer you have to register an event listener on the SkinnablePopUpContainer. The event type is PopUpEvent. PopUpEvent has two properties that you can use to read the flag and data set when calling the close() method: commit and data.

Here is an example of how to open a SkinnablePopUpContainer component and read the flag/data when it is closed:

//create the component and open it
var alertWindow:SkinnablePopUpContainer = new SkinnablePopUpContainer();
alertWindow.addEventListener(PopUpEvent.CLOSE, onAlertClose, false, 0, true);
alertWindow.width = stage.width;
alertWindow.height = stage.height / 2;
alertWindow.x = 0;
alertWindow.y = 100;
alertWindow.open(this, true);

private function onAlertClose(event:PopUpEvent):void {
    trace(event.commit);
    trace(event.data);
    alertWindow = null;
}

Creating custom dialog windows

Once you understand how to use the SkinnablePopUpContainer it is pretty simple to create any kind of dialog window you might need: confirmation messages, simple alerts, pop up lists, and so on. Here is the code for a confirmation window that has two buttons (Yes and No) and lets you set the message text:

And here is how this component look on my Android phone:

And here is the code for a pop up list that lets you to set the title, the list’s data provider, the list’s label field, the list’s initial selected items, and multiple selections (you can retrieve the selected items by listening for PopupEvent.CLOSE and reading the data attribute).

And here is the component running on my phone:

Skinning

The two custom dialog windows I showed you in the previous section use the default look and feel. What about skinning a SkinnablePopUpContainer? There is a Flex class that provides the default skin for a SkinnablePopUpContainer: SkinnablePopUpContainerSkin. By creating a skin that extends this default skin you can change the background of the component quite easily. If you look at the SkinnablePopUpContainerSkin skin you’ll notice that it has a rect with the id equal to background. This is the starting point to change the default background. You can draw additional stuff on top of this background or replace it alltogether with an FXG or PNG file.

For the rest of the UI components used in a SkinnablePopUpContainer (buttons, text inputs, labels, and so on) you will create additional skins and/or use CSS. Here is a screenshot with the same confirmation window but this time using a custom skin:

Here is the skin class used to customize the confirmation window presented in the previous section:

And this is the FXG used by the skin class to draw the background:

Download

You can download a working Flex project that includes all the code used in this article from here.

This is the second part (and the final one for that matter) of my post about creating Flex mobile lists (you can read the first part here). In this post I will show you how I modified the custom layout manager that I created in the first post to add support for virtualization. Also I will discuss the theory behind Flex list virtualization and creating custom item renderers.

As a reminder, in the first part I talked about you how you can create a custom list and layout manager that can be used for displaying vertical and tile section lists:

In this post I will show you how you can create layout managers that support virtualization and custom item renderers. You can see the two custom item renderers below:

I won’t discuss how I created the custom list component to support sections. For this read the first part of this series.

Layout Manager with and without Virtualization Support

So what does virtualization mean in the context of Flex lists and why is virtualization important? Suppose you have 100 items in a list and at any given time you can see no more than 20 items (to see the rest of the items, you have to scroll the list up or down ). If the layout manager used by the list doesn’t support virtualization then all the 100 items are rendered. The next image illustrates the concept.

A list that uses a layout manager that supports virtual layout renders only a limited number of items (typically equal with the number of items that fit in the list’s view port). When the list is scrolled, the item renderers used by the items that were moved out of the view port are recycled to render the items that just entered the view port. The next image illustrates the concept:

As I explained in the first part, if you have relatively few items (tens) you’ll get excellent performance using a layout manager without support for virtualization. However, in the next screencast I will show you what happens when you have 1,000 items in your list and you don’t use virtualization (all 1,000 items are created at once).

In the next video, you can see the same list and 1,000 items but this time using virtualization. As you can see, the list is created almost instantly as opposed to taking 5 or 6 seconds as in the previous video.

Creating a Custom Layout Manager

Let’s see how I created the layout manager you’ve seen in the previous videos. When you want to create a layout manager you have to override/implement at least two methods: measure() and updateDisplayList().

Using Virtualization

Now, let’s discuss what it is happening in terms of methods that are executed when you have a layout manager that uses virtualization.

First, your list component is instantiated and when the list’s DataGroup.validateSize() method is called the layout manager’s measure() methods gets called. The validateSize() method is executed at least once (when the list is created) and this represents the second pass of the layout (the first one is DataGroup.commitProperties()).

Next, as the DataGroup.validateDisplayList() method is executed (every time the list display list is invalidated) it will call the layout manager updateDisplayList() method.

So what to do you do inside of these two methods (measure() and updateDisplayList())?

measure()

You use the measure() method to calculate the total height/width of the list’s DataGroup and set these values back to the DataGroup. Remember that all the items that can’t be fit in the view port are clipped. To see them you have to scroll through the list. Well,  in order to get the scrolling to work correctly (this means that the size of the thumb is proportional to the number of items and you can scroll up to the first item and down to the last one) you have to calculate the total size occupied by all the elements as if all of them would be rendered. The catch is to do so without instantiating any item renderers.

My custom layout manager has properties for section title height, regular item height, and width. So these values are set by the programmer. This means, that I used these properties in the measure() method. You also need the data items. Remember that my list uses two different ways to render the data depending on type (section title or not). You can access the list data provider like this:

var dataProvider:IList = (target as DataGroup).dataProvider;

So, in my layout I loop through all of these items and calculate the total height (for a layout manager like Vertical Layout with items that have the same size, you wouldn’t need to loop through all the items; for example, you can multiply the height of one item by the total number of items in order to calculate the total height).

If you want to use the current size of the view port you can read the target.width and target.height properties. Take care when doing this because depending on the life cycle state of your list these values can be zero sometimes.

Once you calculated the total height and width you can set them to the DataGroup by calling:

target.setContentSize(totalWidth, totalHeight);

Here is the complete code for the measure() method (please note that the method is executed only when useVirtualLayout is set to true; otherwise I exit at the top of the method body):

updateDisplayList()

When the layout manager uses virtualization, the updateDisplayList() is called everytime you scroll through the list. Actually, when you scroll, first the scrollPositionChanged() method is called and if inside this method the target.invalidateDisplayList() method is called, then the updateDisplayList() method will be called. I will talk about the scrollPositionChanged() method in the next section.

The updateDisplayList() is called with two arguments: the width and height of the DataGroup view port. Inside of this method you will position and resize the items you want to display. Because we are talking about a virtual layout, you will not resize and position each element of the list. Ideally you will work only on those that are in the current view.

As you can imagine, the difficulty is in determining what elements must be displayed. The way I solved this is pretty simple. In the measure() method, when I loop through all the items, I save the correspondence between an item and its y value and between a y value and a data provider index (where the y value moves from 0 to the total height of the DataGroup content area).

How do you position and resize an item? You can use the ILayoutElement interface (the layout manager target property has a method named getVirtualElementAt() that you can use to retrieve one item):

// get the current element, we’re going to work with the
// ILayoutElement interface
element = target.getVirtualElementAt(i);

//resize the element
element.setLayoutBoundsSize(elementWidth, elementHeight);
// Position the element
element.setLayoutBoundsPosition(x, y);

Here is the complete code for updateDisplayList() when useVirtualLayout is set to true:

scrollPositionChanged()

The final piece of the puzzle is the scrollPositionChanged() method. As I already said, this method is called every time the list is scrolled. You can find the current view port’s x and y properties by using the getScrollRect(). This method returns a Rectangle instance. Then you can read the top and bottom properties of the Rectangle instance to find where the DataGroup content is scrolled. For example:

var r:Rectangle = getScollRect();
var yTop:Number = r.top;
var yBottom:Number = r.bottom;

Then, using the values I saved when the measure() method was executed I can find the index of the the first item to be displayed and the index of the first item on the last visible row. I save these indexes and if they are outside of the indexes I rendered during the previous call to updateDisplayList() I invalidate the DataGroup display list, which in turn will call the layout manager updateDisplayList() method (and here I will use the two indexes I calculated in the scrollPositionChanged() method).

Please note that you can play around with these two indexes. For example you can add another row before the first visible row and one after the last visible row if you want to optimize small and unintended scroll actions (for example, you won’t execute the updateDisplayList() method if the list was scrolled 10 or 20 pixels).

Here is the complete code of scrollPositionChanged() (notice that it is executed only when useVirtualLayout is set to true; otherwise I just call the parent scrollPositionChanged()):

For the complete code of this layout manager please check the Download the code section of this post.

Without Virtualization

I enabled the same layout manager to work as one without virtualization support. As I said, there are situations when you prefer such a layout.

measure()

When the layout manager works without virtualization support, the measure() method does nothing (you have to implement it though if you extended BaseLayout; failing to do so will trigger a runtime error).

updateDisplayList()

This is where the heavy lifting will happen. This method will loop through all the items and position and resize each one. This method is executed only once as long as the DataGroup display list is not invalidated (you don’t change the list size or data provider for example).

Also, you have to set the DataGroup content size in order to enable scrolling on the list:

// Scrolling support – update the content size
target.setContentSize(width, height);

Here is the code:

scrollPositionChanged()

Again nothing to do here. You just call the super.scrollPositionChanged() method.

Creating Custom List Item Renderers

It is important to create item renderers that are extremely efficient. Otherwise all the work you put in creating and optimizing the custom layout manager will be for naught. For mobile development there are two built-in item renderers, both implemented using ActionScript. As a rule of thumb you don’t want to use MXML for graphics to create item renderers. Instead use FXG, bitmaps, and ActionScript.

The item renderers I created are designed to work with lists with or without sections. As I explained in the first part of this series, depending on the type of a data item (it either has a section property or it doesn’t) it is rendered differently.

Here are the methods you will most likely touch when developing custom item renderers:

1. set data(). I override this method so I can check if the data to be set is a section title or not. Depending on this, I change the font styles and the value of the label property.
2. createChildren(). This method is called automatically when an item renderer is instantiated. And this is where you create the parts you need. In the case of one of the item renderers I created, I only had to create an Image and a Sprite (the label part is created in the class I extend, LabelItemRenderer).
3. updateDisplayList(). This method is called automatically when the item renderer is added to the DataGroup display list or the invalidateDisplayList() method is called. Inside of this method you can size and position the various parts. This method executes the following methods (in this order): drawBackground() and layoutContents(). If you draw on the background of the component using its graphics object then you have to call graphics.clear() before redrawing anything.
4. drawBackground(). This method renders the background for the item renderer. For example this is where the different color for marking an item selection is drawn.
5. layoutContent(). This method is used to position the children. You can use setElementPosition(child, x, y) or setElementSize(child, width, height).

For the project I worked on, I needed two different item renderers for the same list. Both item renderers must support two different appearance: one for a section title and one for a regular item. The first item renderer I created extends the built-in IconItemRenderer. I had to extend it in order to support the section titles. Here is the code:

The second item renderer is just a simple “tile” for regular items. It displays an icon on top of the item and at the bottom, a label. I chose to extend the built-in LabelItemRenderer and add an Image and draw couple of things on top of the existing ones. Here is the source code:

You can watch this screencast to see these item renderers in action together with the custom layout manager and list:

And here is the same code running on my Nexus One:

Conclusions

I hope that I managed to shed some light on the dark art of creating custom lists/layout managers/item renderers. If you need to create something like this, I encourage you to take a look at how the built-in layout managers and item renderers were implemented. You will learn a lot. Also, especially when creating mobile applications try to use/extend the built-in Flex classes. The Flex SDK team put a lot of effort into optimizing this code. So you will get all the future improvements for “free”.

If you have created custom lists maybe you can drop a comment and share with us your work.

Download the Code

You can download all the code used in this series from my GitHub account.

For a mobile application I’m working on I need a section list. If you are familiar with the Flex framework you know that you don’t have built-in section list components (you can have vertical, horizontal, and tile lists). I played a little bit with the Flex List, IconItemRenderer, and BasicLayout classes and managed to put together two section lists: a vertical section list and a tile section list. In this post I will talk about how I did it and about some theory behind the list components.

What is a Section List?

Before talking about code, let’s establish what a section list is:

• It is a list that provides a way to render items grouped in sections. For example, if you have a data structure like “Fruits, Banana, Cherry, Kiwi, Cheese, Cheddar, Gorgonzola” a section list will render this data in a way that makes it clear that Fruits/Banana/Cherry/Kiwi is one section and Cheese/Cheddar/Gorgonzola is another one;
• The section title items can’t be selectable. In our example, clicking on Fruits or Cheese items will not throw a select event nor will it select the item;
• Section title items should be rendered so that it is clear they are different from regular items.

Here is an example of a vertical section list (blue items are section title items, the gray Blueberries item represents the current selection):

If you wonder why you’d need such a list, here are a couple of examples where you can find it pretty useful:

• You have a list of people and you want to display the items sorting alphabetically. By creating sections A, B, C, and so on users can easily navigate through the sections to find what they are looking for;
• You have a properties or preference page in your application with a bunch of options (for example, Editing, Account, and so forth). You can nicely organize the information so users can find their way quickly.

Some Theory Behind Flex lists

This is the boring section of this post :) If you don’t like it, feel free to skip it :D

Flex mobile lists inherit the architecture of the Spark components introduced in Flex 4 back in 2010. An oversimplified dissection of a Flex mobile list would reveal these “organs”: list component, DataGroup, Scroller, layout manager, and item renderer. By default a Flex mobile list is a vertical list (items are rendered vertically and if there are more than can be fitted on the view port than you can scroll the list up and down).

Here is a description of how these things work together:

• The list component uses a container for holding the items that will be displayed. This container is an instance of the DataGroup class.
• The DataGroup container implements the IViewport interface. If the items to be displayed don’t fit in the viewport, they are clipped.
• To scroll the viewport of the DataGroup and see the rest of the items, a Scroller is used. In the case of the mobile Flex list the Scroller displays a scrollbar only when you interact with the list (by default it is hidden). Its size gives a visual clue about the number of the elements from the list (the more elements in the list, the smaller the thumb).
• The list component uses a layout manager. This class is in control of how and where the items displayed in the DataGroup are rendered.
• Each item of the list is displayed using an item renderer. The Flex framework gives you two built-in item renderers for lists: IconItemRenderer and LabelRenderer. The item renderer class is in charge of how an item will be rendered on the screen. Lists are designed to work with a single item renderer.
• The list component has a property called dataProvider that you can use to set the data you want to display. Typically you’d assign to this property and Array or an ArrayCollection of Strings or Objects.
• Finally, mobile lists use virtualization (the virtualization part is implemented actually by the layout manager). This means that only the items that are visible in the viewport are rendered. And when the viewport is moved (for example, you scroll the list down) the item renderers of the items that were moved out of the view port are reused for the items that just got in the view port. This way, even on a mobile device, you can have lists with 10,000 items and you want run out of memory. However there is still a cost with this approach: the DataGroup has to execute a bunch of removeChildAt() and addChildAt() calls in order to reuse the item renderer instances.

I won’t get into details about how everything is linked together at runtime and what methods are called and when. I’ll save this for another post.

The first section list I wanted to create was a vertical section list. Let’s see how I implement it.

Creating a Vertical Section List

I looked at the built-in Flex mobile list and I realized that making a Vertical Section List would be quite easy. The VerticalLayout manager does all the work I needed, and the only things I had to change were:

1. Disabling item selection for list items that are section titles;
2. Finding a simple way to define the data provider structure (which data items are section title items and which are just regular items).
3. Extend one of the two built-in item renderers so I can have two distinct looks: one for section title items and one for regular items;

First, I decided on how to model the data provider used for the SectionList. I decided that I want to be able to use an Array or ArrayCollection of objects and I will use different properties to store the label for section title items and regular items.

Next, I created a new class that extends the Flex List class. In this class I override the item_mouseDownHandler() method. This method is executed each time you touch the list. So all I had to do is to check whether the item touched is a section title item or not. If it is, then I just call event.preventDefault() to cancel the selection.

Next, I added a property named sectionField to store the property name used for defining a data as an section list. Here is the code of the SectionList class:

Then I created a new item renderer by extending the built-in mobile item renderer IconItemRenderer. IconItemRenderer enables you to display more than just a label (you can have a decorator, an image, and a subtitle). To tell you the truth, I have used only the label. So, I guess I could have chosen the LabelRenderer as well.

The first thing I did was to override the set data() method. This method is called automatically everytime the item renderer class is used to render a data item. So this is the perfect place to check if the data that is about to be displayed is a section title item or not. Depending on the result I change the font alignment and weight and I change the labelField value to the property name to be used as the source of the text.

Next, I override the drawBackground() method. This method draws the background of the item. Depending on what data I have to render I change the color of the background.

Finally, I added three new properties that allow me to set the name of the property that holds a section title item, a regular item, and background color to be used for section title items: sectionField and normalLabelField.

Here is the code of the custom item renderer:

With all this sorted out, here is how you use the SectionList component in your code:

This example uses the data provider defined below. This is why I set the sectionField property of the SectionList and SectionListItemRenderer to “section“. You can see how the background color for section title items is set.

Defining the data provider:

Here’s a video with the list running in the Flash Builder desktop simulator and on my Android phone:

Creating a Tile Section List

A tile section list could be handy, especially on tablets. Because you have plenty of space on the horizontal axis you can fit multiple items on the same row and thus make better use of the available screen on the device. Here is an example of tile section list (the item renderer used here doesn’t do a good job of separating visually adjacent items):

If all you need is a tile list then you can use the Flex list with the built-in TileLayout manager.

With the vertical section list up and running all I had to do was to create a new layout manager. This layout manager lays out the items (starting from left to right and top to bottom) using these rules:

• If the item is a regular item and it is enough room to accommodate it on the current row it will draw the item next to the previous one;
• If the item is a regular item and there is not enough room to fit the item on the current row, it goes on the next row;
• If the item is a section title item it goes on the next row and fills is the entire view port width.

Fortunately, back in 2010, Evtim Georgiev (an engineer on the Flex SDK team) created a custom layout that was pretty close to what I needed. So I took this layout manager and modified it a little bit. The magic happens in the updateDisplayList() method. This method is called every time the display list of the List is invalidated (for example if you change the width/height of the list or when the list component is initialized). The two arguments of this method represent the view port’s height and width.

updateDisplayList() method is where you position and size the items. For my first run I chose to create a layout manager that doesn’t use virtualization. This means that updateDisplayList() will iterate over all the items you have in the list and create an item renderer for each one and then position and size the item. The layout manager positions the items in the DataGroup instance used by the list for displaying the items. The item renderer class implements the ILayoutElement interface. Using this API, the layout manager can set the width/height and x/y of each item renderer.

As I explained, the layout manager uses the whole width of the view port for section title items. For regular items, I added a property to the layout manager called columnWidth – so you can control how many items you can have on the same row.

Here is the code of this custom layout manager (I called it SectionListLayout):

The item renderer and list data provider are the same as the ones used for the vertical section list. I’m using the same SectionList I created earlier. Here is how I instantiate the SectionList and set the various properties:

And here is a video with the tile section list in action:

Caveat

Obviously, a layout manager that doesn’t support virtualization could trigger performance issues when you have hundreds or thousands of items (at least on mobile devices; on the desktop you probably won’t run into this most of the time). However, if you don’t have many items, than it could be actually faster than a layout that uses virtualization.

LATER UPDATE: You can read here how you can create layout managers that support virtualization.

Why? Because when a list uses virtualization, it recycles the item renderers (as soon as you move out of the screen an item, its item renderer is reused for an item that just got into the view port). This means that as each item renderer is recycled, it must be removed from the DataGroup display list, new data are set, the item is redrawn if necessary, and it is added to the DataGroup display list.

Right now I’m working on a Tile Section Layout manager with support for virtualization. Once I finish it, I will write another blog post that will explain in greater depth “the art” of creating layout managers.

Download the code

You can download the source code of the Flex mobile project from my GitHub account.