Aral on Flash, SWX, Flex, ActionScript, and life.
The Pistach.io Flash Pack is proud to support the PaperKing3D Papervision3D Contest with pro bono ads.
The PaperKing3D ad will be run on all of the following member sites of the Pistach.io Flash Pack: Alessandro Crugnola, Andre Michelle, Aral Balkan, Chad Udell, Flash Magazine, Grant Skinner, Keith Peters, Marco Casario, Mario Klingemann, OSFlash, Peter Elst, and Seb Lee-Delisle.
Best of luck with the contest guys! I can't wait to see the awesome stuff this contest will no doubt result in.
Well, it appears that Google has already started using this new indexing system and some Flash developers are not happy by how much it is revealing about their applications.
Peter Elst, a prominent Flash developer (diclaimer: and member of the Flash Pack on Pistach.io, of which I am a partner), just Twittered the following:
oh no, SWF indexing seems to do just as I feared -- already noticed Google was picking up my test Flash SEO swf but its now exposing URL's
And posted his concerns on his blog, wherein he quotes Ryan Stewart from Adobe on what exactly is getting indexed:
… it will move through the states of your application, get data from the server when your application normally would, and it will capture all of the text and data that you’ve got inside of your Flash-based application.
Peter goes on to state why this could be dangerous:
The concern I have here is that URL requests to the backend will get indexed, those URLs getting exposed in search queries or spider bots hitting those URLs could cause issues. Its not like in HTML content where the search engines can ignore form submit URLs, there is no such context in a HTTPService or URLRequest.
Do you remember the damage Google Web Accelerator caused when it started deleting data by following badly-coded links in web applications? The problem there was web developers using GET requests for non-idempotent operations such as deleting data. It remains to be seen how zealous this indexing is with regards to following data calls from Flash and Flex applications and what, if any, side-effects this will have.
Peter also mentions that the SWF indexing is not opt-in but that's a fact of life with search engines in general and not something that is unique to Flash content. I am sure that this new indexer will follow the instructions in your robots.txt file.
Unfortunately, Flash developers have also been harboring under a false sense of safety that because Flash bytecode is compiled, they can put sensitive information inside their SWF files. I've been warning about the dangers of doing this for years now but this latest development should hopefully help to educate Flash and Flex developers that anything they put in a SWF should be considered public information. Previously, the only security afforded by the bytecode representation of SWF content was security by obscurity -- which we know is not security at all.
To quote Kristof, who posted a comment on Peter's post:
Argh! Google has actually started indexing my Flash Files and is revealing all the URL’s of the pictures in Flash. But also the url’s of the MP3’s I placed in Flash. I was hoping Flash would conceal it - because now, anyone can download our music without paying for it.
I don't know if Google is actually exposing URLs received from data calls or whether the URLs were hard-coded into the SWFs but, if the latter is true, than that information was always available to anyone with a decent SWF decompiler. It was just a little harder to get to.
I'd love to hear your thoughts. How is the new SWF indexing feature of Google and Yahoo! impacting your SWF applications? Leave a comment and let me know.
Buying an ad on the Pistach.io Flash Pack puts your ad on all of the following web sites: Alessandro Crugnola (sephiroth.it), Andre Michelle, Aral Balkan, Chad Udell, Flash Magazine, Grant Skinner, Keith Peters, Marco Casario, Mario Klingemann, OSFlash, Peter Elst, and Seb Lee-Delisle.
Find out more on the Pistach.io web site.
The Pistach.io Flash pack has officially kicked off and I want to take this opportunity to thank our first advertisers.
Ads for Flash Page Flip by Design Positive are currently in rotation and ads for Electric Rain are going to be up shortly.
Register your interest if you would like to advertise on the Pistach.io Flash Pack.
Buying an ad on the Pistach.io Flash Pack puts your ad on all of the following web sites: Andre Michelle, Aral Balkan, Chad Udell, Flash Magazine, Grant Skinner, Keith Peters, Marco Casario, Mario Klingemann, OSFlash, Peter Elst, and Seb Lee-Delisle.
Find out more on the Pistach.io web site.
Update: Use promo code ABALW5 to get 5% off the price of your Pistach.io ad.
Why are some things just much harder than they need to be? Finding a current, easy-to-use data source for populating a country selection box, for example.
Most of the clean country data out on the web is second-hand, having at one point in time been scraped and tediously hand-converted from the International Organization for Standardization (ISO)'s page of English country names and code elements.
That list "states the country names (official short names in English) in alphabetical order as given in ISO 3166-1 and the corresponding ISO 3166-1-alpha-2 code elements" of 246 countries and is free to use.
Unfortunately, it's an HTML table. Which means that you have some manual data massaging to do if you want to use it. Sucks big time.
ISO also sells the ISO 3166 "database" for about $148 USD. And it comes in -- get this -- Microsoft Access format. I bet we've all got a copy laying around somewhere, right? Oh wait, it's not 1999! So they want to charge you about 60 cents per country name? Not acceptable.
So what's a developer to do? Scrape the site? Write his one-line regular expression to pull out the data? Solve his own problem and move on?
Nah, let's make things better so that other developers don't lose precious time having to jump through ridiculous hoops! 
Et, voilà, I present to you Open Country Codes.
This simple and deliberately unstyled little app gives you the ISO 3166-1 and ISO 3166-1-alpha-2 country name and country code lists in a variety of ready-to-use formats. There's an HTML country list selection box that you can drop into your page, and pure data structures in Python, JavaScript, ActionScript and a CountryComboBox component for Flex.
There are also JSON and XML feeds that you can use in your applications.
The application pulls in a fresh copy of the list every day and the code samples are dynamically generated.
I hope you find this useful. If you have any suggestions for improving it, please leave me a comment here.
You can find a list of fixed issues in the release notes, including the template cache issue that I was running into.
Also, it's not in the release notes but I just confirmed that the app.yaml skip_files issue has also been fixed. So you don't need the patch any longer.
I also tested the latest version of The GAE SWF Project and it works out-of-the-box with version 1.0.2.
Bad decision. This needs to change.
Enabling accessibility features for The GAE SWF Project resulted in an 8KB file size increase in the SWF file. I can live with that. Creating inaccessible SWF files to save a couple of KB is no savings at all.
The Flex accessibility overview page feels woefully outdated and mention Adobe Flash Player 7. We're on 9 now. Let's update these, guys!
It also reads more like marketing talk then factual information for developers with phrases like "designers and developers can create powerful, exciting, and engaging experiences on the web that are accessible to all" and "it's never been easier to design accessible Rich Internet Applications." Let's cut out the marketing talk and concentrate on the facts. If we feel that we need to dilute or detract from the facts with marketing talk, maybe we need to concentrate on changing the facts.
The Accessibility Best Practices for Flex document, on the other hand, does an admirable job of disseminating important information that is useful for developers.
It is also important to note that the accessibility features of the Flex components have been optimized for use with JAWS on Windows and that users will need to install additional JAWS scripts to enable these features. Why aren't these scripts included by default in JAWS?
The best practices document is very useful but I feel that we would benefit for a short, succinct and no bullshit summary to quickly inform developers on the state of accessibility in Flex. Something along the lines of:
Finally, bookmark the Accessibility Resource Center on Adobe.com and keep checking back for new articles (and bug Adobe if you don't see any!)
Note that your document class in Flash projects should extend org.gaeswf.flash.BaseApplication and your Application MXML in Flex should be of type org.gaeswf.flex.BaseApplication (if none of this makes any sense to you, see my Flex 3 Code Behind Quick Start.)
Remember that I'm constantly updating the framework and will continue to do so as we build Singularity. Expect changes!
Update: Apparently, I blogged it but didn't push it up to appspot. Doh! So instead, you get an even more updated version 1.34 now.
The new additions are currently only to the Flex client and include a public state in addition to Home (which led me to revise and generalize how I was handling the deep links back from login and logout to support apps with a mix of authenticated and non-authenticated states).
The new public state is called "Mouse wheel" and demonstrates how to make the mouse wheel work in Flash on OS X (it doesn't by default) by using Ali Rantakari's excellent ExternalMouseWheelSupport package.
Update: I just saw that the site had validation errors which I've now fixed. It validates as HTML 4.01 Strict. This is not in the 1.34 source release but will be in the next one.
In the meanwhile, the suggested workaround is to add debug=True to your template.render() methods (pass it as the third argument, i.e., after the context).
Update: As of 2.30pm (when I last checked), the app appears to be working again. I've made no changes whatsoever.
If you hit the Flash or Flex client on The GAE SWF Project right now, you will be greeted with a page long traceback.
I've just opened issue 273 on the Google App Engine Issue Tracker to track this and added this comment on the forums.
The problem is that the error never occurs locally when developing and testing with the Development Web Server and randomly starts happening on appspot (the app will work well for stretches of time and then start failing 100% of the time.)
The last time this happened, issuing an appcfg.py update . fixed the issue but I'm not going to do that now in hopes that seeing the error will make it easier for Google's engineers to fix it.
The updates in a nutshell:
Bad Behavior has blocked 0 access attempts in the last 7 days.
Recent Comments