Among of the biggest news of the Adobe AIR 3 release  is the Native Extensions feature. If you want to get started with this, or maybe just try it, you should check out the Native Extensions page on Adobe Developer Connection.

There are five examples so far:

1. Gyroscope (iOS/Android)
2. NetworkInfo (iOS) – retrieves information about the network interfaces on an iOS device
3. Vibration (iOS/Android) – make the device vibrate
4. iBattery (iOS) – gets the battery status (unknown, unplugged, charging, or full) of an iOS device
5. .NET Image Encoder (Windows) – encodes a bitmap into BMP, JPEG, or PNG format using Microsoft .NET Framework 4

The first three extensions were created by Adobe engineers, the last two by community. As I said before I’m looking forward to seeing many more extensions created and having a central place to go for all of them.

Radu Ticiu of Timisoara Mobile Development Group invited me to speak at their August event about Adobe’s solutions for mobile development. And I must say I’m glad I accepted. Not only because the event and the people were great but because the other speaker was quite interesting.

Stefan is his name and he runs one of the most creative companies in this part of the world. Just to give you some context: they’ve won three FWA awards so far. His presentation was about the making off of an iPad game using Adobe AIR and Flash Builder 4.5. So far nothing new or extraordinary. isn’t it?

Well what really caught my attention were these facts:

• While they had great expertise in building Flash applications for the desktop, this was the first project they’ve done for mobile.
• They completed the game from concept to final IPA file ready for publishing in a week.
• The team who built this consisted of one designer, one developer, and Stefan.

Here are some screen shots of their game – called Chemistry Brothers:

During the presentation (and after while we enjoyed some beer and food) I learned more about this project and the company. And I think this project and the way they approached it is a good example of how you can get into mobile development if you are a web or desktop developer.

These were Stefan’s challenges before deciding to start the project:

• no expertise in mobile development
• no expertise in Flash and AIR mobile development
• no expertise in selling an application on Apple’s app store

Though these challenges were quite big he had something to rely on:

• tons of creativity
• great expertise in desktop and web development including Flash and Adobe AIR
• a plan

The plan he had was as important as the skills of his team. First of all, he decided to spend a week for building the game, from nothing to the polished “thing” you can find in app store. It was an all-or-nothing kind of bet. And to increase the chances of success he took his team out of the town to a remote town with nothing to distract them. They did a sort of software bootcamp.

Second, from the beginning he didn’t want to have anything less than great performances. To ensure this they used a first generation iPad for testing the code and they targeted 30 frames per second for their game. Anything less was not accepted.

Third, they struck a fine balance between the “features” of this game. They spent a lot of time on the graphics and game story but they didn’t spend much time on building lots of levels. It would have been impossible to do all those things with such restrictions (three people and one week).

And finally, they did a kind of agile development not for the code but for the product (game). Remember that I said they didn’t have any prior experience in building and selling mobile applications. So their plan was to build the game in one week and then ship it. If it had success then they would continue to develop as they already had the game story and lots of ideas. Guess what? They are happy with how the game is selling so far. Stefan told me that they will continue this project.

If you are one of the people who couldn’t find time for trying mobile development so far you are not alone. And more importantly, it is not so difficult to make your first move. Just think of an application that you’d like to build and make sure you allocate time for this. It could be a series of weekends during a month or three days of your vacation. It really doesn’t matter. What matters is to be focused and work on this fully committed. Chances are that you’d be surprised by yourself and what you can do.

In the end I just want to share some pictures from their office. Some say that having a creative environment stimulates creativity. After talking to Stefan and seeing his company’s work I’m not sure about this anymore. It looks like creative people change ordinary things into something to remember.

A wall built out of books

Playing around with Darth Vader's helmet

Another inspirational wall closely guarded by a she-clone

Rest room guardian!

Taking a break or having a meeting in a cozy space

If you have similar stories or just want to talk back, don’t hesitate to use the comments :). All I can say is: Bravo Stefan & Company!

