flex preloader not working with # in the url (deep linking) - apache-flex

I can't get flash preloaders to work when there is a a # in the url of my page (even without any deep linking libraries or logic). I am using flex 3.3. Flash plugins 9 and 10, all browsers.
There is this bug regarding # in the url preventing preloaders from working:
http://bugs.adobe.com/jira/browse/SDK-14162
However, somehow, someone, somewhere has ways around this. Here are somewhat working examples (remember to clear your cache to ensure you see the preloader awesomeness):
http://www.adobecards.com/index.html#wtf
http://www.escriba.es/base_en.html#wtf
http://www.sonypictures.com/movies/onceuponatimeinmexico/site/mexico.html#wtf
http://instinct.ru/flash.html#wtf
http://www.alternativedesign.tv/plant5.html#wtf
However, these do not work (no preloader at all or momentarily stuck on 100%):
http://www.flashmagazine.com/articlefiles/preloader_finished.html#wtf
http://www.mariaclaudiacortes.com/colors/Colors.html#wtf
http://whoswestudios.com/flashsite.html#wtf
http://www.iotashan.com/examples/NotSoCustomPreloader/index.html#wtf
So, what is going on here? I suspect the flex framework.
Anyone know where to look in the flex code? Or is this bug deeper than anyone but adobe can fix?

Few things going on here.
(1) Looks like the quickest pre-loader from my #wtf examples is from Adobe. They load a very small container.swf, which then loads their 3mb main swf (amongst other biggies).
(2) Some of the others "preloaders" aren't really preloaders. Their opening animations play when the whole thing is loaded.

I believe the problem you are having is that you have your assets loading into the same frame as your preloader assets and code. Flash doesn't display a frame until it has been loaded to its entirety, cause your preloader not to be seen during load, and then covered up by the new asset after.
As a flex developer you do not have a timeline, so this is why it is important to use a small "container" as you call it or as loader movie. This movie is to have a tiny foot print so that it is available asap. Upon completion of load, the container can then call the main movie into itself, tracking the incoming data with the ProgressEvent.
It is hard to know exactly what the issue is from what you have said, but this is a common problem. Fonts, and any other embedded items either need to be embedded on frame 2 or laterm which I believe you can only do with the flash IDE, or you require the extra loader swf, lightweight and quick to load!
I have successfully deeplinked the following with preloaders
http://www.madagascargame.com
http://www.kungfupandagame.com

Related

How to reduce SWF filesize by optimizing the code?

Considering we have already done the following actions:
Flex Framework as RSL
Compiling with debug=false
Loading most images at runtime
Drawing other simple images with flash draw features
Reducing complex images with pngquant
Creating modules for secondary features
Applying ranges to fonts
Running FlexPMD to find dead code and bad copy-paste
Running FlashOptimizer and secureSWF (with poor results)
Today our application is 1358k:
Code: 978k - 72%
Images: 270k - 20%
Fonts: 110k - 8%
We believe we spent a lot of time into asset optimization and most of the work is remaining on the code.
By analyzing our link-report, our guess is that the heavy part of the code is comming from Flex .mxml nested components. We don't think there is much to do on our pure AS classes.
Is there any analysis or coding best practice in order to reduce the impact of the code on the swf filesize ?
Thanks.
Here is the application : http://www.pearltrees.com/nicolas/137698/
In my practice I usually don't have big final swf files, so I want to mention only one thing. Using mxmlc directly we should not forget to add (for the final build of course) parameter/attribute
debug = "false"
in other way final swf will be almost 2 times bigger.
do you have an objects in the .mxml that are similar to each other that you could turn into a generic class and customize programatically?
Consider looking into preloaders and modules.
Without knowing your application, it's hard to be specific, but a custom preloader can sometimes help a lot with perceived download time. Let's face it, asking the user to idly stare at a progress bar is sad, and you can do better.
The usual example here is that your need your application users to login, or select some basic details before jumping into the main application. By implementation that first form as a preloader, your application will keep downloading in the background while your user interacts with that form.
The downside: Your preloader code doesn't have access to all the Flex goodness. You'll have to draw your UI and implement your interaction in plain old AS3. Still, the extra work can be worth it in some situations.
Flex Modules are the other thing that'd be worth looking into. In a complex Flex app, not everything is commonly used. If you cut the lesser-used bits from the main application and move them into a module you load on-demand, you may be able to save a fair amount of bytes from the initial download size.

