Someone suggested that with so much happening in the Flash world at the moment I should talk about the future direction of XPComponents.
This basically means talking about Flux!
Flux is the code name for a project we are currently working on.
Flux stands for a FLash User interface defined in Xml.
Might sound similar to Flex, I mean that’s Flash and XML right? True, they are similar products but I would describe them as siblings i.e. related but not competitors. Flux differs most significantly from Flex in that Flux is compiled at run time whereas Flex is compiled at author time, additionally all code behind in Flux is contained in actionscript class files not in scriptlets in the XML. I see both approaches as having there advantages and disadvantages, some situations will be best suited to Flex but I believabe others will be better served by Flux, I don't really see that there will be much overlap.
A typical Flux application consist of several precompiled libraries containing the XP3 component framework, plus your application specific code library and an xml file containing the definition of the overall application structure and screen definitions.
It will be possible for an application to be made up of more than one custom library/XML i.e. to have a Form or a group of Forms in a separate library and a separate XML file so that it will be possible to share Forms across different applications without needing to have the Form compiled into your application.
Much of the power of Flux comes from leverageing the existing capabilities of the XP3 framework with its layout managers, data binding, forms and application architecture.
The typical workflow that we imagine with Flux will be to create your application class files in Eclipse (i.e. ASDT, Zorn, or PowerFlasher), at the same time define your UI in XML, then compile your actionscript using MTASC, copy the compiled files plus XML to server and run.
The idea is basically similar to how you would handle a JSP or HTML application today, the interface is defined in an xml file then rendered at run time when a form is requested. Your own code behind will then exist in a compiled library and will be loaded and associated with the interface as it is rendered. The XML file will be modifiable after the application is compiled i.e. after being deployed, making simple layout changes trivial.
The foot print of Flux applications is generally very small, each Form will only be a few kb maybe in the region of 1 or 2 kb (obviously dependent on the amount of code you write) plus a few hundred bytes for the xml UI definition. The XP3 system libraries obviously are larger than this but then they will be cached on the client so they will only be needed to download once rather than with every application or Form.
Ultimately we hope to have a Flux Form designer that can be integrated with Eclipse though this currently has a low priority and wont be in Flux 1.0 .
Flux is currently under development, we don’t yet have a planned launch date but it will probably be sometime in October.
XPComponents will still continue to be targeted at both Flash IDE and Eclipse development, Flux will probably be sold as an add-on product that will targeted primarily for Eclipse based development.
For anyone interested in XPCharting, we have plans for substantial development of the charting package once we get our hands on Flash8. We are hoping that the improved graphic capabilities of Flash8 will provide the basis for major enhancements particular in user interactivity as well as improved rendering making more complex charts practical.
Tuesday, August 23, 2005
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.
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
<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
New Flash 8 Player Security
Someone on Flashcoders today mentioned that one of our demos crashed under FP8, so I installed FP8 to check it out.
Whilst checking into the issue I ran the application from my local PC and came face to face with the new security features of FP8 from a user perspective.
All I can say is I hope it is improved by the time it is released.
The application basically links to our site and downloads an XML document and some jpg's.
First I got the message box saying that a potentially dangerous thing had been stopped and I needed to click settings if I wanted it to go ahead, fine so far. Bit to long a delay while it fires open a new browser and heads of to the MM site to show the security setting screen but ok if this is really unavoidable. Once there it took me a while to realise that I needed to add the url of our server as a trusted location and restart but OK got that done.
On restart I get the same message, again go to MM site, so maybe I got the wrong url, so I enter another of our servers url's as trusted and restart.
and again... and again... didnt matter what I put in it wasn't what FP8 needed.
So in the end I just clicked the option to say just trust everybody..
Thats fixed it..
Now this may be just a beta issue, but a suggestion here.
When you go to the security page why not tell me what the url the application was trying to access was and then just give me the option to say "OK that one is good" 'cos in reality no user is going to actually enter trusted sites it will be "all" or "nothing" unless you give them something to click.
Whilst checking into the issue I ran the application from my local PC and came face to face with the new security features of FP8 from a user perspective.
All I can say is I hope it is improved by the time it is released.
The application basically links to our site and downloads an XML document and some jpg's.
First I got the message box saying that a potentially dangerous thing had been stopped and I needed to click settings if I wanted it to go ahead, fine so far. Bit to long a delay while it fires open a new browser and heads of to the MM site to show the security setting screen but ok if this is really unavoidable. Once there it took me a while to realise that I needed to add the url of our server as a trusted location and restart but OK got that done.
On restart I get the same message, again go to MM site, so maybe I got the wrong url, so I enter another of our servers url's as trusted and restart.
and again... and again... didnt matter what I put in it wasn't what FP8 needed.
So in the end I just clicked the option to say just trust everybody..
Thats fixed it..
Now this may be just a beta issue, but a suggestion here.
When you go to the security page why not tell me what the url the application was trying to access was and then just give me the option to say "OK that one is good" 'cos in reality no user is going to actually enter trusted sites it will be "all" or "nothing" unless you give them something to click.
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.
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.
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:
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.
Subscribe to:
Posts (Atom)