Writing your own custom Flex Components is a valuable skill to pick up, and involves a few key abilities, such as knowing how to manage your graphic assets (in the absence of a library such as Flash has), carefully considering things such as styling, scaling etc.

On the code front, you might find it restrictive to work within the confines of the Flex lifecycle, but you must do so. Understand, Flex sits on top of the Actionscript language – it adds functionality to the base language. If you look at a side-by-side chart of AS3 vs. Flex, you’ll see the the Flex classes are many more numerous.

The benefits of this are that you get things like the nice layout managers, data binding to properties, CSS styling, etc. Where you might find the Flex component odd to work with has to do with the invalidation model that it uses, if you have not used such a model before. In short, the invalidation model works based on the idea that one does not update the screen until all data has been evaluated, and then only the things that have changed should be updated.

This is not that new of an idea, being pretty common in video games. You plot the movement of your sprites, look for collisions, flag them, calculate reactions, then update the screen. This approach works equally well for components, and there are a lot of advantages to doing things this way.

One big reason for using the invalidation model in Flex, is that MXML can not, without some script injection, directly call actionscript methods. But it can directly set the value of properties of a class. Why is this a big deal? Well, for most developers, they are used to defining public methods as the API for their classes. However, to be true to the Flex way of doing things, you don’t define an API via public methods, but rather by properties exposed either directly or indirectly.

This causes a subtle but significant shift in the responsibilities of the objects. The component itself becomes responsible for all things related to the change of any piece of data in it’s state. It becomes very self-contained. What does this mean for development and implementation of the component? Well development becomes more of a hassle, but implementation becomes a good deal easier – and that is precisely what you want in a component. It should be easy and seamless for anyone to pick up and use without knowing the particular details of its internals.

So I say again: the key to understanding the Flex architecture and making your own components is to remember that the API for a Flex component should always be exposed via properties, never via public methods. Stick to that rule, and your data binding will work. (Data binding is one of the major features of Flex).

With that rule in mind, a lot of the phases of the Flex component lifecycle begin to make more sense in the way they support that notion. In short, a basic custom Flex component that is compliant to the Flex framework (but does nothing) would look pretty simple. It would extend UIComponent, the base class that Flex components all extend. It would define just a few methods; createChildren(), commitProperties(), measure() and updateDisplayList(). With the exception of createChildren(), all these methods take place after some data has changed in the component! Easy right? But how does the component know that the data has changed? The framework itself tells the component so.

The framework knows the data has changed because whenever our component’s property changes, we just call a specific method of the framework to tell it the data was updated. These are simple methods, named to be easily remembered; invalidateProperties(), invalidateSize(), invalidateDisplayList(). Each of these methods signals the framework that a property has changed, or the visible properties of an object have changed, or something on the displaylist has changed.

So the formula for changing data in the component is pretty straightforward and doesn’t ever change: update the data, then call an invalidate function to let the framework know. After that, the framework will take care of the rest by calling any or all of the commitProperties(), measure(), or updateDisplayList().

That is, of course a very simple breakdown of the how and why of making custom components in Flex, and there are definitely some more in-depth articles out there. But hopefully this short submission can help to give you a good overall view of where to begin and how to think about Flex components.