Today's the day! The long-awaited release of Flash player for mobile devices has finally arrived.

For those of you with Android-based devices, once you've upgraded to FroYo (2.2) you'll be able to install the player. Looks like Adobe has also released it to the companies behind Blackberry, webOS and Windows Mobile phones as well. Those of us with Apple devices, well, we're going to just have to stare at that little blue brick until mommy and daddy stop fighting.

As for what makes this release special, consider that Adobe (and before that Macromedia) has been promising a viable Flash runtime for mobile for what feels like forever. 10.1 is the first full Flash runtime built from the ground up for mobile devices, taking into account their inherent limitations (processor power, screen size, battery life) and still providing what early reviews say is outstanding performance. Short version: you can now watch more videos, play more games and access more rich internet applications on your mobile devices than ever before.

There's a lot here for the developer community too. Until today we were stuck building web based applications (as it turns out, mobile devices aren't immune to browser implementation quirks either) or going fully native (thus incurring the cost of building new for every targeted platform). Now, we can build modern, web-friendly, high-performance applications that will run on a wide variety of devices from all but one of the top-tier mobile device manufacturers once and only once.

The mobile market is changing rapidly. HTML5 is years away from an official standard. Mobile browser-based applications will always have to work around implementation quirks, even if the feature set is striving towards parity with what Flash player has had for years. I'm excited to have the option of building an app once, having it available everywhere and knowing that it'll "just work."

While CS5 is going to be a fantastic release, one feature in one product of the suite was perceived as sufficiently threatening to actually get a reaction from Steve Jobs. So if one feature was that awesome, consider what else is going to be in that box on Monday! But I digress...

Adobe is doing what it does best: release tools that make designers and developers more productive. This has little to do with Flash and everything to do with unleashing the collective output of the web development community. Flash is merely an enabler for the most dynamic, engaging and portable web-connected software experiences we have. But Dreamweaver, ColdFusion Builder, Flash Builder and the upcoming Flash Catalyst are the tools that make it all possible. They're not sexy but it's what we get to look at all day long.

The ability to develop an app using a language and IDE you're comfortable with means that you, the developer, can focus more on the creative and innovative aspects of your product instead of getting tripped up on syntax or negotiating the quirks of a new platform. That's just good business sense and makes for a happy, productive development team. Apple doesn't see it that way and would prefer that we do it their way, using their tools or just stick to web development.

It's not about getting Flash on the iWhatever; it's about getting developers working on apps for the iWhatever using Adobe tools. Really. Apple has plenty of specious reasons for not allowing Flash on their mobile hardware and only one legitimite one. Adobe's not out to decimate ITMS or the App Store (even if that might be fun) - it's looking to increase the size of the Flash developer market and thus sell more tools (which also includes our server-side favorites like ColdFusion and Flash Media Server). Flash isn't perfect (and if you actually read posts from Adobe folks, they're not arrogant enough to assert otherwise) but it's really fantastic for what it did for rich media delivery and standardizing the delivery of application experiences in the browser, a task that the major browser vendors continue to struggle with. Performance will never be as good as native apps - so what? Adobe continues to throw resources at optimizing the player and now that they have (at least in this one area) help from Apple on hardware acceleration the OSX crowd should be somewhat placated.

The blowback from the developer community on the latest SDK changes is the sound of people ticked off that the iPhone/iPad will remain mostly inaccessible without learning Objective-C. Not everything we'd want to do is exposed through the browser. It's an inferior platform and forever relegated to second class citizen status on the device. Why do developers like Flash in a desktop/laptop/netbook browser? Because it gives back a lot of things that the browser takes away. These things Apple wishes to keep for itself and a small cabal of trusted (or at least solid revenue generating) developers. HTML5 does not restore them - that seems to have been conveniently forgotten - despite Steve's assertions that the browser is all we should be paying attention to.

