Making a good choice when using Flex components

Sasha Dzeletovic, Thursday, May 22, 2008 @ 11:39 am

Good people of Adobe were so kind to pack a lot of useful components
with Flex Builder. Story goes, they are there to speed up the
development process and in doing so cut production cost while retaining
excellent user experience. There is also a lot of other kind people of
the Flex developer community that made wonderful components for all
kinds of applications and made them freely available.

To name some:

• flexlib, library of components
• spring graph, by Mark Shepherd
• Flex Exchange (hoping it gets bigger)
• ILOG Elixir, impressive and commercial
• Flex IFrame, a lifesaver
• FX SlideShow

Here's two links with a comprehensive list of Flex components from flex.org and FlexBox.

Beware Flex developer, this is a double edged sword. It's very tempting to jump in and grab components left and right to compose your custom application. In my experience this randomly has a happy ending.

First off, you have to get to know your component really, really good. Really. By now, I can group the related problems into following:

• Using only a part of the component's purpose
• Components with bugs
• Components with performance issues
• Components with a closed source (SWC's)

Using only a part of the component's purpose
Good rule of thumb is not to have anything in your project that is not actually being used. You'd think it wouldn't matter but more often than not it does. Typical problem is performance. You want to get the best bang for your buck. By buck, I mean computer resources. By bang, I mean perceived value. All those methods and properties that you are not using are still being initiated and are using system resources to do so, but you are not exploiting all that crunching. Repeat that component a few times in your project and the problem grows with it. And often it grows to a point where it impedes the overall performance of your application.
You would solve this by overriding the stuff that you are not using. If the component is complex, this requires a lot of work. Sometimes more work than it would take to build it from scratch yourself. But don't restrain from this solution because of its hardship because this is one of the best ways to truly master the Flex framework.

Components with bugs
A lot of components look good on a screen shot but you always want to see a fully working example of a component before you use it. It happened a number of times that I took the time to implement something that I thought was awesome, only to see after all that work that it doesn't really work as advertised. If you're going to fix any bugs, they better be yours because you will use more time to analyze somebody else's work and only than start with debugging.

Components with performance issues
Some components actually work as advertised but at a big cost. Remember, you are most often browser and Flash Player bound. You only have so much to work with. If the execution is lagging, there goes the user experience. So ideally you want to see your potential component under real working conditions beforehand. What happens to the component if you load it up with the real amount of data that it is going to be using? Is it still responsive as it was with your small test data?

Point being, first test your component under extreme conditions so you get to know it's performance boundaries. This is most often noted when trying to stuff Builders Charting components and (Advanced) Data Grid with too much data. Inquire in detail upfront what are the ceiling expectations of a component.

Components with a closed source (SWC's)
This is a real tricky one and should be avoided unless you bought it and it comes with a warranty. The reason is obvious – If anything is wrong with it, you're stuck. There is nothing you can do about it. Ask yourself, what if I want to override something? Is the documentation of this component really complete? Is something going on behind the scenes that I might not be aware of? Basically, you really need to have trust in the source of that component and accept that you are rolling the dice.

In general, I suggest trying to build your own components whenever possible because only you know what you exactly need. Flex documentation has gotten significantly better and there are examples online for most problems that you would encounter in your daily work.

Try not to start with extending an already complex component unless you're really sure you're doing. It's hard to track all the ins and outs of something like that.

Get to know the Flash Player! That is how you deliver your work and it works significantly different than standard browser bound solutions. There are some great articles about it, and boring as they may be, they are the very essence of Flex development.

In the end, the advantage of Flex platform is not so much in the fact that you have all these ready made components but that you can create and expand your own intricate framework however you please.

Kudos to Flex developer community that is sharing their work and experience!

Related posts:

1. Hedge Fund Analytics in Flex
2. Flex Gauge Component Example with source
3. Using Flex Code Generator (FCG) with Flex & PureMVC
4. Flex Widget for Graphing Elections and Debt
5. How much Excel can we get in Flex?

Comments (0)

Software Development

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment