moockblog

components article followups

here are two responses to questions about the flash components article i wrote for the o'reilly network.

==================
QUESTION 1

Why are components large in size?

I started using drop down, push button, and radion button on one of my application and noticed the size of my swf file increase from 10K to 32K. Please note that I am publishing my project using the compress option. Any ideas why this is happening?

==================
ANSWER 1

This is a common debate on most flash programming boards. The two biggest reasons for the size of the components are:

1) they're designed to be used as a group, so you take a big hit for the first one you use, and much less for each one thereafter. e.g., if you just use a listbox, you'll notice a big jump in filesize as the core libraries for components are added to your app. if you then add a radio button, you'll notice that the additional size is less than the cost of using the radio button on its own. and if you need a scrollbar, you get it for free (there's already a scrollbar in the listbox).

2) the components have a much richer featureset than you might think. they respond to keyboard control, and accessible input devices, have their own focus model, work with dataproviders, etc, etc. macromedia's goal is to make them behave like real operating system controls, so that online flash apps feel like traditional desktop apps. to paraphrase macromedia's mike chambers (www.markme.com): if you can build an equivalent feature set in less code, macromedia has a job for you.

it seems to me that it might make sense to ship "lite" versions of the components, that have a stripped down feature set. however, if everyone used those, then flash content would be much less usable and completely inaccessible.

for a long discussion about file size and component quality involving several macromedia employees (including nigel pegg, who developed most of the original mx components), see: http://chattyfig.figleaf.com/ezmlm/ezmlm-cgi?1:sss:27250#b

==================
QUESTION 2

I'm speaking from a coder point of view, and here all the things that I dislike in components:
- Macromedia doesn't provide any guideline, standards, rules or internal documentation of their components.

- I didn't like smartclips in flash5 too, and I'm happy not to have waisted my time to use or build them, because now they are obsolete, detroned by flashMX components, is it gonna be the same things with components when flash 7 will go out and promote a new way of doing things ?

- the way components work and how they are structured, sorry but that's bad coding practice ...
http://c2.com/cgi/wiki?CodeSmell

I will not be a dummy programmer following blindly Macromedia components bad OO coding style.

==================
ANSWER 2

components are here to stay, trust me. if you develop windows apps, you don't write a Menu or DialogBox class yourself, you use the corresponding MFC class. if you're developing java apps, you likely don't write a Tree class yourself, you use JTree. if you're developing flash apps, you use components. after all, you're developing apps, not UI widgets. of course, in some situations you'll produce your own specialized UI widgets for any platform, but for standard apps, you use the built in UI libraries.

the mx components are not perfect. they are version 1 of flash's UI library. but they are quite usable, and lay a good foundation upon which macromedia will certainly build. i agree that the flash mx component authoring process needs improvement, and in some cases so do the components themselves...but that's why software companies release new versions of products, right? merging an animation tool with an app development IDE isn't something that happens overnight. it takes years to evolve. and along the way i think we're all learning to create better, more engaging content.

Posted by moock at July 23, 2003 11:04 AM