One of the important pieces of the Flex framework for mobile development is the ActionBar class. This class lets you create an application title bar with three distinct areas. Starting from left to right you can have a navigation area, a title area, and an actions area. Of course you are not forced to use all these areas.

Why would you want to use this component? There are many reasons for using it but probably the most important is that it is an established user interaction design pattern on Android and iOS. This is how you usually add things like an application or section title, navigation buttons, search input texts, or action buttons.

Here are two screen shots of the Facebook application running on Android and iOS that illustrates this idea:

Using the ActionBar component

Using the ActionBar component is quite easy. First, you’ll need to create a Flex mobile project that uses either ViewNavigatorApplication or TabbedViewNavigatorApplication. Then, you can define the components you want to add to the ActionBar either globally (for all the Views) or individually (for each View).

If you want to add them inside of a View here is how you do it:

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

 <s:navigationContent>
     <s:Button label="Back"/>
 </s:navigationContent>
 <s:titleContent>
     <s:TextInput prompt="type to search" width="100%"/>
 </s:titleContent>
 <s:actionContent>
     <s:Button label="+"/>
 </s:actionContent>

</s:View>

This code produces the following ActionBar:

If you want to set it globally then the method differe slightly depending on what Application root tag you chose when creating the project (ViewNavigatorApplication or TabbedViewNavigatorApplication). For ViewNavigatorApplication you’d do something like this:

<?xml version="1.0" encoding="utf-8"?>
<s:ViewNavigatorApplication xmlns:fx="http://ns.adobe.com/mxml/2009"
       xmlns:s="library://ns.adobe.com/flex/spark"
       firstView="views.ActionBarHomeView">

 <s:navigationContent>
      <s:Button label="Back"/>
 </s:navigationContent>
 <s:titleContent>
      <s:TextInput prompt="type to search" width="100%"/>
 </s:titleContent>
 <s:actionContent>
      <s:Button label="+"/>
 </s:actionContent>

</s:ViewNavigatorApplication>

And for TabbedViewNavigatorApplication you’d add one for each tab you have in your application. For example:

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

 <s:ViewNavigator label="Tab 1" width="100%" height="100%" firstView="views.Tab1View">
      <s:navigationContent>
           <s:Button label="Back"/>
      </s:navigationContent>
      <s:titleContent>
           <s:TextInput prompt="type to search" width="100%"/>
      </s:titleContent>
      <s:actionContent>
           <s:Button label="+"/>
      </s:actionContent>
 </s:ViewNavigator>
 <s:ViewNavigator label="Tab 2" width="100%" height="100%" firstView="views.Tab2View">

 </s:ViewNavigator>

</s:TabbedViewNavigatorApplication>

And here is how this code looks like at runtime:

If you set the ActionBar globally and you want to override a section or all sections in a particular View all you have to do is to set that section/sections in the View.

You should also know that you can control the ActionBar visibility and rendering mode. For example in any View in which you want to hide the ActionBar you can set actionBarVisible = false. By default the ActionBar is rendered so it takes up some of the available space for the rest of your application. If you want to have the bar hovering on top of the rest of your application you can set the overlayControls to true in your View.

Understanding how the ActionBar component works

Let’s see how everything is put together. Each part of the ActionBar (navigation, title, and action content) is actually a Spark Group object. If you open the ActionBar class file you’ll find three properties named: actionGroup, navigationGroup, and titleGroup. These Groups are populated by calling the setter methods: actionContent(), titleContent(), and navigationContent(). These methods are called by the View class to push the components you set for each section and the argument is an Array (you can set a Button or a number of UI components for each section).

How about the layout used by these three groups? Well you can set a different layout than the default by calling the actionLayout, navigationLayout, and titleLayout setters.

The ActionBar component is a Spark component and this means that the task for laying out the various UI components that you can add to each section is actually implemented by a skin class. And of course the look and feel is implemented by the same skin class. The default skin is spark.skins.mobile.ActionBarSkin. This class extends the MobileSkin class, which in turns extends the UIComponent.

The interesting parts in the skin class are these three methods: createChildren(), measure(), and layoutContents().

