In this article, I’m going to discuss four considerations for developing high quality custom components:
- Portability
- Flexibility
- Performance
- Weight
Using these considerations, you’ll be able to develop more professional, usable components. Even if I don’t think I will use my component in another project, I like to use these principles.
Portability
This refers to the components ability to stand on it’s own. As you build it, keep in mind that you want to create a “black-box”. It should have properties and styles that define what data it works with and how it looks, but if it requires other components or data to be present outside of the component, you won’t be able to use it in other projects without those other things. This is bad form. It’s not that hard to keep your components portable, so just provide getters and setters or public vars that can be your interface to the outside world and you’re good to go.
Documentation also improves the portability of your component, although this depends somewhat on the complexity of your component. If it’s really straight forward, then putting the work into lots of asdoc documentation is just going to waste your time. Instead, document the code really well (if you’re distributing it as code) or write a web page describing the basic inputs and outputs of the component.
Flexibility
Flexibility is the ability another developer has to customize your component without digging through your code. If you expose the right properties and styles, another user will be able to easily set those things most often changed. I say “most often” because you don’t want to go overboard with this one. Just because something can be changed, doesn’t mean it needs to have a property exposed to change it.
Performance
This doesn’t take much explanation, but unfortunately, understanding the meaning of good performance doesn’t make everyone understand how to implement it. You have to look for ways to reduce processor cycles where it isn’t necessary. Look for places that the exact same mathmatical calculation is being done over and over. Make the calculation once, store the value and use that instead. If you have an understanding of how computers work, under the hood, this will be much easier for you.
The importance of performance is dependent on how much processing it’s going to be doing. If it processes some data once, then just displays it, then you will be more likely to get away with sloppy performance than if your component is meant to process thousands of bits of data every time the screen refreshes. One way to squeeze extra performance out of your component may be to use the “garbage-in, garbage-out” rule. That means removing some of that error checking code you have sitting around and providing the disclaimer with the component that error checking should be done earlier on.
Sometimes, you can ask yourself “how much processing does this require?” Then ask yourself, “how much processing should this require?”
Weight
The weight of a component refers to the memory footprint it has for every instantiation that exists. Similar to performance, you might need to examine what the most common use of your component will be. If it will be on the stage in one place and fairly static, then the weight won’t be as much of a concern as the case where your component will exist hundreds of times (such as in the case of an item renderer).
Something else to consider when looking to drop the weight is feature bloat. As I mentioned in the flexibility section, you don’t want to go overboard with features. Think about what most people will use your component for. A component that does 5 useful things is better than one that does 400 things that 99% of the users will never use. The component will end up carrying around all that extra baggage whether they get used or not.
When your component is an extension of another class, take the time to find out how base your base class can be. A common mistake is to extend Canvas or some other container to hold something simple. Containers like Canvas and VBox have code to draw scrollbars, layout children in certain ways, and other baggage that may not be needed for your use case. UIComponent is the base class for all Flex components. If you subclass anything else up the inheritance chain, you won’t be able to display it, so if your component is visual, see if you can get away with subclassing UIComponent.