This will still be a great week for Adobe. It's also a great week for the web development community. One sentence in one document tells us where to shift our attention - away from Cupertino and towards a more open future.

Fine. I didn't want to pay your rent anyway, Steve.

Adobe wins, with or without you.

Adobe is open-sourcing an implementation of FlexLiveCycle Data Services for remoting and messaging applications. This is a big deal!

Damon Cooper has a great blog post on the subject outlining what BlazeDS is all about. what limitations exist and the open sourcing of AMF too.

The more data we're shoving around. the more it makes sense to economize wherever possible. With Flex as our client platform. AMF is certainly the preferred method ~ BlazeDS just drastically reduced the cost of doing better. faster and more interactive publish/subscribe application development. We use remote objects almost exclusively in our Flex apps. but the way we're using them is entirely on request from client to server. BlazeDS will allow us to push data from server to client. which depending on the application could be a great asset. Think of any type of collaborative application - being able to see what other folks are up to in real time could be quite an asset.

We've already downloaded the beta from Labs to start playing as soon as we get time.

Wait long enough and *someone* will undoubtedly figure it out. The wisdom of crowds prevails again!

Chad Udell figured it out. mostly due to this post that g.skinner left on his blog.

Now to give it a try in our app to see what happens...

So it's not just me.

Our Flash/Flex embedded font offset issue is likely also being caused by the same problem Chad Udell is having. I'll be watching this post to see what he figures out...

That calendar I used in my last example works great on Windows. On Mac (PPC). however. the event title isn't wrapping properly. It's just text in an mx:Text block.

This was tested in Safari and Firefox. latest FP installed. Is this a bug in Flash Player or something I screwed up?

I've stripped the code down significantly...maybe there's a clue here I missed.

Thoughts?

Now that we're kicking out Flex apps left and right. we have to deal with Flash Player version detection. Thankfully. Flex Builder generates all that code for us - what a relief!

I thought I'd document what the user experience is for different states of flash player detection just for kicks. It's likely that most people haven't seen these differing experiences because. as web developers. we tend to keep up to date with plugins. My father. on the other hand. does not!

First up. the user experience if you have Flash Player 9 installed:

Next up: Flash Player 6.0.79 - the latest version of Flash Player that supports the "upgrade in place" feature. 6.0.65 is the minimum version to do this. I bet this is what most people will see for a little while...

And finally. the experience of people who don't have Flash installed OR have disabled JavaScript.

It's important to note that you can control the text message that's displayed when this happens just by tweaking the Javascript a little bit.

Overall. the script works flawlessly and handles that whole Active Content issue with IE without a hitch. Thank you. Adobe. for abstracting me out of the equation of player detection! Just one gotcha that bit me: don't forget to upload the "playerProductInstall.swf" file to the server or the upgrade-in-place feature will not work at all!

Flex/Flash question for today!

We want to load an image in to our Flex app. That's simple if the images are in a web-accessible directory. We don't want to do that for "security" reasons.

So we thought we'd just do a little CFFILE manipulation on the server side and return the contents of the image file over the wire in a remoteObject call.

Flash has a bytestream class that we can clearly dump the file contents into...but where we're stuck is getting the data out of the bytestream and into a rendered image in Flash.

Can anyone help?

Lots more hand-wringing on the blogs today about an "alleged" combination of Acrobat and Flash PLayer. eeks...but then. i've also learned how to disable a crapload of the acrobat plugins. making it somewhat snappier to load.

Over on FlashAnt. one of the Adobe guys chimed in:

Hi.

The FAQ is poorly written and will be fixed.

We plan to keep the Flash Player small and focused.

We *also* plan on a new client code named Apollo that will work out of the browser and bring together the best of HTML. Flash. and PDF. Apollo will be very cool. (note: we learned a lot from the experience with Central.)

Regards. David Adobe (wow. odd to write that after 13.5 years at Macromedia).

So there you have it. Nothing to fear.