If you take a look at the createChildren() method you will see that here is where the three groups (navigationGroup, actionGroup, and titleGroup) used for each section are actually created and the default layout is set. Also you can see that the default layout used by each group is HorizontalLayout. Here is a snippet of the code that creates the navigationGroup:

navigationGroup = new Group();
var hLayout:HorizontalLayout = new HorizontalLayout();
hLayout.horizontalAlign = HorizontalAlign.LEFT;
hLayout.verticalAlign = VerticalAlign.MIDDLE;
hLayout.gap = 0;
hLayout.paddingLeft = hLayout.paddingTop = hLayout.paddingRight
        = hLayout.paddingBottom = 0;
navigationGroup.layout = hLayout;
navigationGroup.id = "navigationGroup";

The measure() method is executed executed after the createChildren() method or when the invalidateSize() method is executed. As the name implies, this method measures the width and the height of the ActionBar taking into consideration the padding (left, right, top, and bottom) and each group width and height (navigationGroup, titleGroup, and actionGroup). It is important to note that the height of the ActionBar is determined by the highest element you have, if this height is bigger than the default height. In other words if you add a Button and set the height of the button to 200, then the ActionBar height will be 200 pixels.

And finally the layoutContent() method is responsible for positioning and setting the size of each Group. This method positions each group starting from left to right with the navigationGroup, titleGroup, and actionGroup. If the total width of the navigationGroup and actionGroup is equal to or more than the total available width then the titleGroup is not displayed (visible = false).

Here is a graphical representation of how these different parts are related:

Skinning the ActionBar component

Let’s talk about styling the ActionBar component. Out of the box you can quite easily change the appearance using the CSS properties. For example you can use CSS to transform the default look and feel  of the ActionBar presented in a screen shot at the beginning of this article to something like this with a little bit of CSS:

And the CSS code that does this is this (please note that you have to include the CSS code or file in the main application file and not in the Views):

<fx:Style>
@namespace s "library://ns.adobe.com/flex/spark";

s|ActionBar {
      chromeColor: #484877;
      defaultButtonAppearance: beveled;
}
</fx:Style>

The second CSS property in the code above (defaultButtonAppearance) is responsible for rendering the buttons in iOS style. If you inspect the ActionBar class you will find all the important CSS properties that you can play with.

If you want to go beyond background and font colors, sizes, and so forth you have to go down the road of creating a custom skin. And the easiest way to do this is to extend the ActionBarSkin class.

Here are the important parts of the ActionBarSkin class from a skinning perspective:

• border and borderClass properties. Border represents the first child of the ActionBarSkin (take a look at the createChildren() method).BorderClass is a reference to an FXG file that is set in the class constructor depending on the applicationDPI value. The borderClass is used for creating the borders of the ActionBar and the shadow at the bottom. Here is a screen shot of what this looks like (I placed a pinkish background behind the graphics to provide some contrast for the highlights you can notice on the left/right side):

• drawBackground() method. This method is responsible for drawing the background. In the previous screen shots this is where the black or dark blue color is coming from. If you take a look at this method you will notice that it uses CSS properties (default or set by the programmer) to draw a gradient.

I think that in the most of cases, when you want to skin an ActionBar component you’ll likely modify the drawBackground() method and create a different borderClass FXG file.

Let me show you an example of a custom skinning. There are three steps involved in this.

First, I created a new FXG file to be used for the background. To do this I opened up the FXG file used by default by the ActionBarSkin in Adobe Illustrator (you can find the path for this FXG in the ActionBarSkin constructor). And I added three green rectangles (some with a solid color, others with a transparent gradient). Here is the result in Illustrator:

Then, I exported the FXG file as an FXG. And I opened this file in a text editor to remove some of the tags and attributes introduced by Illustrator. Finally, I add the FXG file to the Flex mobile project.

Second, I created a new ActionScript class that extends the ActionBarkSkin. In the constructor I make sure that the borderClass uses the FXG file I created in the previous step. And I overrode the drawBackground() method because the FXG file does everything I need. Here is the complete listing:

Third, I changed the CSS from the main application file in order to set the new skin class as the ActionBar skin class, and the chromeColor used for the buttons. Here is the code:

