nothing yet | jason madsen

Over the last few weeks (has it already been over a month?) the web world has been abuzz regarding technology mostly surrounding Adobe’s ill planned announcements surrounding Flash Player, HTML5, and Flex. What is best, what should be killed off? Why this technology is ‘better’ than that technology… We might as well work in some type of ministry as much as people get dogmatic about the technology choices they make. I recognize there are business decisions to be made. You need to be able to look your client in the eye and tell them that you are helping them make appropriate choices for their projects. You don’t however need to be blindingly loyal to any specific technology. They all have their strengths and weakness. Having said that, I have enjoyed my time working with Flex. It solves some interested challenges for web development. It also creates a few others.

Here are a few thoughts. First, if this snuck up on you then you have simply not been paying attention over the last few years. Once Jobs put out his “Thoughts on Flash” article, and Adobe fumbled their response, the writing has been on the wall for the Flash Player on mobile. The idea that somehow Apple would cave and someday support Flash Player on iOS has never seemed feasible to me.

It might be time for some of us to “double down” on reality. Flash Player isn’t inherently evil, Neither is JavaScript. Best practices for today’s JavaScript applications are not the same as it was 7 years ago when you last fought with it. To that end, ActionScript has grown up a lot since some of you stopped playing with it in ActionScript 1. Think you are too good, advanced, or “too OOP” for JavaScript? Please. If you are that great go help build the JavaScript community. Build frameworks and abstractions that make the language what you think it needs to be. There are plenty of smart people already doing that. Go join them.

There are plenty of Flash / Flex applications that could have been built with web standards technology. Are there pain points? For sure. Does Flex make it easier? Absolutely. The cold reality however is that you can’t count on Flash Player being available on mobile. Users are increasingly loading web content on mobile devices. Will you build your web application twice? Once with Flex for desktops, and again with web standards for mobile? I’m guessing not.

I have always loved the Flash / Flex community. There are some incredibly smart, talented developers in this community. I believe that Flex development will be around for a while to come. There are too many companies heavily invested in it to simply turn away. To that end, I am interested in what the community will do with the new (assuming it gets accepted) Apache Flex.

Do yourself a favor this upcoming year. Learn a new language. There are plenty of powerful languages to choose from. They all have merit. At the end of the day you will be a better programmer for having picked up something new. You can always go back to being religiously loyal to your language of choice after you have expanded your horizons. Who knows you may just find a new language to become dogmatic about.

The good folks behind the Swiz framework just dropped a nice little beta build of Swiz 2.0. The beta release introduces Aspect Oriented Programming (AOP) into Swiz. I’ve only put together an initial proof of concept application that tests the waters, but am real excited about the work they have done. If you haven’t done so already go check it out. Swiz is already a great framework, adding in AOP puts it over the top. Check out the intro to AOP article they have posted as well — Part 1, and Part 2.

On September 8th at 6:00pm I’ll be presenting on using Swiz for the Full Sail Flash Platform User Group (FSFPUG). If you are in Orlando, stop by (see group site for room details). If not be sure to check out the presentation online at: http://www.wddbs.com/go/fsfpug-connect

Lastly, I’ve begun work on a screen cast series that introduces and overviews the features of Swiz. I’ll post up information here when it’s ready… stay tuned.

I’m real geeked up to be heading to 360 | Flex DC this year. Should be a great time. Plenty of great speakers, building with the community etc… There are still ( at the time of this post ) early bird tickets. You know you’ll end up going. You might as well save a few bucks and get your tickets now.

UPDATE: Looks like the early bird tickets are now sold out, but for the money, it’s still the best Flex conference around. Go get your tickets!

Recently I had a chance to go back and sit in on some courses at a local university ( not the one I currently teach at ). In so doing I sat in on two semesters of Java. The courses were intended to teach both Java and object oriented programming. Before I go too far, let me say that I’m comfortable with Java, in fact I actually enjoy Java. Having said that, I will say that curriculum for beginning oop development should be, in my opinion, taught using ActionScript. I realize that ActionScript isn’t a perfect language. There are some things that need to be addressed (The lack of an Interface for the flash.display.DisplayObject for example). But taking it all in, the good and the bad, I think ActionScript is a really good language to learn with.

