explorers' club

explorations in dev, science, sci-fi, games, and other fun stuff!

Tips (and reckless behaviour) for Component Developers

Leave a comment

Component Development (ComDev because I am lazy) is no walk in the park. Plenty of hard work goes into making a good, quality, and intuitive component. Though I have my occasional gripes about the Flex component set, I recognize that for the most part that the Flex framework and the component architecture is solid.

Since getting into ComDev, I have endured my fair share of trials and tribulations. As a result, below are some of my findings. Most of it is just common sense but there are a few things that work particularly well that you might not find except through trial and error. But before I start I’d like to highlight what I consider are the three most important things in ComDev.

Words of ComDev Wisdom:

  • Don’t try to reinvent the wheel – Though there may be plenty of ways to skin a cat, there are only a few that really work. Before even taking on this endeavor, you might consider asking yourself:
    • Is this really useful?
    • Is what I am adding/creating providing that much more value over a standard approach?
    • What are the costs/benefits?
    • Has it been done before?
    • and if so, how successful were those other attempts?
  • Go with the flow – Rather than forcing particular architectures/APIs/var names/method names inside your component, try to embrace those standards established by the Flex framework. I.e. if you are making a new type of ListBase component, consider using the name dataProvider on what most Flex developers would consider… well the damn dataProvider, rather than making up some new name for it.
  • Sometimes it takes frequent breaks and a second pair of eyes – If you find that a piece won’t fit, taking a break might help you realize that square peg won’t fit in the circle slot. Also having someone critique your logic and approach with a particular component will help you fine tune an intuitive API.

Tips:

  • AS3 Metatags – If you plan do any custom skinning, binding, event dispatching, etc. then you should familiarize yourself with the metatags and their functions. I’d highly recommend using the Flex framework’s metatag mechanisms as a model for your own implementations.For instance, if you were to want to make only certain string values available for a property in an MXML instance, you’d make use of enumeration property in the Style metatag. Also, anyone who has read my post on Flex’s built in Binding mechanism might want to implement their own custom event/binding trigger using the [Bindable] & [Event] metatags.
  • Learn the who, what, when, why & how – I am referring to the following functions:
    • updateDisplayList()
    • layoutChrome()
    • createChildren()
    • invalidateDisplayList()
    • invalidateProperties()
    • invalidateSize()
    • getExplicitOrMeasuredWidth()
    • getExplicitOrMeasuredHeight()
    • styleChanged()

    These are the primary players when it comes to all things be it skinning, child layout, instantiation, etc. To understand these is to understand the component as fully as possible.

  • Favor Inheritance over Composition – I am sure there is copious volumes on why to favor one over the other. I am not here to debate that. What I am here to say: In order to facilitate the ‘wiring’ necessary to plug in a child of a composition-based component, you’d most likely have to manually rewire the all the event and styling mechanisms. You also limit yourself to the public APIs of the children which means you can’t get at some of the key aforementioned methods.By using inhertiance, you now have access to both public and protected APIs, and you need only to override event and styling behavior that needs it. Of course for a more complex custom component this may not be possible. Not a decree, just a rule of thumb.
  • Favor ActionScript over MXML – Though this is personal preference, it should be noted that all of the mx classes are in ActionScript. And they are pretty damn stable. Though this limits some conveniences such as binding, you will probably have a much more stable component. In addition, you are less likely to run into erroneous ‘child out of bounds’ RTEs. Again, for complex layout type components, this might not be possible.
  • Be generous with comments – and add ASDoc comments as well.
  • Think long and hard about names for variables and functions – Have you ever asked yourself, “Why in the hell did they name that (enter name here)?!?”. Be kind to those who will be using your components. Don’t make them go on a rabbit chase to figure out what they need. That just gives them an excuse to use someone else’s component.
  • Be Grainular – This is one gripe I have about the mx class source files. Some of the methods span hundreds of lines. Anything over say 10-20 lines most likely needs to be broken down into separate functions.

Use with Reckless abandon (no really just use sparingly). I have used these a time or two to get the job done. They are not recommended but sometimes you gotta do what you gotta do:

  • Tap into the mx_internal namespace.
  • Make use of your own namespace.
  • For super.super needs, copy a parent’s source file and modify then extend (oh god… I think I might hurl….grrggg).
  • more to come…
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s