Finally, here is how the skinned ActionBar at runtime:

In conclusion, if you couple these techniques with skinning of the other components you plan to use inside the ActionBar then you can really get something that is quite unique.

You can download the Flex project source code used for this example from here.

A colleague of mine who is building a Flex mobile application had some performance issues with a list. In short, when he used a pretty heavy custom item renderer (with checkboxes, buttons, and labels) the scrolling performance dropped a lot. When using just a label item renderer everything worked well.

So, we started to debug the code and, as I suspected, the culprit was the layout manager: the virtualization was off.

This was strange as he didn’t turn off the useVirtualLayout flag anywhere in the code – at least not explicitly. So why was the virtualization off? Because he used list.itemRenderFunction to change the item renderer at runtime. If you take a look at the documentation you will find this:

Function that returns an item renderer IFactory for a specific item. You should define an item renderer function similar to this sample function:

function myItemRendererFunction(item:Object):IFactory

Currently, when using itemRendererFunction with a virtual layout (useVirtualLayout=true), item renderer recycling is turned off. Because of this, using itemRendererFunction can cause a performance degradation and is not recommended for mobile. This may be fixed in future versions of Flex.

So, if you use a heavy item renderer and/or you have many items, don’t set the item renderer using the itemRendererFunction method.

Instead, you can wrap your custom item renderer in a ClassFactory object and then assign this object to the list.itemRenderer property. Like this:

var factory:ClassFactory = new ClassFactory(MyCustomItemRenderer);
// set the properties for custom item renderer
factory.properties = {iconField:"thumbnailSmall",
                  messageField:"description", iconHeight:180, iconWidth:180};
// set the ClassFactory object as the list item renderer
myList.itemRenderer = factory;

There is one more thing. In the example above I used the properties property of the ClassFactory object to set the properties I needed (for example what data property should be used for the message label). You can’t use this approach for setting CSS properties like fontSize. The only solution I found so far is to create setters that behind the scenes are doing something like this:

public class MyCustomItemRenderer {
   //...

   public function set fontSize(value:int):void {
      setStyle("fontSize", value);
   }

   //...
}

This was my tip of the week. And don’t forget, stay away from useVirtualLayout = false;

One way to improve the user experience for mobile applications is to save data locally. This technique is important for desktop applications and it is even more important for mobile applications (mostly because the network connection is expensive, slower, or intermittent).

When using applications such as mail or Twitter clients local storage enables users to see the messages or tweets loaded in the previous session. And while you are seeing these “old” items the application can pull in newer items behind the scenes. The main idea is to not to make the user stare at an empty screen each time he opens your application.

A second benefit of this technique is that your application will feel much more responsive. As I said it is possible that the user has a slow Internet connection and downloading 12 small pictures and some descriptions could be visibly slow. Local storage can offer a “performance” boost especially for applications that access data that changes rarely.

Depending on your specific use case you may want to save locally:

• media assets (images, MP3 files, video files)
• text or HTML resources
• XML files
• ActionScript data structures (an array of ActionScript value objects for example)

So how can you store data locally in an AIR mobile application (Android, PlayBook, and iOS)? You have almost the same methods as in AIR desktop applications (on the desktop you can use the encrypted local store to save ActionScript objects):

• Use the embedded SQLite database – obviously perfect for data that are a good match for a relational database
• Save ActionScript objects or collections of objects in files – serialize the objects into a file and read back when needed. Or you can use SharedObject to do the same
• Save binary assets directly into files – perfect for saving images or videos locally

I won’t go into details about these three techniques. Almost three years ago I wrote a blogpost that explains each technique (back then it was only AIR for desktops, but remember that apart from the encrypted local store you can use the same approach on mobile or desktop). So click here if you want to learn how to use these techniques.

There is one aspect I do want to highlight, however. When you want to save data locally using files you should always use the application storage folder. This folder is outside of the application installation folder. So you can update the application without worrying about the saved data. Here is a simple example for creating a new file inside the application storage folder:

