Flex 3 - Thursday: Dramatically Smaller Flex SWF Files
DIGG IT!
66
Comments
Published
Thursday, June 07, 2007
at
7:12 AM
.
What if Flex SWF files could be smaller? (Over 500Kb+ smaller???)
What if a Flex SWF didn't need to embed the Flex Framework?
What if the Flex Framework could cache in the Flash Player?
What if the cached Flex Framework worked across domains?
What if the cached Flex Framework could be updated and versioned?
What if anyone could host the Flex Framework for caching on their domain?
Flex 3 and "FrogStar", codename release of Flash Player 9, adds support for caching the Flex Framework within the Flash Player. This feature is nothing short of a revolution for Flex applications deployed to Flash Player. Moving forward the Flex Framework will be cached within the Flash Player dramatically reducing the size of the output SWF files. Your application SWF files will only contain your code plus the Flex Preloader containing the caching/loading logic and will exclude by majority the Flex Framework. Simply put, the file size cost of using any additional component adds negligible size to your base SWF file.
*(results may vary, see Matt Chotin for details)
BEFORE PLAYER CACHE:
Flex SWF with Button
Flex SWF with Button,ComboBox,TabNavigator
Flex SWF with All Flex Framework Components
AFTER PLAYER CACHE:
Flex 3 SWF with Button
Flex 3 SWF with Button,ComboBox,TabNavigator
Flex SWF with All Flex Framework Components
Lets dive into some of the details:
Cross-Domain:
The Player Cache allows the Flex Framework to be cached for use across domains. Say the end user visits Yahoo Web Messenger and receives the Flex Framework (Flex 3.0.0 Moxie) for caching. If they then visit Picnik.com or SlideRocket.com or Buzzword or BrightCove.com, and these sites are targeting Flex 3.0.0 Moxie), these sites will reuse the Flex Framework cached within the Flash Player. Because the Framework is cached across domains many sites can receive the benefits of reduced SWF size.
Versionable:
The Player Cache supports Flex 3.0 and future versions of the Flex Framework. Your application can pick which version of the Flex Framework to use and regardless of what changed in Flex moving forward, the legacy version will just work. Each RSL cached within the Flash Player is stored under a unique SHA256 hash based on its unique binary content and signature.
Easy to Use:
The MXMLC/COMPC compilers and Flex Builder 3 makes supporting this functionality easy to use. The Flex Preloader has been enhanced to support the Player Cache features.
Security and Code Signing:
Caching of RSL assets across domains opens many security issues if anyone can cache code in Flash Player. To eliminate this risk code signing was added in Flash Player and assets using this feature must be signed by Adobe. Without this tight security model this feature could never have been added to Flash Player. The upside is that with Flex 3 going Open Source, developers can get new features and components added into the Flex Framework which supports this feature.
Failover and Hosting:
The Flex Framework RSL can be located anywhere even in multiple locations. A site using this Player Cache is not dependent on an Adobe domain or any 3rd party site. The feature includes support for failover URLS so that the Flex Framework SWF can be located in multiple locations cross domains. If downtime on a server occurs, the application will download the Framework RSL from a failover URL.
Cross-Domain RSL:
In parallel with this feature, the Flex Framework now supports Runtime Shared Libraries (RSL's) to be loaded across domains with a Cross-Domain Policy File. Say for example Yahoo wanted to provide an RSL for all Yahoo properties using Flex 3, they could host an RSL that any team could load at runtime to allow code-reuse cross-team and cross-project hosted across Yahoo domains.
Cheers to a more distributed Flex with smaller SWF files and code caching within the Flash Player. It is a great day for Flash and Flex as we can now support a secure distributed component model across domains.
Oh...
One more thing...
This is all 100% optional. If you want deployment to any build of Flash Player 9 version, that remains the default. Over time as "Frogstar" gets wide deployment we will see Flex get smaller and smaller and smaller!
What else is in "FrogStar" you ask? My lips (and blog) are sealed.
I will be covering Apollo features tomorrow. There are new components specific to Apollo and new deployment features as well.
More to come!
Ted :)
ps. Doug, I sure hope this is enough! If not there is still more. :)
brilliant! ;)
I wasn't clear on one thing. Can any body host the framework or only a trusted Adobe site?
ANYONE CAN HOST THE FRAMEWORK!!!! ANYONE!!!!
Neato. I've never had to use a DataGrid, so the new components didn't really do it for me (though any improvements to charting could be huge -- I work for a newspaper and we love doing that sort of thing). But smaller file sizes would take away any reservations I had about using Flex on our site for neat data exploration.
So when I compile I'll upload the framework and my swf. The swf will preload the framework and then load the app.
So if I have 5 flex apps the will all reference that framework cache. Like a stylesheet or linked js file?
Spoon,
YES.
1. You will upload your SWF and Flex Framework RSL.
2. When viewed your SWF will detect if the framework is cached in the Flash Player and cache the Framework if it is not there.
3. You app will run seamlessly.
Since there will be many sites using the same framework, many users will have the framework cached in the Player and thus reduce Framework loading to the first viewing of any SWF using that version of the Flex Framework.
Unlike a stylesheet or JS file, this cache is within the Flash Player and not prone to the user clearing the browser cache. Additionally it works cross-domain.
Ted :)
Great feature! I'd bet a lot of flex apps will load nearly instantly now.
So will this be in a Flash Player 9.x? or 10?
Darn. This is good for the flex community (i like Charlie's comment) but sucks for me. I only develop internal apps and we have a gigabit Ethernet connection. 500k doesn't mean anything.
Will you still blog about the chart improvements? Hopefully we will get a beta tomorrow and see them our selves!
How are failover RSL's determined by the Flash Player?
Also since this stuff is part of the Moxie beta, will we be seeing public builds of the SDK along with it? I guess this means that frogStar will be available as well with the Moxie beta or is this wishful thinking ;)
"Starting this summer with the pre-release versions of the next release of the Flex product line, code named “Moxie,” Adobe will post daily software builds of the Flex SDK on a public download site with a public bug database. The release of open source Flex under the MPL will occur in conjunction with the final release of Moxie, currently scheduled for the second half of 2007."
When cached in the Player, the Flex Framework instantiates very fast given it is on the local machine. Given there is no bandwidth delay, loading and start-up of the app are lightening fast.
It is the best of the best! Essentially it is like the Flex Framework is part of Flash Player.
Ted :)
That visual representation of improvement made me LOL. Good stuff!
-mL
http://knowledge.lapasa.net
Dominick,
Not wishful thinking. Beta 1 will provide access to "Frogstar" Beta as well.
Again I will state we are days away from Beta 1. Days, not weeks.
Ted :)
Dominick,
Failover URLS are embedded into your Flex SWF file. The preloader within your SWF will hunt through the list of URLS to complete the caching of the Flex Framework.
Ted :)
Just to make sure everyone understands:
"FrogStar" === Flash Player 9 Update 3
Ted :)
Ah. Now I know why Ely was asking how much of the Flex framework we were using... :-)
THIS IS FANTASTIC!!! The caching has been one of the reasons that I have resisted on advising clients to use Flex for the Web for large websites! The Bandwidth costs can add up significantly. However with this approach this changes everything. Now Flash CS3 + Flex will go hand in hand! At this point if you have Flash CS3 then you MUST get Flex Builder 3 because you guys have made these two platforms truly compatible and integrated! That within it self is a phenomenal achievement. Kudos. Thanks for posting Ted!!! You Rock!!!
sigh... I'd imagine a new build of Apollo then too? I'm just full of questions on this one ;)
Guys,
You are giving new meanings to static and dynamic linking :-)
Regards,
Eduardo.
Just great! can't wait to see and try the beta.
When we can expect the final release? in Q4 or Q3?
So, just so I understand how the new Player cache works (possible stupid question) -- if I clear my browser cache, will it wipe out the cached Flex framework, or are they completely separate?
Also, will there be 'hooks' in the API that allows for runtime Player cache control? (clearing the player cache, reloading the framework, etc.)
This is awesome news. Game changing, in fact. Flex will have gone from prohibitive for some applications (due to filesize overheard) to practically a requirement, if only to use that one cool or essential component/widget. Combined with deep linking... wow. :)
Keep up the good work guys!
thats awesome Ted!
Thats probably the best thing that happened to flex!!
Btw, this new caching feature for Flash player, will it be provided only for the flex framework, or will it be extended to any code library?
Can end users opt out: ie) not cache framework?
A.) This is awesome
B.) Couldn't you have a similar process for adding WebKit to the player so we can use real HTML in our Flex apps? Couldn't the player be modified to download extra features if an app requires them? There's a lot of demand for this, just look at the search terms that have brought people to my blog in the last two days:
div on top flash safari
div on top of object
display div on top of flash player
how to display message in div in flex
People want to build ad-supported Flex apps but online advertising is an HTML-based world. Making it easier to make money from Flex apps will spur demand for Flex.
flex 3 have WebKit control ???
it tell me that yessss
Wow! This is great.
I love the "One more thing..." especially from you, especially this week!
Is flex 3 going to make coffee?
Ted your blog is so hot for the community!
Thank you.
Will there be an option to allow a Flash app (signed, or user-trusted, or something) to access any internet site, without crossdomain file. This is a serious limiting factor for us in using Flex now. We are doing an integration app in flex - and now we either have to get all (over hundreds) participants to add crossdomain files or have the app donloaded to the user disk (updates are hard).
would it cache multiple versions of the framework to support legacy flex applications? or is the flex framework backward compatible?
@Andris,
Even with crossdomain.xml, the Flash security model is by far the most open one for web applications.
Without crossdomain.xml files installed, or without Flash, your only option is to proxy your http requests through your server.
That said, if Apollo has an application update mechanism, it could fit your requirements quite well.
Ted, I'm a bit confused on your statements about code signing. Are you saying that we could make our own site frameworks cacheable? That would be truly awesome. Or was that feature intended only for open source code that is intended to be merged into the Flex framework (i hope not)?
That's great! But, on the other hand, will flash player host many different flex frameworks? Because this would make it heavy... Hopefully there will be some "clear cache" mechanism inside player. Anyway great post, this sounds like "big times are coming" for flex :)
Hi Ted. Awesome news...
I know this question has been already asked but, will the cache function work with other framework / library ???
Mybe the end users will complain with the player update which become more and more frequently!
@sharpbeans > the process will be transparent for the end user. when he will go on a website and need the framework, if this one is not cached it will be loaded. the user will see the progress bar as he is loading the application ( which he is actually doing ). It will not be an update of the player itself ( not really )
Maybe soon we'll be talking about the Flex Player... ;)
This is fantastic! Thanks for sharing Ted. Can't wait to get our hands on it.
Just about every disagreement I've ever had with users who felt I chose wrong by migrating to Flex usually ended with them shoving the file size issue down my throat as the token slam dunk (read cheap shot).
Glad to hear you've pulled the rug out on that argument. :)
This is really an exciting year!
Hi,
Really great questions on the cache -- I'll try to roll them up into the faq for the Adobe Labs beta :-)
@joeflash
Clearing your browser cache will not clear the player cache. Users can do so through a new settings in the Settings Manager. It is not available yet, but will be on release.
There are no hooks in the player for an app to clear the cache or to reload it. This happens auto-magically -- if what you need is not there, the player goes to fetch it. The cache is default 20MB (right now) and once it is full it boots the oldest component to download the new one being requested.
@ hosey
Yes, end users will be able to disable the player cache through Settings Manager
@ Brett Walker
For the player cache, only signed Adobe platform components, such as Flex, can be cached.
@zeflasher
The Flex framework is one of the first signed Adobe platform components that can be cached by the Player. You can imagine that we will continue to develop libraries and components to provide other great capabilities for content and applications.
best,
Emmy Huang
Product Manager, Adobe Flash Player
Hi Ted,
By when we can expect a release of Flex 3.
Hi ted,
I'm really exited about the beta features!
However i have some feature requests to make the platform even better. The question is. What is the right address to post requests/bugs etc?
looking forward to the beta!!!
Arnoud
No more sleep for me - ever. The more I learn, the more I realize there is to learn. Exciting times - this is such a great addition to the Flash Player and Flex that I almost fell out of my chair while celebrating. I guess I shouldn't dance while standing in it. :-)
Very impressive!
@Emmy
> only signed Adobe platform components
> such as Flex, can be cached.
What? That's barely unthinkable!
How can Adobe close the player to it's own components???
If it's the case, that a very bad news for AS3 developers...
if not (the cache will be open to any component, like the local memory), it's a marvelous news !!
This was probably the only concern we had with our flex application. Now Flex is the ideal platform to build our RIAs.
Hmmm... I wonder what would happen if someone hosted a bugged version of the framework. People might then get the bugged version cached in their player, and not know how to remove it...
Tony,
The cached SWF is signed by Adobe and is sha256 hash validated against the actual bytes within. If the SWF is not signed it would not cache and could not be used.
Your logic here is correct, this is the security hole that we are preventing in making Framework Cache only open to Adobe signed files.
Ted :)
Will the Flex framework be downloaded and precached along with the Flash Player 9 Update 3, or will the user have to first go to a site that has a Flex 3.0 app to have it cached?
I can see arguments for both ways. On one hand, it seems kind of silly not to include such an integral framework, when it will end up just being cached immediately afterwards, and also force these many sites to host the Flex RSL. On the other hand, including it adds a lot of size to the initial Flash Player download.
Care to clarify, Ted?
Many thanks,
Mike Welsh
Will the Flex framework be downloaded and precached along with the Flash Player 9 Update 3, or will the user have to first go to a site that has a Flex 3.0 app to have it cached?
I can see arguments for both ways. On one hand, it seems kind of silly not to include such an integral framework, when it will end up just being cached immediately afterwards, and also force these many sites to host the Flex RSL. On the other hand, including it adds a lot of size to the initial Flash Player download.
Care to clarify, Ted?
Many thanks,
Mike Welsh
this is a bit out of theme but WTF is with textIdent property in moxie?
it just makes me mad please try to use and back to sdk2...
Hi,
Thanks for sharing first.
I need an urgent solution for my problem. I build an flex app. It is about 259 K. And searhing how to reduce its size, I saw that RSL
should be used. Download and recomplile it with flex 3 using framework RSL. now my app is 94K. But the framework library is 500K.
So, total is nearly 600K.
I got the Idea of caching, But I wonder to know something.
This caching is only available for flash player 9.0.60
As said in
http://labs.adobe.com/wiki/index.php/Flex_3:Feature_Introductions:Flex_3_RSLs#How_to_use_the_Flex_Framework_as_an_RSL
"Notice the message below the table about requiring Flash Player "9.0.60". Since only a single signed RSL was specified, Flash Player 9.0.60 will be required to run the application because it is the lowest version that knows how to load RSLs signed by Adobe. To allow the application to used by down-level Flash Players add an unsigned RSL as a failover. At runtime, if the Player running the application is less than version 9.0.60, then the signed RSL will be skipped and the unsigned RSL will be loaded. "
So for the users who has older version of flash player, require to download this 600K. They cant use player caching!.
Am I right or miss something?
Thanks in advance..
Why doesn't Adobe just embed the flex framework in the Flash Player, instead of 1 required download for caching? The 500k punishment for users without the cache has kept me clear of taking advantage of using the signed RSL.
Flex framework caching -- can I assume this is essentially the same thing as JAR caching in the Java plugin?
I hope so! That's been a very effective way of minimizing download time for Java apps for years.
Just looking to relate this to something I'm already very familiar with.
Is there anyway to cache the Flex Framework in Flex 2? Since the Flash Player is available now, this would be fantastic. But I have no idea how to create the .swz file and it seems not to be documented?
fantastic ..
Ted, if you could point to some links for updates on this. It would be of great help. Also, some links on RSL ;-)
Thanks
--
Chetan Sachdev
when the cached flex framework needs to be updated, will the entire package have to be downloaded? My concern is having the user who just needs the update to, say, the datagrid component would have to download the whole 500k+ framework again. Also, could you confirm that the users without the player 9 update 3 version will be forced to download the 500k+ framework even if the application does not use any components, which amounts to about 150k of code? Or would you have to require player 9 update 3 if you want to support caching the framework?
As said before, app nows = 80Ko + 500Ko instead of 200Ko, but if Flex lib has cached, app is also, no? So it's better to download 200Ko and cach it instead of download 80+500 Ko and cach it too. So solution of RSL is not very usefull ;-(
The only solution is that Adobe put into the Flash Player the Flex framework, anyone has an idea of this issue?
Does anyone know where the framework files end up for the Firefox flash player plugin?
I need to remove them in order to verify that I've got the relative path right both offline and on our server.
(Sorry if this ends up as a double post. If it does, I blame a different kind of cache.)
C:\Documents and Settings\currentUser\Application Data\Adobe\Flash
Player\AssetCache\2242EB4H\5E68E1848D7A13D588876E6C0B4866CB76D0D3E2.swz
of course the folder name and filename at the end vary, and this is
for XP it is different but similar on a mac, not sure about Vista, but
think it is at least similar
Regards,
Hudson
@Hudson: Yeah, that's where it ends up if you use IE. In my experience Firefox and Safari don't copy the framework to that location though.
It works now though. Very spiffy! Well done! :)
Hi Ted on Flex,
The idea of RSLs is great but as far as I can tell, the method doesn't degrade gracefully.. From Adobe: "if the Player running the application is less than version 9.0.60, then the signed RSL will be skipped and the unsigned RSL will be loaded." Where do we get the unsigned version of the RSL? Does Adobe provide unsigned versions of it's framework? And also assuming one was to get a true unsigned failover swf, the app would still die because is has been built, in all likelihood, against the framework libs which are SIGNED. Am I missing something here? I couldn't get rsls to failover at all for earlier flash players.
FYI - flex 3 files sizes
empty flex app
debug build - 345k
release build - 215k
Great tip, thanks
Maybe in the next release Adobe could provide a means to specify a path for RSL's that is relative to the SWF location instead of the html page it is embedded in.
Most of us know that if you are serving a widget on a social network (or many social networks) you must provide a fully qualified URL for the location of your RSL. This isn't always possible.
A simple variable (such as {SWF_PATH}) would go a long way.
Developers have full access to the same framework APIs used by the core applications. The application architecture is designed to simplify the reuse of components; any application can publish its capabilities and any other application may then make use of those capabilities (subject to security constraints enforced by the framework). This same mechanism allows components to be replaced by the user.
***************************
shanmarsh
Size 28 Clothing
Great site. I will bookmark for my sons to view as well..
I work for a newspaper and we love doing that sort of thing...This is what i need..thanks
I never think about this font could be in use