GWT style code splitting in Flex

I do a lot of work with GWT but don't have experience of Flex. I was talking to a guy today who was looking at moving some large Flex based applications to GWT due to the Flex application getting too big and using too much memory in the browser. This is a problem I have had before with GWT - browser apps using lots of memory as all the code gets loaded when it starts.
However, in GWT 2.0 there is now a code splitting feature to overcome the problem of the client code getting too big. This allows all the code (javascript) not to be loaded as one big file on start up but instead code split into different files that can be loaded when required.
I was thinking as to if there is anything similar in Flex. I assume the Flex application code all lives in one single SWF file which loads at start-up so this approach is not possible but thought there might be other solutions.
You might want to look into Modules. Otherwise the code is in one SWF. You can also move the Flex framework code out of yur SWF. And you can always dynamically load your resources such as images.

Flex printing on OSX pushes image off the page. How can this be fixed?

My Flex 3 app prints pages just fine from browsers on Windows using FlexPrintJob (not the browser print function). However, on OSX, the left and top margins show up larger and the page gets pushed off the right and bottom. Basically, the scaling is screwed up, and I can't see any way to adjust the margins in code.
Has anyone seen this discrepancy in Flex printing between Windows and OSX? Are there any known workarounds? I've searched all over and I can't find any good info on this (other than 12 unresolved printing bugs in the Adobe Jira DB).
And please don't say "don't print in Flex". I know Flex sucks at printing, but I have to use it. Thanks!
Edit:
PDF Generation is one route and while its a valid solution for some folks, I need to print directly. I'd like to see stuff like using regular Flash PrintJob, monkeypatches to FlexPrintJob, or just ways I can format my DisplayObjects before sending them to FlexPrintJob. None of the scaling options in FlexPrintJob work. My Flex Component is at 1.0 scale. I'm not sure what else I can do except for mess around with regular PrintJob. I'm putting a bounty on this for answers in this domain.
Switch to PDF generation. There are two ways to do this without having to purchase server-side licenses:
Use our library of Flex components - clear.swc, a part of open source Clear Toolkit available on Sourceforge. This process is described in Ch. 11 of the book Enterprise Development with Flex currently available as rough cuts on safaribooksonline.com
Use open-source library alivePDF.
Don't print by Flex PrintJob :)

Difference in building swf through FlexBuilder and mxmlc(ANT build)

Will there be any difference between the swf generated by Flex Builder and mxmlc?
In my application, there is a page with certain fields to be filled in. Upon clicking a button, it opens up a popup. Upon selecting an option in the popup and clicking OK, it makes a request to the server, fetches some data and adds it to the main page.
When the swf is generated by the Flex Builder, everything works just fine. But when the same is generated using an ANT script, upon selecting a value from the popup, I get an error.
[ResultEvent messageId="8638F71F-BCB8-ACFD-E577-B6F97156374D" type="result" bubbles=false cancelable=true eventPhase=2]
This happens only when ANT is used for building the swf.
<mxmlc output="$swf_name" file="$mxml_name" allow-source-path-overlap="true" optimize="true">
I'm using the Cairngorm framework, and the swc is generated before hand.
<compc output="$swc_name">
Also there is a size difference between the final outputs.
The swf is 802 KB when generated from Flex Builder whereas its only 788 KB when generated using ANT. I haven't made any config changes in Flex Builder. It uses the default values(which I believe is optimized) for generating swf.
Am I doing anything wrong with ANT scripts? Do I need to use any different arguments so that I can remove the error which I get only when using the swf built by mxmlc?
Please provide your suggestions.
There could be differences between your configurations; have a look here -- this Adobe KB article might help you determine whether there are, and if so, what they might be so you can correct them:
http://kb2.adobe.com/cps/404/kb404341.html
I hesitate to mention this second part, because I haven't often toggled between the two compilers (I generally stick with one or the other), but I can say that I've noticed this issue before myself, and as I recall there was a brief mention, in Ely Greenfield's talk at MAX this past month, about a push with Flex 4 to achieve parity between Flex Builder's compilers and their SDK counterparts -- suggesting that such parity doesn't quite exist today. So while I don't have much in the way of details on that, it does seem there are some differences between the two.
Wish I could be more helpful on that -- maybe someone with a little more detail could chime in on it.