var file:File = File.applicationStorageDirectory.resolvePath("new-file.png");
var fileStream:FileStream = new FileStream();
fileStrean.open(file, FileMode.WRITE);
fileStream.writeBytes(data, 0, data.length);
fileStream.close()

Flex mobile support for persistence

You probably already know about the persistence support of the Flex mobile framework. If you save your information to the data property of your View pages and set the persistNavigatorState attribute in the main application file to true, then all the information will be automatically saved when the application is closed and restored when the application is re-opened.

So here is a simple example. Suppose that you use this data model in your application:

package {

[Bindable]     
class User {
    public var firstName:String;
    public var lastName:String;   
}
}

Next, you turn on the persistence support in the main application file:

<s:ViewNavigatorApplication xmlns:fx="http://ns.adobe.com/mxml/2009"
    xmlns:s="library://ns.adobe.com/flex/spark"
    firstView="views.HomeView"
    persistNavigatorState="true"/>

And finally you use the data property to save the current instance of User. Bellow is the first View of the application. It uses bidirectional binding for displaying the User first name and last name properties.

<?xml version="1.0" encoding="utf-8"?>
<s:View xmlns:fx="http://ns.adobe.com/mxml/2009"
   xmlns:s="library://ns.adobe.com/flex/spark"
   title="HomeView"
   viewActivate="onViewActivated()">
<fx:Script>
 <![CDATA[

   private function onViewActivated():void {
      // if it is the first time the application runs t
      // here is no data
      if (!data) {
         // create a new User instance and
         // save it to data property
         data = new User();
      }
   }

 ]]>
</fx:Script>
 <s:layout>
     <s:VerticalLayout/>
 </s:layout>
 <s:Spacer height="10"/>

 <s:Label text="First Name:"/>
 <s:TextInput width="100%" text="@{data.firstName}"/>
 <s:Label text="Last Name:"/>
 <s:TextInput width="100%" text="@{data.lastName}"/>
</s:View>

When you run the application for the first time you won’t see any information in the two text input boxes. However if you type in something and then close the app and re-open it, you will see the information you typed during the previous session.

When is the data property of a View saved to disk? Every time the application is closed or a View is destroyed/replaced by a new View. In terms of events right after the View deactivate event is triggered.

When is the data property of a View recreated if persistence is turned on? Right before the View activated event is thrown.

The data property of each View is saved to disk using flash.net.SharedObject and the object that does this is the ViewNavigator instance accessible in any View class by using the navigator property.

If you want to be sure that the data property is persisted you can call navigator.saveViewData() in your View. Why would you want to trigger the saving process manually? Because in the unlikely event the app is closed by the operating system due to low battery or memory events you cannot be sure that the normal event flow for closing the app will be followed. By calling navigator.saveViewData() manually each time the user updates something you can make sure that nothing will be lost.

RegisterClassAlias

When you serialize ActionScript objects to files or use SharedObject the original data type is lost when you deserialize them. The same applies when using the data property of the View because, under the hood, SharedObject is used for storing the data. If you want to keep the custom data type, all you have to do is to use registerClassAlias() method.

Why? Because the serialization is done using the AMF3 format (Action Message Format) and if you want to preserve the class information for the objects you serialize/deserialize then you have register the class alias of the class object. If you don’t do this, when you decode the objects you’ll get anonymous objects.

In a previous section I used a custom data type User. If I want to make sure that the data type is preserved I can register this class in the main application file (this way I make sure that the class is registered before any decoding is performed):

<?xml version="1.0" encoding="utf-8"?>
<s:ViewNavigatorApplication xmlns:fx="http://ns.adobe.com/mxml/2009"
 xmlns:s="library://ns.adobe.com/flex/spark"
 firstView="views.HomeView" persistNavigatorState="true">

<fx:Script>
<![CDATA[
   import flash.net.registerClassAlias;

   registerClassAlias("User", User);
]]>
</fx:Script>

</s:ViewNavigatorApplication>

Conclusions