ActionScript has all the usual strengths for beginning developers: strongly typed, compiled, object oriented, a vibrant and helpful community. I feel that the biggest benefit for new developers is that most find it quite easy to create visual elements with ActionScript and Flash Player. As such I think students get the added benefit of seeing their objects in action. Having a relatively painless process that allows students to create visual objects helps students see the state of their objects. It is a great system. It’s the difference between calling a setter method and printing something to the console versus calling a setter and visually seeing your object update.

I have been teaching Object Oriented Programming using ActionScript for just over two years now. I can’t image having to do this in another language and getting students as far as I currently do. You can argue for and against ActionScript and the Flash Player all day. But it is a great language to cut your teeth on. Lately I find myself more and more happy to be a Flash / Flex / ActionScript developer.

I have been using Flex Builder ( and now Flash Builder ) as my ActionScript editor for a few years now. I have put together a nice little workflow for designing in the Flash IDE, while developing, managing, and compiling my projects in Flash Builder. When it came to working with AIR however there was a slight hiccup. In Flash Builder, ( or previous versions of Flex Builder ) there is no option for an ActionScript based (i.e. not Flex) AIR project.

I have seen a few workarounds, but none as simple as a tip I overheard on Twitter from Ted Patrick. So here it is, either read on, or watch a quick two minute screen-cast I put together.

1. Create a new Flex Project in Flash Builder.

2. In the New Flex Project Wizard, give your project a name

3. Choose Desktop (runs in Adobe AIR)

4. Select “Next >” in the wizard

5. Still in the Wizard click “Next >” again to bypass the Ouptut folder ( you can change it if you feel so inclined )

6. Still in the Wizard change the file extension of your Main application file from .mxml to .as

7. Select Finish

When you compile, and run the application in ADL, you won’t actually see the native window. Here is where the tip from Ted Patrick comes in. In your application-descriptor.xml file, change the visible tag to true. Compile and run. You should have a nice native window showing up. You can set the initial width, height, backgroundColor, and frameRate using the [SWF] annotation / meta-tag.

Optionally, if you would rather wait to have the native window be visible, you can do so using ActionScript by setting the visible property of the nativeWindow instance of the stage like so:

stage.nativeWindow.visible = true

So I had a bit of an annoying morning today. I went to update from AIR 1.5.2 to the latest release (1.5.3). The process didn’t go so smoothly. Long story short the updater would just hang up and sit there. I tried uninstalling 1.5.2 to get a fresh version of 1.5.3 rather than an update. No luck, the uninstaller wouldn’t work. I kept getting error messages about possibly not being an admin on my machine. Not true, I am the admin…. So what to do… Looking around the interwebz, it doesn’t seem like others are having the same trouble.

I checked permissions, restarted. Tried again, no luck. Tried again, and what? It tells me that I already have 1.5.3 installed. Huh? On which of the failed attempts did that happen? So I thought I would check the version number somehow. After a bit of googling. I found no easy way to verify the version number. You can do it programatically from within ActionScript. To do so you simply look at the following:

NativeApplication.nativeApplication.runtimeVersion

Looking at that property from within your IDE will tell you which version of the runtime you have in your installed SDK. To see which actual version of AIR is installed for AIR apps that you are running on the machine you need to execute the code within that environment.

So I built a quick little widget that displays the installed runtime version. Nothing too fancy here, just a utility. Feel free to install and use it via the badge installer below…

You can install the widget from the install badge above, or you can download the .air installer here

Over the last year or two I have seen several different methodologies on creating ActionScript documentation using ASDoc. Jesse Freeman shows a quick example of creating documentation using ANT tasks in his recent article 5 Tips for Documenting Code . ANT tasks are nice in that they can be transfered with the code base as it moves from developer to developer. When I need to quickly create ASDocs however, I typically use the External Tools dialogue directly in Flash Builder.

I thought I would document how to create a simple ASDoc configuration within Flash Builder’s External Tools dialogue.

External Tools

In Flash Builder, select Run –> External Tools –> External Tools Configurations

Create a new configuration by double clicking on the “Programs” button. Next, give the new configuration a name, I’ll choose something generic like “Generic ASDoc”.

Location

The External Tools Configurations window needs a bit of information. The first is “Location”. Select the “Browse File System” button and locate the the asdoc compiler.

On a Mac it is typically located at:

/Applications/Adobe Flash Builder Beta 2/sdks/4.0.0/bin/aasdoc

On windows (XP) I believe it is located at:

