RangeError: Error #2006: The supplied index is out of bounds.
	at flash.display::DisplayObjectContainer/addChildAt()
	at mx.core::Container/addChildAt()
	at mx.effects::EffectManager$/removedEffectHandler()
	at Function/http://adobe.com/AS3/2006/builtin::apply()
	at mx.core::UIComponent/callLaterDispatcher2()
	at mx.core::UIComponent/callLaterDispatcher()

It threw me for a minute because I hadn't made any changes to effects since I last tested the application and I couldn't see any connection between the code I had just written and any effects in the app. But after hunting around I found the culprit. There's a set of components in a Canvas that gets removed when moving to the parent state. What I had done was separate those components into two Canvases(Canvi?). For whatever crazy reason the new second Canvas can't have a RemoveEffect. The code works fine if just the first Canvas has it, but if both or just the second Canvas has it then it throws that error.

side note: the reason it took me a while to find the source of the error was because I copy/pasted the canvas declaration only changing the id, and I forgot that there was a removedEffect associated with it.

But wait there's more. The reason I split the components into two distinct Canvases was so I could position one below and the other on top of a third major component in z-space. The solution was to add the first Canvas as a "firstChild" and the second Canvas as a "lastChild". That it seems was the problem. In mxml when changing states you apparently can't add a firstChild before adding a lastChild. so I copy and pasted the first Canvas below the second one, so that all the lastChild additions occurred before all the firstChild additions and voila, presto, it works.

The reason is that when you move from a state back to its parent state it follows the order in which you add components in the state declaration to remove them. If the first component you add is added as a firstChild then that get's removed first changing the indexes and number of children of the parent container. I guess the underlying state changing function already calculated what the lastChild index was, so when trying to remove a Child with the pre-calculated index of lastChild it triggered an index out of bounds error.

I figured I'd post this cause the location of the AIR Application Installer that you would want to be associated with .AIR files eluded me.

So to fix it just right click on the .AIR file. Choose "Get Info". In the Info window expand the "Open with:" arrow, and make sure "Adobe AIR Application Installer" is selected. If it isn't choose "Other..." in the dropdown list and navigate to Applications->Utilities->Adobe AIR Application Installer, select it and tick the box that says "Always Open With" before clicking "Add". Then back in the Info window click the "Change All..." button to apply it to all .AIR files.

This worked fine but now in it's spark implementation when moving between random states the button label if it contains a single space will occasionally jump around - providing you've rolled over the button before changing state. It would take a boring while to explain it in more detail so I just recorded the behaviour. Best watched in full screen.

The fourth iPhone OS is going to be announced tomorrow at 1pm(EST). The updates should propagate to iTouches and iPads as well. Things expected and hoped for include multitasking for 3rd party apps, wireless syncing, unified inbox, better maps, and some other shit.

The question is why Apple is making so many announcements, when they usually have very few meticulously planned expansive ones.

Adobe CS5 is launching in 4 days, watch the countdown here [http://cs5launch.adobe.com/]. During Adobe's announcement they will let us know not only about a huge leap in performance and features of the tools everyone uses (ie: Photoshop, Illustrator, etc.) but also tools to export apps built with Flash(formerly Flex) Builder to the Apple app store. Currently you can build an app in Flash Builder and deploy the same code on the web, and on the desktop with AIR. Very soon, hopefully in 4 days Flash Player 10.1 and Adobe AIR 2.0 will be released allowing the additional output of your same code to most smart phones and portable devices as well, and very low level socket support and advanced text support, among many other features and less resource consumption making it a truly compelling option for serious apps deployed across all screens.

Once Adobe announces this everyone is going to be making iPhone, iTouch, and iPad apps in Flash Builder so they can develop once deploy everywhere. Apple deliberately blocks Flash on iDevices because they want people to learn Objective-C (the language for making iPhone apps). If you spend money learning Objective-C and clients want to jump on the iPad and spend money hiring developers who already know the language then you're only able to target iDevices, and now with the screen size and performance of the iPad you then have to rewrite and rerelease a version of your app specifically targeting the iPad. Objective-C is a really shit language, and solely dependent on Apple products[apparently not according to Nick's comment - better take his word for it].

So Apple is racing to get each thing out as soon as they're ready to beat the launch of Adobe CS5 so as many clients and developers lock into Objective-C as possible. Apple lost millions of users because they refuse to support Flash which even though the web is now slowly moving to support the limited and unofficial HTML5 video spec along with IE and other niche technologies for compatibility's sake, Apple purposefully restricted their mobile devices from 70+% of the video on the web and the vast majority of interactive content to the end of being anti-competitive. They upset clients, lost more, and tarnished their company image for years. Now CS5 is coming out and it'll make their anti-competitiveness irrelevant and pointless. So Apple needs to squeeze out products and features and create lots of buzz and chatter to try lock in as many people as possible and I guess attempt to overshadow the CS5 announcement so nobody notices.