On Android you have to remember to set the appropriate permission in the application configuration file if you want to write files to disk (android.permission.WRITE_EXTERNAL_STORAGE). Also take into consideration how much space the data you want to saved will occupy. You should let the user know if you plan to consume GB of space.

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.

Lately, it is quite impossible to attend a software conference and not see sessions dedicated to mobile development. This is the hot topic of the day and rightly so, I believe. However, I have the impression that many people think that tablets and smartphones are almost the same thing. This is something that I do not believe is true. Furthermore, I think that because of this belief held by others many tablet applications end up being just a scaled up version of smartphone apps. If a tablet is just a phone with a bigger screen then a tablet app is just a bigger resolution smartphone app, right?

Let’s see why do I think that a tablet it is not just a bigger phone.

Tablets are more powerful than smartphones

This seems to be just a truism. Well, it is and yet most applications that run on tablets and smartphones tend to offer the same set of features and experience.

This is  suboptimal because on a tablet you have more storage space, a more powerful processor, and a bigger screen. And, if the battery doesn’t last for a full day it is not a tragedy. Is not like you end up in the middle of nowhere with a dead phone :)

All these differences should be exploited to create tablet applications that help people to do more than what they are able to do on a smartphone. If you take into account only the bigger screen you have something that enables people to read for hours without getting teary eyed. When more storage space is available , for example, why not let the user decide how many GB your application can use and offer him a true offline experience for things like email, news, RSS feeds, videos, and so on.

Tablets are shared smartphones are personal

Correct me if I’m wrong, but I have the feeling that, at least in the case of home users, a tablet is shared. This is not the case with your smartphone. You don’t say “hey mate, here is my phone. Just return it  in four hours.”

And if this is true, why are so many tablets apps built with a single user in mind? How can you have a tablet shared when you have to logout from your social or email accounts in order to let the other user do something?

Again, this feels to me like a big opportunity that it is missed. Why not enable multiusers for them and support on all the apps for which it makes sense? Remember, you do have plenty of storage space…

The Missed Opportunity

I think that this tablet shortsightedness is part of the reason for what we are seeing today: there a far fewer apps for tablets than for phones. And this is true for all the application stores.

I think that developers have a real opportunity here, and that for now it is just being missed. Once we fully understand that tablets and smartphones are different and people want and should use them differently, we will see much more innovation.

About three or four months ago I wrote a blogpost about Conqu – an AIR application for managing tasks. Since then, Conqu has been one of the best demos I have at hand when talking about mobile development with the Flash Platform. Most people couldn’t believe that Conqu was built using Adobe AIR and Flex.

Back then, it was available only for Android tablets. But today, Conqu is available in:

1. Android Market
2. iTunes App Store
3. BlackBerry App World
4. Amazon Appstore for Android
5. Nook Color

Running on an iPad:

Running on an Android Tablet:

Conqu is running today on three different OSes: Android (including Nook Color), BlackBerry Tablet OS, and iOS. And this is not all. They are working on making it available on Android phones, iPod Touch/iPhone, and desktop computers.

I tried the app myself on Samsung Galaxy Tab, iPad 2, and PlayBook. On each device it worked just great and looked beautiful at the same time.

I think that, with all modesty, this is a proof that the Flash Platform does deliver on multiple devices and OSes. Because the Conqu team used Adobe AIR and Flex, and applied the same tools and workflows for each version it was much easier to distribute their app across so many devices.

If you want to learn about mobile development with the Flash Platform make sure you show up at one of the events that the evangelism team is participating in all over the world. And of course take a look at the Adobe Developer Center page.

Nahuel Foronda of the Conqu team was kind enough to answer some questions I had. So here is a short interview with the team behind Conqu:

Me: What is Conqu?
Nahuel Foronda: Conqu is an easy to use yet powerful task management tool designed to help you conquer your inbox and get things done. With Conqu, you can organize the tasks by criteria that makes sense to you and then find the right task to do at the right time and place. Whether you are a GTD pro or you just need a simple to-do list, Conqu will provide you with all the tools you need.

