In regaurds to your question about loading framework classes over the network and wanting one swf, I think your answer is in this;
<!-- static-link-runtime-shared-libraries: statically link the libraries specified by the -runtime-shared-libraries-path option.-->
The above line is found in the flex-config.xml and is turned OFF by default right now.
Navigate to your sdk directory, find the flex-config.xml file and set the value to true. This will create all needed classes in one swf.
Thanks for the fast response. Do you know if this will be returned to
'true' by default in the future? Any particular reason the SDK's
beyond 4.0.0 are implemented in this way? I suppose I can see some
I wish I knew, I had a pain in the... when they first switched. I couldn't understand why the debugger was trying to load the text layout framework.
Seems like this might be for the beta. I know Adobe has a motto, give functionality, turn it off and let the developer enable it. If they left this compiler arg on, it would seem like they are going against that principle.
I agree that providing developers with the option to choose which
functionality they wish is a good approach. However, when a developer
doesn't know that they do, in fact, have choices or know how to change
choices that have been made for them - then it becomes a problem. I
didn't know anything about the static-link-runtime-shared-libraries.
One day it worked one way, the other.. another. So, I agree in choices
but we should know how to make them if we don't like what's been
chosen for us.
There's an option in Flash Builder to set the framework linkage. Go to your project properties, Flex Builder Path > Library Path tab, "Framework linkage" and select "Merged into code". This will include all your dependencies in your SWF instead of loading RSLs at runtime.
Jason San Jose
Quality Engineer, Flash Builder
Thank you Jason. I had, in fact, never actually noticed the 'Framework
linkage' menu option before!
I'm not sure if this will stay as the default option in the future, but I think the reason for the RSL:s not to be included in the compiled swf by default is that Adobe wants users to start caching the framework libraries in the Flash player. The rationale behind this is that the first application to load a particular RSL will have the overhead of having to download the file. The next application that needs those same RSL:s will not have to download them, since they're already in the cache of the Flash player, and thus the download size of the new application will be smaller and startup time will be faster. Now for extremely domain specialized RSL:s (like e.g. your own custom library) it will probably not make much of a difference whether you include it in one swf or load it as a RSL. But for framework RSL:s that come with the SDK, it's probably wise to link to them instead of including them in your compiled swf. Reason being that it's very likely that there will be a whole bunch of applications out there using the same version of the framework, and thus it's very likely that a user will already have those RSL:s in their cache = faster startup time for your application.
Thank you for clarifying this for me. I suspected it was something
along those lines. I can certainly see the benefits.