Showing posts with label Flash. Show all posts
Showing posts with label Flash. Show all posts

Thursday, August 18, 2005

Excluding AS2 Classes

Recently I have been looking at how to exclude classes from a swf as part of a strategy for constructing large multi-swf RIA where core classes are loaded in as a common shared library at run time and then individual forms are loaded on demand.

Flash 7 introduced the "exclude.xml" as a way to achieve this.

To exclude classes from compilation, create a specially named and formatted XML file and place it in the same directory as the FLA file. Name the XML file FLA_filename_exclude.xml, where FLA_filename is the name of your FLA file minus the extension. For example, if your FLA file is sellStocks.fla, the XML filename must be sellStocks_exclude.xml.

Place the following tags in the XML file:

<excludeAssets>
<asset name="className1"></asset>
<asset name="className2"></asset>
...
</excludeAssets>

The values you specify for the name attributes in the tags are the names of classes you want to exclude from the SWF file. For example, the following XML file excludes the mx.core.UIObject and mx.screens.Slide classes from the SWF file:

<excludeAssets>
<asset name="mx.core.UIObject"></asset>
<asset name="mx.screens.Slide"></asset>
</excludeAssets>

Ok so this does work but the problem is it does not work properly, there are still classes that get compiled into the swf.

I was pointed to this article by Darron Schall which did provide useful information.

However in one case after several hours work to rework a class so that it would be excluded I was pleased to see it worked and the class was excluded, however the swf footprint went up, I was wondering what was going on!
Well after poking around inside the swf using ASV I saw that though the target class was not there several other classes had now been included. These were unrelated to any changes I had been making.

So at this point I decided to go back to basics and try and look at some very simple cases to see what was really happening.

I created a swf with no assets but with some code that directly referenced half a dozen classes. Without the exclude file the swf was 54k, with the exclude file it was 159bytes, good so far!

I then created another swf with a particular component and with the exlude file it was 7k which was all made up of graphical elements in the component. Again, good so far.

So now what happens if I combine these two files?
Well at worst case the size should be simply the two individual file sizes added together, however if the two files shared some classes you might expect the total size might reduce.

So what did happen?

The resultant swf was 35k, why???
Using ASV I can see a whole bunch of additional classes were being included.

I cant see any logic to explain this behavior.

But thats not the end of the story, taking this 35k swf I added additional components and placed them on the stage.

Again logic says the swf size would stay the same or increase depending on the overlap of the classes needed but what happened was the swf decreased in size to 21k.

At this point I give up further testing, although using an exlude file does have a very significant effect and certainly becomes an essential part of the strategy for developing larger RIA's there is no way to predict its impact or plan the class structure to achieve the smallest size swf. Just to be clear, from my own testing on the average form I can achieve reduction in size ranging from 50% up to 80% using the exclude file but whatever reduction you do initially get there isn't anything you can do to tweek it to get the remaining classes excluded.

It would be nice to think that this might be sorted out in Flash8 but it has already been said that little has changed in Flash 8 related to actionscript and anyway MM's focus is moving away from Flash so I guess this might become a feature of Zom.

I should note in this respect that MTASC also supports an exclude file, though it uses a different format, from testing it was accurate and consistant in excluding files.

In fact we are currently using MTASC to build the core shared component library as it is able to achieve a significantly smaller footprint than the same built from the Flash IDE.

Friday, August 12, 2005

Flash 8 IDE

Its been over 5 months since I last got round to blogging, we�ve been heads down working on XP3 the next generation of the XPComponent framework but now its out the door our heads are coming back up. I will try to highlight some of the new features in XP3 in future posts but for now Flash 8!

So Flash 8 is announced, some great new features for sure, but I was somewhat disappointed in what wasn�t there.

I read this blog by g.wygonik and I agree with what is being said not so much from the aspect of particular features discussed but about development of the IDE in general.

Mike Downey has made several comments on the subject which I feel are very significant and are worth highlighting.

We haven�t done any major code-editing improvements for hand coders as we found that almost all of the hand coders that we interviewed preferred to choose their own text editor. Even if we had added all of the features of an editor like PrimalScript or Eclipse (which would have been far too much work for a single cycle) users told us that they would still use their own editors. So we decided to focus on other things instead


We met with customers all over the world who represent every key segment of the Flash user base (solo devs, creative agencies, educators, enterprise shops, etc) and found that, overwhelmingly, everyone had a different idea of what features a good text editor should have and - even more so - were very attached to their existing text editor solutions.


The number of Flash users who are advanced hand coders and would be willing to give up their text editor to go back into Flash was far too small when compared to the greater base of Flash customers.

In the case of Flash 8, users made it clear that code editor enhancements like the ones mentioned in this thread were important - but not as important as the other things that we did.

We developed Flex because Flash authoring was never going to fit the traditional application developer market (Java/C++/.NET/etc) so we needed to do something new. Flex is not a replacement for Flash, it�s a new solution targetted at a completely different market

Let me summarise:

  • People wont use the Flash editor even if we improved it

  • People want other things improved

  • Flash is not for application development Flex is


  • Mike does say that this doesn�t mean that they are never going to improve the editor/IDE but to be honest that comment doesn�t make a whole lot of sense. If the facts as stated are true then how are you ever going to justify the resources needed to improve the IDE to match that of other similar products (IDEs - Delphi, VisualStudio, Editors-Eclipse,SEPY) particularly when in 2 years (or whenever F9 is out) the IDE will be even further behind the alternatives and the mountain will have become even steeper and higher.

    Mike somewhat dismisses the rant about missing features by saying don�t get upset if your own personal favorite feature is not in Flash 8, but I think that is unfair the rant is not so much about one persons favorite feature but about lack of development in general of the IDE stretching back over several generations of Flash.

    If we now have to wait until Flash9 to see any improvements that�s a long ways off and I cant see things changing then anyway. We have put resources, time and money with the aim of developing jsfl tools and wizards for use with our components in the IDE, our belief was that a visual IDE was an important element in creating Flash applications and a good IDE is a major productivity benefit to a language (just look at the Delphi IDE) and that someday soon the Flash IDE would be at least brought into the ballpark of VisualStudio (not the greatest IDE by any means ) but I realize now this is just not going to happen. The decision has been made and clearly Macromedia are following a different path.

    So as a company focused on RIA�s or supporting developers who create RIA�s I have to take this on board. I shouldn�t be using the IDE to create applications and instead I should use Eclipse. So today I downloaded Eclipse, although we do do a lot of Java development we are not Eclipse users (we use JCreator) so it was something new (also makes me wonder how many MS shops were in MM�s survey group �cos I don�t know of many who use Eclipse) .

    I don�t really have a problem with Eclipse but I will say if I am using Eclipse to write my code for sure I am going to use MTASC to compile it. Its just a natural fit and it seems that everyone else has the same idea.

    I may be gaining in productivity using Eclipse/MTASC as I don�t spend half my day waiting for a recompile or needing to restart Flash after a crash but its not a visual IDE and in some areas my productivity is going to suffer.

    One of the cool things with MTASC. is I can already build Flash8 swf�s even before the release of Flash8.

    The question I find myself asking is why would I now want to upgrade to Flash 8? It has nothing to offer me that I don�t already have, and it sounds like its unlikely to have anything for the foreseeable future either.

    Its a shame really a good visual IDE is a major productivity boost, Delphi has it, VB has it, others have it, Flash on the other hand doesn�t and seems to be giving up but there is no point in trying to fight lost battles so over time XPComponents will shift its focus away from the Flash IDE towards Eclipse and MTASC as the target development enviroment as MM suggest and so expect to see a lot more from us in this area in the future.