Me: What is your business model for this app because you offer the application for free?
Nahuel Foronda: Conqu is free because we want to reach as much as people as we can. By removing the monetary barrier we believe that more people will try it out. From those that try it, some will use it once in a while but others will use it daily. People that find value on it are our real customers. They are the ones that appreciate other features like cloud synchronization between devices or the ability to interact with other APIs. Our business model is based on the synchronization service, which is a monthly subscription.

Me: Did you use the Flex framework or pure ActionScript?
Nahuel Foronda: We used the Flex Framework. It was a simple decision for us because we were already working with Flex in all of our previous projects. We really wanted to use a CSS system powerful enough to make the look and feel of our app as close to our Photoshop mockups as possible. Flex gives us that flexibility and it also has the advantage of being a great layout framework.

Me: Conqu doesn’t look like a Flex app. How did you do it?
Nahuel Foronda: We used Flex as the foundation but we created a lot of custom components. We used the List, TextInput, TextArea, Flex layouts and containers but the rest is all custom. All of the components (including those included in the framework) are highly skinned with ActionScript skins and graphics. The look and feel was very important for us, so that’s why you don’t find out-of-box Flex skins or regular Flex components in our app.

Me: The app not only looks great but performs greatly on all devices I tested. How did you do it?
Nahuel Foronda: The key for us was to use a very lightweight class as base for our components: SpriteVisualElement. That allowed our components to be very responsive. All the Flex layouts work great with this class, so we are able to include our lightweight components in any view. For the animations, we created our own layouts and use the Tweener library.
Another important optimization we did was to make all our skins in ActionScript as opposed to use MXML. In 95% of the cases we used bitmap graphics for things like backgrounds or icons instead of vectors to avoid runtime calculations.

Me: Your first supported device was Android tablet. How hard was to deliver the app for PlayBook?
Nahuel Foronda: It was not that bad, but it could have been great if we didn’t have to monkey-patch the Flex Framework to make the app that was running in AIR 2.6 run on the Playbook, which supported only AIR 2.5. I want to clarify that right now it is simple because both run the same version (2.7). At that moment, however, it took me some time to make it work. That’s what happens when you are working with a device that is not even out yet and is under development :)

Me: What about the iPad version?
Nahuel Foronda: That was perfect, very easy to make it work. We only had a couple things here and there but overall, it worked amazingly.

Me: Did you think about going native for Conqu? What made you change your mind?
Nahuel Foronda: Not really. We thought at some point about making an iOS-only version, but never three different versions. I don’t like the idea of developing an app three times for three different markets. We don’t really have the resources to do that. We also don’t have the time to develop and maintain three different platforms.

AIR allows you to focus on one code base with maybe a few differences in the layout, but still one code. What made me believe it was possible was the schedule app developed for MAX last year. That app was working very well on the small devices and because tablets would have more memory and CPU, if you built something for them, it would run even better. Now, a year later, the phones are faster too, so I believe we made a good choice.

Me: I know you have in the works versions for phones, Android and iPhone. How did you solve the problem of multiple resolutions/screen densities?
Nahuel Foronda: I’m working with the CSS queries that the Flex Framework provides. They give us the ability to use different bitmaps for the different resolutions and it is working very well for us because it keeps our code clean. Only the CSS has a reference to all the different resolutions.

Me: What about the team who build the app? I mean what experience did they have with the Flash Platform and mobile development and how large is the team?
Nahuel Foronda: We are three people on the team: a designer (Mark) that created all the mocks in Photoshop, a server side developer and Flex developer (Laura), and myself. Laura has great experience in ColdFusion and she takes care of all that plus half the Flex side (using Mate Framework). For example, she is in charge of all the model and most of the business logic in Flex. I’m complementing the team doing the optimization and all the ActionScript code such as custom component and skin development

Me: Do you have any other killer app in your pipeline?
Nahuel Foronda: We have a lot of ideas! But we are trying to focus on this one until we have released the desktop and phone versions.

Me: Is there anything you want to add?
Nahuel Foronda: Thank you so much for the interview and if your readers want to know more about the whole development process I have a very detailed post that I did not long ago.
http://www.asfusion.com/blog/entry/design-first-and-the-process-behind

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: