Beer and Flash.
Now, i plead guilty to introducing the two from time to time ... and sometimes more of one than the other. : )
... and here comes an opportunity to mingle micro-brew tasting with some of the most intelligent minds in the business... and in Boston no less!
Flash on Tap is in Boston from October 7th until the 9th. Get you tickets while the super early and early bird special last!
Josh Noble - the main man behind the Flex 3 Cookbook of which i had the esteem pleasure of being part of (thanks again, j-man) - has recently blogged about some more information involving the files for download and the intention of the book.
Wanted to blog about it as well, as i feel there is some great information from his post about the decision for cutting chapters and where to download code and the best way to submit errata. He also mentions the heartbreaking decision to cut chapters and recipes from the book to preserve page count... but don't put the book back on the shelf, they are available to download!
We hope people are enjoying the book at what any level developer you are. Cheers to Josh and happy coding!
If you read MXNA, you probably have stopped checking quite some time ago because every post is about Astro...
but if you are interested in another way to set up your projects in FlexBuilder to target FP10 without having to muck about with files in the frameworks folder of your original Flex3 SDK installation this post may shed some light.
I am a workspace fanatic when it comes to development. I like things tidy, and when i start a new client project or go into some new exploration that involves multiple projects, i create a new workspace. The great thing about workspaces for me, aside from keeping things neat in my head, is that each new project you create in that workspace inherits from any default settings. So when the big news hit and i wanted to check out the latest SDK, i created a new workspace and followed most of the excellent directions already available on the adobe open source site. I only strayed a little in how i went about setting my workspace up so that every new project i created in it was *almost* set for development targeted at FP10 without having to run through the process each time.
The following is the process i took to only mess with the files from the nightly build and set defaults for a single workspace in order to play around with the current features available in Astro:
1. Download Flash Player 10 codenamed Astro.
2. Download the nightly build and unzip to some directory. (for me that is /Applications/flex_sdk_3.0.1.1728
3. Open FlexBuilder or Eclipse (if you have the plugin) and create a new workspace. (ie. ~/Documents/workspace/astro).
4. Create a new project.
5. Navigate to Project>Properties
6. Select the Flex Compiler option
7. Under Flex SDK version, click Configure Flex SDKs...
8. In the Preferences (Filtered) window, select Add
9. Navigate to the installation of your nightly build. (ie. /Applications/flex_sdk_3.0.1.1728)
10. Add a new name for the SDK... you should see something like so:
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
11. Click OK, Then tick the checkbox next to the newly added sdk in the Installed Flex SDKs window.
12. Click Apply, then OK.
13. Then back in the Project Properties folder, under Use a specific SDK, if the newly added SDK isn't selected, select it.
14. Under the Required Flash Player Version, change the value to 10.0.0
15. In the Project Properties window on the left side, select Flex Build Path> Library Path.
16. Expand the SDK you just set as default, and select the playerglobal.swc and Remove it.
17. Click Add SWC, and navigate to the player 10 swc from your nightly build SDK installation (ie. /Applications/flex_sdk_3.0.1.1728/frameworks/libs/player/10/playerglobal.swc)
18. Click Apply, then OK.
19. Open up the flex-config.xml file from the Astro SDK installation and update the settings as described in the first part of the Command-line Compiler instructions from here.
Thats it! Only 19 steps... that seems like a lot. In any case, in ensures that any project you now build under that workspace will default to using the targeted SDK. You will still have to manually change the Required Flash Version (from step 14) before you compile a new project, but other than that when you want to tinker with the nightly build - and not mess with your stable Flex 3 SDK release that other projects in other workspaces are targeting - just hop over to that workspace.
Good reading:
Ryan Stewart - Flash Player 10 codename "Astro" goes beta
Tinic Uro - Adobe Is Making Noise series
Keith Peters - Astro Dynamic Sound!
Josh Tynjala - Gratuitous Text Effects
I have recently gotten into incorporating Prana - the Inversion of Control framework of AS3 created by Christophe Herreman- into my projects. I gotta say, it's beautiful piece of work and makes me rethink my approach to the architecture of applications again.
I don't want to go into IoC and dependency injection and how your applications can truly benefit by using the Prana framework, as this post may get pretty long and these references are much better reading than my rambling:
Christophe's blog: http://www.herrodius.com/blog/
Martin Fowler's Inversion of Control Containers and the Dependency injection pattern
the hollywood principle
What i did want to bring up is that i had a small problem with the workflow and how i develop. Which is my problem, of course
but nonetheless...
One important thing to remember is that the context file is an external file that is loaded by the application at runtime. This means you will need to have all the possible classes your application may use already compiled into the SWF in order for the objects to be instantiated and your application to work. If you are typing to interfaces, this could prove to be a bit of a problem. You could create a reference for each class that may be needed in another class that is known to be compiled into the SWF - as Christophe explains in this post - but that always seemed dirty to me.
As is mentioned in the comments to that post, you can also go about adding each class using the -includes compiler option. Adding all possible classes using the -includes option makes for an excellent case on when to use additional compiler configurations, and presents the option to really just change the application context file and the additional configuration file as the project sees fit, without having to open up the source and tack on or remove dummy references to classes.
As an example, take for instance this application context file:
.. for each possible implementation of ConnectionDelegate and CallbackResponder that i may decide to swap in and out as the project seems fit, i would either need to hold a reference to each implementation in some class sure or be compiled into the SWF, or i could store them in an additional config file that can be added using the -load-config option with an additional value:
The prana.config file:
... drop that in my source folder and add the compiler option:
From there, i could change the context as i see fit, update the prana.config file to reflect my preferences and just recompile the application without having to go into the source and muck about. It's a little more clean for me and allows me to happily go about using the Prana framework.
The best part is that Prana is truthfully AS3 compliant! Meaning you can use it in your Flex AND AS3 projects, which cannot be said for some frameworks that claim to be AS3 and actually use class from the mx package... (looking at you as3lib). A huge pet-peeve of mine.
*Last i checked, the source under version control doesn't seem to reflect the current changes Christophe has made, but they are included in the downloads.
You can't... That is to say, there is no style property to change the color of that little white box that appears in the lower right of a Container component when the vertical and horizontal scrollbars are present.
Today, i added a Canvas that had fixed dimensions to the displaylist of a Flex application. Because the content within the Canvas instance would vary in size, vertical and horizontal scrollbars are needed for content that is larger than the width and height of the fixed dimensions of its parent container. When both scrollbars are present on the display, they meet in the lower right and create an empty space. That empty space is actually a FlexShape in the Container class called whiteBox. The whiteBox shape is protected, but is added and removed programmatically within private methods based on the presence of both directional scrollbars.
Fine by me... the problem i have is that the color of whiteBox is hard-coded ( to #FFFFFF ). Super! I guess if you name something with a prefix that is a color, you have to hard-code the actual color it will be using to draw...
There is an easy work-around by just creating a subclass of Canvas and overriding the updateDisplayList() method to remove whiteBox, but it seems kind of hackish, especially if it is going to be added each time the vert and horiz scrollbars are added to the display and then i have to remove it again.
Here's an example of how i resolved my issue:
Nothing extremely complicated, but it would have been nice to just set a style property or for the fill color to inherit from the backgroundColor property. ah well... Hopefully someone may find this post if they are wondering what to do with that white box.
For those of you that still follow this blog, you may have noticed that i have not been too knee-deep in blogging. A measly 5 posts ago, i rambled on about what 2007 might bring. Needless to say it had kept me pretty busy - and for all good reason. I have had the opportunity to work alongside some unbelievably talented people and be a part of two amazing books focused on Adobe AIR and Flex 3 that will be hitting shelves soon. I also accepted a position at Infrared5 and am looking forward to working with some of the most insane and brilliant minds in the industry.

Marc Leuchner and Matt Wright (of NoBien fame) and I have been burning the midnight oil to deliver an exciting book on Adobe AIR - AIR Create-Reuse-Modify from Wiley Wrox press. Each chapter walks through building applications as you learn about the AIR API. We had a lot of fun architecting and writing about each application that highlights specific facets of the platform and hope it is as much fun to read. Adobe AIR and the API is part of the Flex 3 SDK, which might be coming out soon...

Well, i didn't stop at discussing one part of the Flex 3 SDK and also was asked by Josh Noble to be a co-author for the Flex 3 Cookbook from the O'Reilly press. We've gathered the submissions from the Adobe online cookbook and Josh has been steering the cookbook ship to greatness. If you are unfamiliar with the O'Reilly cookbook format, the book is designed to present hundreds of 'recipes' aimed at solving programming problems. I have had the extreme pleasure to write about parts of the Flex API that i love and believe to be essential to RIAs developed using the Flash Platform.
If writing didn't keep me busy enough, I worked with some amazing people while building applications that stretched the possibilities of what online and desktop applications built in Flex can do. Along the way i learned more about the business, some agile practices (which i hope to write about some) and how to have fun and love what i do. It is an amazing thing.

I also have had the opportunity to join the Infrared5 team and could not be happier. Infrared5 is a consulting company started by Chris Allen, Rebecca Allen and Dominick Accattato focused on architecting applications using the Flash Platform and Red5 Server technologies. Keith summed it up pretty well in this post. I am honored to be in company with some of the brightest minds in the field that keep me laughing throughout the day. Once I stop breaking things around the office, i can settle in and learn something
All in all, 2007 was a great year and i am making out 2008 to be even better. Here's to posting more!
To start off, recently i have been working remotely for my job... whole 'nother discussion... and what was once the 'office' (read: extra room where we didn't know where to put stuff and has my computers) i retired to during the nights and weekends has become my proper 'office' (read: i am in here all the time now). Essentially what this has boiled down to is having no boundaries of what music i can put on at any time - aside from the albums i had to leave behind at the store until i get another check and can free them.
This also has lead to me digging around and discovering some old gems that i just never bothered to bring to work or put on the iPod. And i started to notice with the CDs that some of them would end. I'm enjoying my coffee. Hmm. It's nice outside. Should i ta... 'BA-DIT-IT-Y DUM WHIRRRRrrr'. What the hell is that!?! Oh... yeah... extra track stuck on the end of the cd... you can get out from under the desk now.
Does that happen any more? I haven't bought a CD in a long time that has that 4+ minute dead space at what should be the end of the CD that then drops that hidden song on.
Todd at 14: 'It's not even freaking labeled on the jacket!?! What's the name of this song? It's awesome. Did Tim know that was there? Oh, man. That's going onto the next mix tape.'
Todd just may have dated himself...
Anyway, I got to thinking... a) what happened to that suprise? is it that they still make 'material' CDs only for poor schmos like me who like to hold something and that the production is no longer based on someone buying more than one song? b) i wonder what the equivalant in the internet world this 'extra track' phenomenon is?
The answer to a) is probably yes and the fact that it was a fad. There was a time i couldn't buy a CD without expecting an extra track hidden at the end, and i would spend my time hitting the seek button until i heard something. Was i disappointed if their was no extra track? Only if the rest of the album sucked and i felt i was suckered in by one song to buy it - looking at you Live. (remember this was a time before you could preview anything on the internet and it was a godsend if a record store had opened CDs you could pre-listen to...)
The answer to b)... hmm. Don't know. I am always tempted to say 'skip intro'. But i don't know... that wasn't really a treat most times ![]()
And, aside from obvious design and nomenclature, i am wondering if there was something that was prevalent on applications or websites that you couldn't get away from whether you were interested or not... kind of like how you can't buy a decent glam album nowadays without it being remastered with more extra tracks than the original album had. Good and bad and leaves you wondering how long it will last and if you really care if it's gone... but you'll write a blog about it 10+ years fter the fact.
I don't know where i am going with this. Just rambling and looking at the crates of LP's and stacks of CDs for something new to listen to...
As some of you may know, Matt Wright and Marc Leuchner (of nobien fame) and I are authoring an Adobe AIR book to be published by Wiley. We've been breaking fingernails typing away to deliver a jam-packed by-examples book in which you'll build real world applications while learning about the AIR API. As we're writing, we run across some amazing features in AIR and yammer amongst ourselves - or to anyone who listens - but rarely blog about our excitement and findings.
That said, there is a coupling of features of AIR while leveraging the Flex Framework that i cannot hold inside and think is worth mentioning: Associated filetypes, the invoke event, and BindingUtils.
To view and download the full code, click here.
File Types
First off, you can associate filetypes to your AIR app in the application descriptor file within the fileTypes node:
Once the AIR app is installed on your machine, a file with the extension set as the value of the extension node will be associated with your app. Meaning, it will show up first in the list when you choose 'open with' and even invoke the app if you double-click on the file - that is if the extension is not associated with another program on your machine (ie. doc) in which case you will have to set your app to always open associated as default to your app.
InvokeEvent
The invoke event of a WindowedApplication will be triggered upon initial instantiation - without having the application previously running - and any subsequent 'open with file' calls. The arguments property of the InvokeEvent is an array of arguments passed through invocation of the app. This not only allows command line junkies to open an application with a file like so:
On Mac:
>open MyAirApp.app MyDocuments.ftf
On Windows:
>MyAirApp MyDocument.ftf
.. but as well as double-clicking or choosing 'open with' on a file (as describe above). Probably you wouldn't have any documents lying around in your applications directory - but you get the picture. To handle those arguments your app would look something like as follows:
Note:
AARG... i can't find a decent mxml plugin for Wordpress. There is an errant closing mx tag before the script and the closing tag at the end should read /mx:WindowedApplication . If anyone has any tips on a good plugin, please leave a comment!
This assigns the onAppInvoke() method as the handler to the 'invoke' event dispatched from WindowedApplication upon instantiation AND any subsequent invocation calls. The arguments attribute of the InvokeEvent is a list of strings - deliminated by space if you on the command line. From here, just handle them as you want to. In following with this example we are going to handle paths to simple text files.
BindingUtils
All this filetypes and invoke events craziness is enough to warrent me to stop writing... but i got to thinking (always bad news)... what if i've got an 'invoke' event that may trigger prior to the creation of a client that needs to know about an opened file, or more so, the app needs to switch focus to a client that has yet to be instantiated that knows how to handle that file? This is where BindingUtils and ChangeWatcher come into play and really show off the power of the Flex Framework.
Note:
Again i apologize for the terrible representation of mxml code. To view the full code, click here
On dispatch of 'applicationComplete', a ChangeWatcher instance is created to bind any changes to the invokeFile attribute to the invalidateFiles() method. The invalidateFiles() method will be called upon a change to the invokedFile which is of type File from the AIR API. The client that handles any invoked files in this case is another addition to the AIR API - Window. I threw it in there because i can't stop wanting to use it
The invalidateFiles() has checks to see if the file is valid as well as to make sure the Window is open and ready to receive data. Basically, with binding a change to the invokedFile attribute to the invalidateFiles() handler, we can be sure that when a file is requested to be open - either through invocation from the command, double-click, or 'open with' - the Window client that knows how to handle that file data will be presented.
This just scratches the surface. There are icons you can associate with file types, there's drag and drop capabilities that can update the invoked file if wanted... i just have to stop typing at some point!
View the full source code here. I didn't offer up the air app to download because it's a rather boring app, but it is included in the source if you want to install it and test out the invocation.
If you made it this far and haven't checked out AIR, go download the bits. And maybe consider buying a book or two...
The cat's outta the bag... and threw up on the middle of the cover. If for some insane reason you have been wondering about the lack of posts, i have been saving my mastery of the english language to co-author a book on AIR.
I've been fortunate enough to work alongside Marc and Matt to produce a 'by example' book on AIR that we hope people will enjoy reading as much as we have writing it. Matt took the words out of my mouth, but with any new technology there is always the jazz of it's potential and then the questioning of its practicality. I can say for certain, after having worked with it for the past several months, that AIR is the next generation in desktop software development.
The Wrox Instant Results series walks you through building applications while learning the platform API, and this is no different. We have assembled a dozen examples that you can walk away from and use as well as expand upon. As the book progesses, you build on your knowledge from previous chapters and learn new aspects of the API. With a general knowledge of Flex and basic understanding of OOP, anyone can jump into this book and take off running with their own ideas.
Also available from Wiley Wrox is Professional AIR by the esteemed Chuck Freedman, mister Keith Peters, Clint Modien, Ben Lucyk, and Ryan Manning.
Wrox AIR Instant Results
Daniel Dura wrote up a great post on adding Flex components to NativeWindows. If you are looking to add Flex components to your NativeWindow instance, you will need to follow what Daniel described. As Daniel has mentioned, this is an issue concerning the alpha version of Apollo and may be cleared up in the next release, but if you can't wait and are looking to add custom ActionScript components that extend Flex components, there is another option.
I don't pretend to know enough about the architecture (so someone speak up if i am off track), but adding components to NativeWindows - without Daniel's or the proceeding example- fails due to the reference to your main ApolloApplication's stage when displaying components within the Flex framework. You can add all the displays existent in the AS3 library (Sprite, TextField, etc.) to the stage of your NativeWindow instance, but any in the Flex framework need a little push. Adding MXML components to your NativeWindows will still have to follow the formula Daniel laid out using the addChild/removeChild methods, yet there is a workaround to this for ActionScript components by adding an ADDED_TO_STAGE event listener within its constructor.
I have a tendency to try and word things right and it comes out all mush, so i'll just show some code. You can alternatively look at source view.
The CustomLabel (CustomLabel.as) component that will be added to our NativeWindow:
... And the main mxml (NativeWindowExample.mxml):
NOTE: the preceding code has some major problems due to mx tags in wordpress, so disregard all affending close tags
-- As well, you could extend NativeWindow and add the AS components to its stage to bypass adding them in the main app. --
In the main app file we are just creating a new NativeWindow instance and adding the custom AS component, CustomLabel, to it's display.