Flash Snippets [http://theflashblog.com/?p=1494]

Before I quote the email I'd just like to add my own heart felt sentiments: Please die Internet Explorer 6. Please die now. You're very old, insecure, and stupid. Please die fast but painfully for putting the world through extended support and allowing yourself to exist for what? almost 10 years now?!

Dear Google Apps admin,​

In order to continue to improve our products and deliver more sophisticated features and performance, we are harnessing some of the latest improvements in web browser technology. This includes faster JavaScript processing and new standards like HTML5. As a result, over the course of 2010, we will be phasing out support for Microsoft Internet Explorer 6.0 ​as well as other older browsers that are not supported by their own manufacturers.

We plan to begin phasing out support of these older browsers on the Google Docs suite and the Google Sites editor on March 1, 2010. After that point, certain functionality within these applications may have higher latency and may not work correctly in these older browsers. Later in 2010, we will start to phase out support for these browsers for Google Mail and Google Calendar.

Google Apps will continue to support Internet Explorer 7.0 and above, Firefox 3.0 and above, Google Chrome 4.0 and above, and Safari 3.0 and above.

Starting this week, users on these older browsers will see a message in Google Docs and the Google Sites editor explaining this change and asking them to upgrade their browser. We will also alert you again closer to March 1 to remind you of this change.

In 2009, the Google Apps team delivered more than 100 improvements to enhance your product experience. We are aiming to beat that in 2010 and continue to deliver the best and most innovative collaboration products for businesses.

Thank you for your continued support!

Sincerely,

The Google Apps team

Gizmodo, who were some of the idiots I referred to in my post yesterday redeemed themselves by publishing a very comprehensive breakdown of why HTML 5 isn't saving anyone anytime soon 40 minutes ago, and (although they only briefly touched on it, being that the post is primarily about HTML 5) why Flash is better at doing the kind of things HTML 5 is supposed to usurp in imagination land.

HTML isn't platform ubiquitous and never will be because whoever has the monopoly is also directly motivated to keep web standards to shit. Companies are companies and the monopoly will always be a company.

Flash on the other hand is already platform ubiquitous. Write once, deploy everywhere. The only problem with flash is resource use, which 10.1 - already in 2nd beta will address.

Flash also now has the ability to run native c/c++ code, so decoding video with flash will be as fast as doing it natively in the browser. Well as doing it natively in the browser will eventually maybe possibly in 5-10 years if the web can come together in happy fairy land on HTML 5 implementation.

Goodbye Flash?? I say goodbye web browsers and hello Adobe AIR branded front ends to web services and content.

Here's a small excerpt from John Herrman of Gizmodo's comprehensive HTML 5 breakdown, although I strongly recommend you read the whole thing as it makes things clear for the tech - and not so tech, savvy:

...

The Basics

Before we get into what HTML5 means, we have to talk about what it is, and to talk about what it is, we need to talk about what it's built upon.

Hypertext markup language, or HTML, is the language underneath every web page you've ever been to. The language, along with its various complementary technologies (see: CSS, Javascript), has become immensely complex over the years, but the concept is simple. HTML is what turns this:

<u><em><strong><a href="http://gizmodo.com">Hello!</a></strong></em></u>

Into this:

Hello!

It's basically a set of instructions that a website hands to a browser, which the browser then reads and converts into a formatted page, full of text, images, links and whatever else.

Here, try this: Right-click anywhere on this webpage, and click "View Page Source," or "View Source," or something to that effect. Your eyes will be assaulted with a wall of inscrutable text. You'll see evidence of syntax, but your brain won't be able to parse it. Your eyes will glaze over, and you will close the window. This, my friends, is HTML. But you probably already knew that, because it's 2010, basic web languages are basically in our drinking water. So what's this "5" business?

Somewhere in the central command center basement of the internet, there's a group of guys who maintain the standard, or the rules, of HTML. In the case of HTML5, the buck stops with the Web Hypertext Application Technology Working Group (WHATWG), and to a lesser extent, the World Wide Web Consortium (W3C). It is through these independent standards organizations that new features are codified and presented to the public, and later—in theory—supported by various browsers, no matter what company is behind them.

In the early nineties, the W3C and a few influential torchbearers would collect various new web features thought up by different browser makers, publishing these standards with the hope that we didn't end up with different internets for different browsers. By the mid to late nineties, the standards had grown in both size and stature, then serving as the de facto guide for browser makers and developers alike. (If this sounds a bit rosy, the reality was far grimmer—just ask any seasoned web developer about Internet Explorer, version 6 or earlier.)

Despite an occasionally rocky road, HTML standards went beyond being just a record of changes in web technology; eventually they became the blueprint to push them forward. Still, standards are guides, not laws, and no browser maker has to adopt each and every revision.

The last major revision of the HTML standard, version 4.01, was published in 1999. HTML5 hasn't yet been formally codified, but it was born in 2004 and has been undergoing steady work and maintenance since. In the '90s, HTML discussion centered around topics like font coloration, or tables, or buttons, or something more esoteric. Today, a new HTML version means deep-down support for the modern web, namely web apps and video.

John Herrman - Read the rest on Gizmodo

There are two main arguments to this. The first is the emergence of HTML 5. HTML 5 finally allows video and audio playback without any plugins, and canvas - a tag which allows for complex drawing, embedding fonts, etc. etc. Things Flash has been able to do for years, has a huge head start on, and does really well. Flash has supplied us with everything from video streaming to blackjack, and even website design as a whole, and yet HTML 5 is supposed to just oust the holder of the crown and sceptre when it's finalized? I don't think so. The problem nobody seems to get is that Internet Explorer still has a majority market share, by a lot depending on who you ask - and Microsoft will likely NEVER support standards because it directly counters their business model. Aside from that, and the fact that every browser that will support HTML 5(ie: everyone else), will implement it differently from each other, with different aesthetics, features, code, BUGS, etc. But even more crucial the HTML 5 spec itself is not even complete yet. It's not even finished, and it's unfinished in a deadlock between the web giants who not only can't decide or agree on which video and audio formats are the best performance wise, but also who owns the rights to implement those formats in their browser and who'll have to pay massive royalties should the true patent holders (still somewhat unknown for sure) decide to cash in. No one wants to properly look this up for a variety of reasons and so HTML 5 - supposed to bring the web together and herald a new dawn of the internet can only work if EVERYONE does in fact come together and implement it in exactly the same way; disregarding that ubiquitous HTML 5 means EVERYONE loses something, some everything.

The other main argument is the Apple iPad - just announced. Which like the iPhone doesn't support Flash. Apple uses the old "Flash is too resource intensive" argument to convince you that limiting you from the full web is a good thing. This simply isn't true. It's false. Both iPhone 3Gs and iPad could happily run the current version of Flash or Adobe AIR just like your laptop/desktop. And it's also entirely up to the developer and how they program and how resource intensive they make their flash app/widget/game/etc. The only reason, listen up, the ONLY reason Apple does not support Flash, is because the Flash platform already powers so many games and useful tools and full blown applications on the internet it threatens Apple's very business model of the Itunes/App Store. Apple wants companies to develop all their apps again specifically for the iPlatform and invest in it. If you could make a Flash app that ran on the iPhone it would also run on Android and every other smart phone. But if you invest in the iPlatform your app will only run on the iPlatform. If Apple was a monopoly the FTC would be pushing them down for their anti-competitive vindictive behaviour.

Apple doesn't block Flash support in their mobile products because they want to push innovation in HTML 5. If HTML 5 was advanced enough, or popular enough to be worth creating the caliber of applications possible on Flash, Apple would immediately configure mobile Safari to block, impede, and hinder the advancement of standards just like Microsoft with IE. In a heart beat. Apple promotes HTML 5 because they know it'll be years before it's anywhere close to where Flash is today, if ever. In fact Apple is one of the "powers that be" preventing the HTML 5 spec from being finalized in the codec wars. Apple wants you locked into their platform. Apple doesn't care about advancing the web, or a better user experience, they care about the big media companies bringing their content online through Apple's platform. Apple wants the iPad to replace your tv, radio, and other media consumption devices. They do not care about the open web.

Adobe on the other hand continues to open up the Flash platform and benefits from creating a ubiquitous platform across desktop and mobile. There are fully open source versions of their Streaming and Application servers, and free and open source ways to develop for their platform. Anyone can build a Flash application, for the browser, desktop, Windows, Mac, Linux, Safari, Internet Explorer, Chrome, Firefox, Opera, etc. etc. Build one application and deploy everywhere using an incredibly powerful, scalable, and mature toolset. Apple on the other hand - should you decide to invest in it, puts you in a position where you may or may not after months of development time and costs even get your application onto a device, regardless you'll have payed Apple to be a developer and to submit it in the first place or even get access to their development tools, and should you get through the random and gauntlet of barriers they can still remove your software from their platform and devices at a moments whim. They can and do literally remove your application from people's phones after being downloaded and used without warning to backup the data put into or created by your app. Anytime for any reason. AND if you're lucky enough to get your application through all these extra months of hurdles and costs and lost revenue you're only gaining access to one small subset of mobile devices.

It is absolutely ridiculous to think the HTML 5 is going anywhere anytime soon, let alone even coming close to eclipsing Flash in any way. Not from Apple, they don't want anything to compete with their platform for getting applications on their devices - Flash or otherwise(HTML, Java, Silverlight), and not from anywhere else because it's just not mature, complete, or will over the next 12-24 months be implemented uniformly or consistently across browsers or operating systems. Even in the event that somehow all these competitors come together to reduce their own profit margins and upset shareholders in the name of benefiting the user and happy popcorn rainbows, it will still only have the capabilities of Flash 8-ish. By then Flash Player 11 will be out and all the best web apps will have an Adobe AIR application front end and you'll use an Adobe AIR application to browse through a market place of Adobe AIR apps. Yes we're moving towards the cloud, and yes the cloud and desktop are becoming indistinguishable, but moving into the browser is only a temporary measure for some companies before they build a desktop front end for their service.

The iPad, iPhone, and iPod are toasters. Every person with an iMobile device also has a desktop or laptop for work and actually managing their digital life. Every single person I've seen raving for HTML 5 and the downfall of Flash depends heavily on Flash and its phenomenal capabilities. They're all idiots.

So in the Flex/AIR app I've got a URLRequest that's used to load a Sound object. Instead of specifying the index.php it had been accessing http://domain.com?var1=blah&var2=blah. Usually this will redirect to the index.php sending it the post variables and letting it do it's thing and fetch the mp3. It works on Adobe AIR for Mac, it works in a browser on Mac/Windows. But in a URLRequest from Windows it doesn't work, confirmed for XP and 7. It doesn't just redirect to the /index.php file and drop the POST/GET variables, it actually just doesn't redirect anywhere, and you get an IOError. You'd think the redirect would be handled entirely by the server and transparent to the client, but it appears that for whatever reason, Adobe AIR on Windows just returns an IO Error.

Either way it's easy to fix, you just have to specify the index file in your URLRequest like so: http://domain.com/index.php?var1=blah&var2=blah.

SecurityError: Error #2123: Security sandbox violation:

Adobe went through a number of phases making the rules for serving and checking Policy files stricter. There are different security sandboxes. If you publish your flex/flash application on domain.com, and the application attempts to load content from domain2.com, it will look for a Cross Domain Policy File at domain2.com/crossdomain.xml to get permission. It does this automatically, however you could specify the location of the Cross Domain Policy File in your flex application using the following method:

Security.loadPolicyFile("http://domain.com/remote_content/crossdomain.xml")

A Cross Domain Policy File only has authority to grant access to content below it in the folder hierarchy. So a policy file in /remote_content/ can't grant access to content in the root folder, and in addition a Policy File at the domain root can override any other policy file. It has maximal authority. Subdomains are considered separate domains - which as a side note most search engines see subdomains that way too.

Now that's Cross Domain Policy Files, In general Adobe Air applications operate in one of the local system sandboxes and has thus have access to content on any domain. This post is about Socket Policy Files. When you access regular web content you're generally connecting to your server on port 80 and being served content by Apache or whatever web server you happen to be running. When you do this you're using http protocols under the hood and never have to deal directly with that crazy stuff. If you want to make a raw socket connection to your server you will need to serve up a Socket Policy File on a specific port.

First I just want to stress the difference between a Cross Domain Policy File and a Socket Policy File. For some reason my dyslexia and the ton of misleading, vague, and now out of date and incorrect information I kept thinking they were the same thing. Second there is no way as far as I'm aware to serve a Socket Policy File with Apache.

The default port for flex/flash to search for a socket policy file on port 843. There are several places on the web that talk about being able to connect to higher port numbers without a Socket Policy File, well that doesn't seem to be the case anymore. Just assume that any raw socket connection from a flex/flash client requires a Socket Policy File.

You can serve the Socket Policy File from the port you're connecting to, but this is tricky considering the manner in which Flex/Flash goes about loading the Socket Policy File and rewriting the service to serve this up, especially if you're using server software built by someone else, means it's just better to keep the Socket Policy File Server as a separate always running entity on the system.

Now in the simplest implementations you need a process either written in python, perl, c++, php cli, or whatever. It needs to be listening on port 843. It has to wait for - very specifically - the following string<policy-file-request/> followed by a NULL byte. Upon receiving that it needs to serve up the policy file which needs to at least have allow-access-from domain set to *, and to-ports set to *. You should use the links at the end of this post to familiarize yourself with the differences between and all options you can specify in Policy Files. It's easiest to keep the Policy File as an actual file, instead of adding the text of the file to your custom server code. And that's it!, now you can go on with a better idea of what information out there is out of date or not.

Here are some important links to help you on your journey:

Adobe on setting up a Socket Policy File Server

Adobe on Policy File changes for flash 9 and 10

Adobe on the structure of Policy Files

An intro to Sockets

Working PHP Cli Socket Policy File Server