Home > Best Practices, Flex, Learn This > Know your Flex interfaces

Know your Flex interfaces

One of the things I love about Flex is how extensible it can be. You are able to make composite components to do almost anything you want using out of the box components. However, if you really want to take advantage of its power, it helps to have a good or in depth knowing of the interfaces that come with it. The reason to proclaim the importance is that using these interfaces, you will be able to create extremely light weight components, but you will be able to make them do whatever you want (in a programming sense of the phrase).

There are, of course, quite a few different interfaces. I have looked through them and picked out five interfaces that I consider to be the more important ones. For each, I will give a brief explanation of why they are important and where you would normally use them.

Usually when creating composite components or item renderers, I try to stick with UIComponent rather than something like an HBox or Canvas. If you are going to use it item renderer for something like a list though, you are going to have to implement IListItemRenderer to your UIComponent. Keep in mind, if you dont use an UIComponent, there are a lot of other interfaces you will have to implement. If you want to keep it simple, use UIComponent.

When you implement IListItemRenderer, you are given access to the listData, which has one extremely useful property on it. Using the listData property, you will be able to tell in your item renderer which field of your dataprovider you are currently using. This property is know as the labelField. This is useful when you need to handle special cases for different properties. Since you have a access to this, you can setup something like a property map to handle each case.

When implementing the IListItemRenderer, when setting your getter/setter for your listData, keep in mind that the data coming in will be of type BaseListData. Be sure that your classes implementing this will have that property on it.

As you might have noticed, I did say to use the IListItemRenderer for lists. Well what about grids? With a IDropInListItemRenderer, you are able to reuse the renderer to assign it to multiple properties, for say, columns in a datagrid. Keep in mind that when using the IDropInListItemRenderer, you must also implement IDataRenderer(which I will discuss shortly). This is in order to have access to the data property. The listData is then used to initialize the data property. Normally when your components need to apply new listData, it takes place in the commitProperties (or in invalidateProperties is flagged. However you feel like describing it). When you implement your getter for listData, make sure you bind a dataChange event in your component like this:

public function get listData():BaseListData{
      return _listData;

This will ensure that your getters/setters are called properly. This also applies to IListItemRenderer. You will also notice that the BaseListData object is also used whenever you are using IDropInListItemRenderer. This is because the type that is actually used is dependant on the component that it is being used with. If it is a grid, it will use DataGridListData, Lists will use ListData and a Tree control will use TreeListData.

The IDataRenderer is another popular one amongst item renderers. This is what gives you access to the data property. Along with needing to work with the listDataRenderers, it is also used whenever a chart needs a renderer. It could also be used with datagrids as well, but for this, the data property would be the data for the entire row, not specifically for the item. Just like in our IDropInListItemRenderer, we need to make sure that our component has a binding for the dataChange event. The other important fact for this is that when you are setting your data, to fully complete the binding, an event dataChange event must be fired.

public function set data(value:Object):void {
  _data = value;    
  dispatchEvent(new FlexEvent(FlexEvent.DATA_CHANGE));

This is one of the more interesting interfaces. Not so much because its cool or does anything special, but it is the only interface where it is recommended to either:

a) extend EventDispatcher
b) if that’s not an option, have an IEventDispatcher property on your component.

Personally, I pick option B. If you have a property for it, it does give you the ability to assign a different implementation class to it, making it more versatile. You could leave it as a normal EventDispatcher, but you could also assign a CairngormEventDispatcher to it. Once you do this, you will be able to create your own hooks in order to dispatch your events.

I feel this gets overlooked but it is definitely important in the world of data services. The reason it gets overlooked is that we just often copy/paste code like this and take it for granted that there will always be a result function for our service calls. However, this is the interface that gives us access to our result and fault functions that our asynchronous service calls make. Most of the time, we use existing frameworks such as cairngorm or puremvc for this, but it is good to have an idea of what is going on the background.

Usually our fault function looks like this:

public function fault(info:Object):void);

Normally a FaultEvent is what is returned, but according to the Flex documents, this is not always the face, hence it being returned as an object.

public function result(data:Object):void);

Once again, this normally comes back as a ResultEvent, but this is not always the case.

These are just a few of the major interfaces that I have used more often than not. There are quite a bit more. While knowing all of them by heart is not something I would consider necessary, but when you start creating custom components, knowing these interfaces and how to use them are extremely important. It allows you to create more flexible, clean and light weight components.

Think I left something out? Any other important ones? Wrong about something? Feel free to comment!

Best Practices, Flex, Learn This , , ,

  1. Filip Nedyalkov
    June 19th, 2010 at 17:45 | #1

    Hi, I find this topic very interesting. I’ve been reading all of the day now about interfaces classes which implement them usage and so on and I really hard it find to understand when there are pretty much no examples. The case here is pretty much the same.. Today I understood how important interfaces are and how you gain access when you implement them to various things but I still don’t know what that exactly means…
    So could you please set maybe 1-2 simple examples of a custom component implementing an Interface and using it’s functions maybe or whatever you thing it’s important to show. I kinda don’t understand how when you implement an interfaces it’s functions get updated or called… it’s basicly all very confusing for me right now. I need to see some real examples to get how it works in the big picture…
    If that’s not a problem for you of course.. or maybe you know some good links where to find usage examples, I couldn’t manage to find good ones myself..


  1. No trackbacks yet.