7/25/2008

Image loading with security sandbox fun.

Just a note in case anyone runs into this.

Loading an image from an external domain without a crossdomain.xml file can be tricky. typically I want to just grab the content of the loader and use it to be referenced for whatever. But in this case, when loading from an external domain that doesn't have a crossdomain.xml file you don't have the ability to do this. I ran into this today, as I have a loader that loads content like swfs and images from a domain that isn't flash friendly. I found the easiest way to run a check on what you loaded is to just check the url in the loader.

if(myLoader.contentLoaderInfo.url.lastIndexOf("swf")==-1)
{
    trace("This is an image")
}else{
    trace("This is a swf and I can access the movie clips within.")
}

ok bye
O.o

7/10/2008

What the Heck are Runtime Shared Libraries?

So keeping in the topic from my previous post of low overhead flash apps, I decided to talk a little bit about runtime shared libraries.

So what are Runtime Shared Libraries?
These are libraries that are used just like you normally use your libraries in Flex 3 but instead of storing them within the swf, during runtime it grabs the libraries from a specific place and loads them then. The difference is that if the user has already loaded that library then he/she needs not load it again, resulting in a faster load time.

But, not all libraries are treated equally. There are two different types of libraries, and they are cached in different places.
If the library you use is a typical Adobe one, like the framework.swc library, since it's signed by Adobe, it get's cached in the flashplayer itself. This results in a continuous cache throughout other browsers as well, assuming the user doesn't change his/her security setting for their flash player. Whereas, if you create your own library, which would not be signed by adobe, it's stored in the browsers cache. This is not bad either since as long as the user doesn't clear their browser cache they're good, though it isn't cross browser.

So there ya have it in a nutshell. For a little more in depth article on this topic visit this article written by Darrell Loverin at the Adobe Developer Center

XMLSyndication

So Last week I did a presentation on the adobe xmlsyndication package and the use of css within an as3 environment sans mxml at the flashcodersny meeting. I think all in all it turned out pretty good but there were a few issues I noticed.

The first being the dependancy on the adobe corelib package and the second being the dependancy on the flex library for a single thing. So I refactored their xmlsyndication and now it relies on nothing. In fact I was able to just about halve the size of my swf file because of this. In fact, I am able to rely solely on the playerglobal.swc which is the only actual library you need to publish swfs.

Why did I do this? Well, I think it's just that there seem to be too much reliance on other packages for things that don't really do that much. Relying on all of this will inevitably bloat your swf and cause load times to increase thereby driving people away from your flash reliant site. Granted in today's world many people have high speed internet access, sure, BUT when you start creating massive applications this can have a very dramatic affect on the size. Which will leave you with a massive application unless properly externalized and organized.

I'll be posting a link to the O'Reilly article once I'm done writing it. Yup, that's right, JC was mighty impressed and wants to add this to the O'Reilly's insideRIA site.
Sweet...