Linking directly to a SWF, what are the downsides?

Usually Flash and Flex applications are embedded on in HTML using either a combination of object and embed tags, or more commonly using JavaScript. However, if you link directly to a SWF file it will open in the browser window and without looking in the address bar you can't tell that it wasn't embedded in HTML with the size set to 100% width and height.
Considering the overhead of the HTML, CSS and JavaScript needed to embed a Flash or Flex application filling 100% of the browser window, what are the downsides of linking directly to the SWF file instead? What are the upsides?
I can think of one upside and three downsides: you don't need the 100+ lines of HTML, JavaScript and CSS that are otherwise required, but you have no plugin detection, no version checking and you lose your best SEO option (progressive enhancement).
Update don't get hung up on the 100+ lines, I simply mean that the the amount of code needed to embed a SWF is quite a lot (and I mean including libraries like SWFObject), and it's just for displaying the SWF, which can be done without a single line by linking to it directly.
Upsides for linking directly to SWF file:
Faster access
You know it's a flash movie even before you click on the link
Skipping the html & js files (You won't use CSS to display 100% flash movie anyway)
Downsides:
You have little control on movie defaults.
You can't use custom background colors, transparency etc.
You can't use flashVars to send data to the movie from the HTML
Can't use fscommand from the movie to the page
Movie proportions are never the same as the user's window's aspect ratio
You can't compensate for browser incompetability (The next new browser comes out and you're in trouble)
No SEO
No page title, bad if you want people to bookmark properly.
No plugin information, download links etc.
If your SWF connects to external data sources, you might have cross domain problems.
Renaming the SWF file will also rename the link. Bad for versioning.
In short, for a complicated application - always use the HTML. For a simple animation movie you can go either way.
You also lose external control of the SWF. When it's embedded in HTML you can use javascript to communicate with the SWF. If the SWF is loaded directly that may not be possible.
Your 100+ lines quote seems pretty high to me. The HTML that FlashDevelop generates for embedding a SWF is only around 35 lines, with an include of a single swfobject.js file. You shouldn't need to touch the js file, and at the most would only have to tweak the HTML in very minor ways to get it to do what you want.
In my experience not all browsers handle this properly. I'm not really sure why (or which browsers) but I've mistakenly sent links like this to clients on occasion and they've often come back confused. I suspect their browser prompts them to download the file instead of displaying it properly.
One upside I can think of is being able to specify GET parameters in the direct URL to the SWF, which will then be available in the Flash app (via Application.application.parameters in Flex, not sure how you'd access them in Flash CS3). This can of course be achieved by other means as well if you have an HTML wrapper but this way it's less work.
Why would you need 100+ lines of code? Using something like swfobject reduces this amout quite some (and generally you don't want to do plugin detection, etc. by hand anyway).
More advantages:
Light weight look cuz you can get rid of the header with all the tool bars that seem to accumulate there and even the scroll bar is not needed. This enhances the impact when you are trying to show a lot of action in a short flash.
The biggie: you get it in a window that you can drag larger or smaller and make the movie larger and smaller. The player will resize the movie to fill the window you have. This is great for things like group photos where everyone wants to enlarge to find themselves and their friends. I've done this for a one frame Flash production!
Downsides:
As with popups in general, if you are asking for multiple ones from the same site, and you want different size popups, the browsers tend to simply override the size you ask for in window.open and reuse whatever is up. You need to close any open popup so the window.open will do a fresh create. It gets complicated, and I have not been able to get it to work across pages in a website. Anyone who has done this successfully, pls post how!
Adobe should be ashamed of themselves with the standard embed, which defeats the puprose of convention over configuration. Check ^swfobject (as mentioned above) or swfin

Resources