C:\Program Files\Adobe\Flex Builder 3\sdks\3.2.0\bin\asdoc.exe

I don’t have a PC to test this with currently, so if I am wrong, please feel free to correct me.

Working Directory

Next we need to add our “Working Directory”. You can think of this as your base directory, the directory from which any relative paths will be resolved. For this field I typically want it to be my “src” folder within the project I am working on. Eclipse has some interesting variables that can help here. You can see them by clicking the “Variables” button. I usually end up with my working directory set as “The currently selected project’s ‘src’ directory” like so:

${project_loc}/src

ASDoc Arguments

Lastly we need to add the necessary compiler arguments for ASDoc. I’ll document the basic arguments here, and then point you toward a more in depth resource created by Adobe that discusses all of the arguments.

-source-path
In this example I will set this to a period (.), meaning the same directory as the “Working Directory” from the previous step.

-doc-sources
Again here I will set this to a period (.), meaning document all of the classes found within the source path (which in this case is our ‘src’ folder)

-output
This is the directory in which ASDoc will build the documentation. If the directory doesn’t exist, ASDoc will create it for you. You could also use a relative path (relative from the Working Directory). I’m setting it to DOCS, meaning that it will create a directory named “DOCS” within the “src” directory.

Other compiler arguments you can use

For simple projects the previously named compiler arguments should get you started. There are several other arguments you may need. I’ll list a few of them here

-window-title
This argument takes a String, be sure to enclose your value within double quotes if it will contain spaces. The -window-title argument gets concatenated to the HTML title tag.

-main-title
This argument also takes a String (use double quotes for spaces). This argument value gets placed at the top of the documentation HTML

-library-path
A relative path to any SWC file dependancies. For example if you have a SWC file being used in the build path of your project found within the “libs” directory you would add “../libs” as the argument.

-exclude-classes
The fully qualified name of any class file that you do no wish to have included in the documentation

Running your configuration

When you have your configuration set up, select “Apply”, and then “Run”. You should see some feedback on the documentation process in Flash Builder’s console. From now on, you should see the name of the configuration when you select Run–>External Tools. Selecting the configuration will run it. You can also run the configuration from the toolbar icon as well.

More Info

For more information you should check out this document created by Adobe that discusses options for using ASDoc including both compiler arguments and options for commenting your code.

A couple of things fell together for me in the last few days, and I started thinking about attending Flash Camp Atlanta. I posted on twitter that I was trying to work things out to attend. Turns out an email from David Tucker was just the motivation I needed, and I am officially going. As part of that, I was asked to help out during the Introductory Session by giving a “Introduction To Flex” presentation. There are some great speakers lined up for this camp. You can see a listing of speakers and the schedule here.

I’m excited to be going to ATL. The last Adobe event I attended there was the “On Air Bus Tour” a few years back. My impression of the Flash / Flex community there has always been a good one, and based on some recent Twitter chatter it seems that there are over 200 tickets sold. Should be a great event. If you are in the area, or want to get away for a few days it looks like there are still tickets available.

See you there.

Jason

So there is an interesting widget that has been developed by Adobe ( I think the credit should go to Adobe Evangelist Serge Jespers, but I’m not sure if anyone else was involved). The widget displays facts from previous Adobe Max conferences and Testimonials from people. You can even record your own testimonial from within the widget. I thought I’d put the widget here on the site for people interested. Click the “?” button in the top right hand corner to see how to win a trip to Max. You can add the widget to your site or blog by clicking the “Get Widget” button in the bottom right.

Pretty cool widget. I’ve been following Serge on twitter, and know he’s put a lot of work into the project. The end result seems to have paid off.

Jason

We are about half way through Flash Camp Orlando. This mornings keynote was given by Greg Wilson who showcased the latest Flash Catalyst and Flash Builder builds. Pretty cool looking stuff. I am looking forward to getting into both of those apps.

I gave my presentation, “Making the jump to Flex”. I didn’t quite get a chance to show all of my examples, but as promised, here are my slides in .pdf form and Flex Builder project archives. The flex examples are pretty basic, but if you are just getting started with Flex, maybe you will find them helpful. I’m also posting the actual keynote slides ( as in .key, not .pdf ) the keynote is a bit large (17MB).

David Tucker’s presentation on AIR data persistence was great. We’re just now getting started with Carl Smith covering user experience.

So far so good. I’m digging the Flash Camp Orlando.

Jason