I saw Tony MacDonell over at Teknision was talking about some of the foibles of creating components in Flash. Then John laPlante commented about the same thing in response to my articles on component development and I have to say I know where they are both coming from. I’ve been developing components for Flash MX2004, Flash 8 and a few for Flex for the majority of my daily coding for nearly 2 years now. I’d have to agree it does seem weird to developers wishing to produce components how it all hangs together the first time you look at one.
The points they both hit upon were:
- Documentation or lack of it
- Having to add the class to both the linkage identifier as well as the component definition
- Placing the assets inside the component clip
- Uncompiled or compiled components inside your component clip
So I thought I’d add my experiences…
Documentation or lack of it
Documentation is a million times better than it was when MX2004 was first released but it is still lacking in a lot of places and some of the help files are just plain confusing for the budding component developer – Then again I shouldn’t carp on too much otherwise I’d have nothing to write about if it was better 8). The examples are far better now though so it’s not all doom and gloom.
Having to add the class to both the linkage identifier as well as the component definition
As far as I can tell, the class binding issue is symptomatic of the fact that the linkage identifier and the component definitions are reference by different processes – Linkage is for the actual compile to test the SWF or SWC whereas the component definition is for the actual component itself to operate. I personally think the fact that you have to compile the SWF / SWC via the library to be a bigger oversight though :P
Placing the assets inside the component clip
This again appears to be down to the issue of ‘compiling for distribution’, by this I mean the compiler doesn’t form any association with the linked items beyond adding a pointer to them inside the component SWF / SWC – if you use or have used a shared library you’ll know what I mean. So when you drag the file into a clean file it looks for the linked items in that files symbol library on export, and if it doesn’t find them it just silently fails. A hack is to add these linked symbols to the new file’s library and set the linkages, then they are accessible when that particular file is exported, not really a helpful solution in either case, but most hacks aren’t.
I have to say I don’t really see this as a real problem, after all it stops the distribution of component SWC missing linked assets – if you always test your SWF / SWC in a new FLA. I can assure you you’ll only do it once :P and then it sticks. Again this is more a symptom of a poorly implemented system for creating components overall as opposed to an awkward process for coding and testing them.
Uncompiled or compiled components inside your component clip
You may also want to watch out for the recompile issue – if you haven’t hit it already. If you have a load of SWC’s that share the same class(es) and you update said class(es) it is not automatically reflected in components compiled prior to this, (obvious I know but this becomes a real headache if you’re using shared libraries as well). This is due to the fact that Flash only initializes a class once at run time – so if two components have the same base class it initializes the first one and the second component just uses the one that is already there. Hence the recompile issue if you inadvertantly add in an old component that contains an old copy of a class that hasn’t been updated and it initializes first.
This can be alleviated in your component development files by only using the uncompiled versions of any components you extending from or as part of a composition component this way when you compile it to an SWC it pulls in the latest classes for all the components included on that enigmatic frame 2 of the component clip. This doesn’t, however, solve the shared library SWC problem. This can also stop erratic behave in compiled components that for the basis of a component extended from them.
If we are lucky Blaze will address these issues. I certainly hope so as the current component system is laboured compared to the rest of the Flash IDE – I would expect an entry in the New Document dialog for component development, (I’ve actually got a set of component templates I use that I’ve been meaning to post up – I just need to comment them up as they are still ‘in the rough’ so to speak :P
On documentation, I struggled with the Macromedia v2 architecture, and looked for documenation on how to apply it. Eventually, I began dissecting the v2 classes which has been helpful.
I read an article from Macromedia about the View class
http://www.macromedia.com/devnet/flash/articles/component_architecture_05.html
This is so not helpfu. They make it seems like it’s essential but it’s not very clear how I use it. Again, it’s a matter of going through the class and possibly reviewing a sample such as the Accordian to see how they use it. I’m not sure it’s worth my time.