It took me a while to figure things out entirely but in the end I'm happy to have learned how to use flash.desktop.NativeProcess. Unfortunately, in order to realize my idea faster, I ignored the fact that the application would really depend on a user's system. For instance, I have Ant installed in such a way that its available as a system command so I can run it from the command line like any old DOS command. I know not everyone is setup like this andwould require knowing where Ant is installed on a user's system. Additionally, Ant doesn't come with a good old fashioned .exe file for Windows so I invoked Ant via C:\windows\system32\cmd.exe. Here's some pseudo code that comes straight from my application...

Another (little) thing was that Adobe isn't very clear about the fact that you need to package your application in a native installer in order to use the 'extendedDesktop' profile.  Took me a while to figure it out, but the good news its pretty darn easy to package a native installer from a .air file.

At any rate, its by no means ready for the public, but I wanted to share my work thus far to see if anyone else would be interested in an application such as this. So here's how it looks and works so far:

When you start the application you're presented with a screen that allows you to load a build file...

Once the file is loaded it displays information about the build file and a list of its available targets...

You can then select a task and run it. Here you can see the output in the TextArea component from when I ran the compile-docs target...

Some of my targets require arguments to be passed in for them to work. For instance, my compile-and-debug target requires a debugLevels parameter that specifies the various debug levels (info, status, etc.) to output to the debugging console (which happens to be de MonsterDebugger). So I created a little panel that lets me specify parameters for the target...

Lastly, here you can see the output from the compile-and-debug target after running it with the passed in parameters...

So thats it! And if anyone thinks this would be useful to them leave some comments and/or ideas.

P.S. I built it with robotlegs

1. Its in F*ckin' New York City!
I know NYC isn't for everyone but there's everything you could imagine here. On top of learning and getting inspired about Flash you'll have everything NYC has to offer at your finger tips. The organizers of the conference know this and have created what they call the "City Track". They've organized a few "field trips" throughout the city that you can tag along with. Just think of all the cool stuff you'll be able to check out, eat, and do while you're here!

2. Its at the 3-Legged Dog Art & Technology Center
This place is just plain cool. Its entirely artist-run and have been supporting the arts in NYC since the center was built in 2006 just three blocks south of the WTC site. Personally, it feels good to be supporting such an organization.

3. The ridiculously good list of attending speakers
ZOMG! Srsly u guys! There hasn't been a large Flash conference in NYC...since...I don't know...2004? And that one pretty much sucked. But just look at the list of speakers! If you don't recognize the names, just trust me on this. They're are some really sharp people speaking about some great developments in the industry.

4. The Price is Right
Tickets right now are $299 (but lets just be real and say $300). In comparison to other conferences, this is CHEAP, especially for NYC standards.  And if you keep your ear in the community (Twitter, blogs, etc), you might even be able to find a coupon code!

I'd say these are my main reasons for anyone to attend the conference right now. I'm sure I'll come up with more and if I do, I'll update this post. Naturally, I plan on attending seeing as I live here and I hope to see you along with my other friends and colleagues here as well! It's gonna be a blast.

Upon downloading Sprint 8 I was immediately happy with the renaming of the framework event classes. They make much more sense now. Seeking progressive videos seemed to have improved as well, but I was still experiencing some buggy behavior when continuously scrubbing a progressive video.

My conclusion is that there is a bug in the NetStreamPlayTrait class and NetStreamTimeTrait classes. Basically, the NetStream.Play.Stop status code is sometimes dispatched when it shouldn't be. For instance, when I continuously scrub a video using the seek() method, there are times at which the aforementioned status code is dispatched when the playhead isn't at the very end of the video. More specifically, when I scrub to the end of the video for the first time the status code is dispatched and caught by the mentioned framework classes. Thus, this causes two things to happen.

First, the NetStreamTimeTrait class dispatches a TimeEvent.DURATION_REACHED event whenever this status code is received. Thus, the MediaPlayer redispatches this event at times when the playhead is not at the end, causing registered listeners to think the playback has completed when it hasn't. This was very strange, so I put some trace statements in the onNetStatus event handler of this class to check the currentTime and duration properties. When this event was dispatched during continuous scrubbing these values were never the same and often not close to being equal at all. Even when the video reached the duration during playback, these values weren't always equal. In one case the currentTime property was larger than the duration by one decimal place. I'm guessing this is a discrepancy between the NetStream.time property and the value of the duration provided by the meta data. At any rate, I thought it might be good to add a condition into the status handler to check if the currentTime was equal to the duration, thus verifying the playhead has in fact truly reached the end of the video. First, I edited the currentTime setter to look like this:

override public function get currentTime():Number
{
    return Math.min( duration, netStream.time );
}

This ensures that the currentTime is never larger than the duration and avoids the bug I described earlier. Next I added a condition into the onNetStatus handler of the NetStream.Play.Stop code. It now looks like this:

private function onNetStatus(event:NetStatusEvent):void
{
    switch (event.info.code)
    {
        case NetStreamCodes.NETSTREAM_PLAY_STOP:
            // For progressive,	NetStream.Play.Stop means the duration
            // was reached.  But this isn't fired for streaming.
            if (NetStreamUtils.isRTMPResource(resource) == false &&
                currentTime == duration)
            {
                processDurationReached();
            }
            break;
    }
}

Notice the additional condition to check if the currentTime is equal to the duration. This ensures that the TimeEvent.DURATION_REACHED event isn't dispatched until the playhead time has reached the duration. These two fixes took care of the TimeEvent.DURATION_REACHED event from being dispatched when it shouldn't be, however I was still experiencing a problem when I tried to resume playback of the progressive video if I happened to scrub it to the end.

Just as in the NetStreamTimeTrait class, the NetStreamPlayTrait class handles the NetStream.Play.Stop status code. As mentioned, the status code tends to get dispatched when it shouldn't, especially when continuously scrubbing and you happen to scrub to the end of the video. So, in the NetStreamPlayTrait class is that when this status code is dispatched, the following code is executed:

case NetStreamCodes.NETSTREAM_PLAY_STOP:
    // Fired when streaming connections buffer, but also when
    // progressive connections finish.  In the latter case, we
    // halt playback.
    if (urlResource != null &&
        NetStreamUtils.isRTMPStream(urlResource.url) == false)
    {
        // Explicitly stop to prevent the stream from restarting on seek();
        streamStarted = false;
        stop();
    }
    break;

So for progressive videos, the streamStarted property is set to false and the video is stopped. Confused, I followed the stop method around and determined that is just pauses the NetStream object. Then I looked around for where the streamStarted property is used and found it being used within the processPlayStateChange() method. From what I can tell it's used to denote if stream/video data exists in the NetStream object. Why would this be set to false for a progressive video's NetStream.Play.Stop status? Is not the video data still in memory? So I commented out that line and the code now looks like this:

case NetStreamCodes.NETSTREAM_PLAY_STOP:
    // Fired when streaming connections buffer, but also when
    // progressive connections finish.  In the latter case, we
    // halt playback.
    if (urlResource != null &&
        NetStreamUtils.isRTMPStream(urlResource.url) == false)
    {
        // Explicitly stop to prevent the stream from restarting on seek();
        //streamStarted = false;
        stop();
    }
    break;

Upon testing my video player my continuous scrubbing seems to behave properly! Woohoo! Now let me just say that I have not tested this extensively and I know that OSMF is still in development. I could very well have created a new bug by doing this, but at least things are behaving the way I would assume they would now.

Having some experience with PureMVC and even having some pleasant success with it, I was quite intrigued by some claims that robotlegs is "PureMVC done right". Hmm...At any rate, I can't help but be intrigued by a claim such as this and I always enjoy looking reading about developers' often unwavering opinions about how an MVC pattern should be implemented. So after reading the docs, development forums and checking out the examples, I feel that robotlegs is a great concept and has fulfilled its development philosophy very well. It seems to me that its primary focus has been the use of dependency injection. This allows you to keep the layers of your application nicely decoupled. In my early research, I was a bit annoyed by the fact that the injection module, SwiftSuspenders, was only compatible with the mxmlc compiler. However, the latest version includes the ability to use XML to configure the injection points so I can now use it with the Flash IDE. Yes, I, and a lot of other people, still use the Flash IDE to compile applications.

My only complaint about Robotlegs is very subjective. And let me preface this with the fact that I'm not a classically trained developer (I have a degree in design, not computer science). But Robotlegs was rather difficult to get my head partially wrapped around. More specifically, dependency injection was, and still is, rather difficult for me to understand. I understand the point of it, but how its implemented in Robotlegs still seems like magic to me. And because I don't understand the dependency injection all that well, its hard for me to feel really comfortable using the framework to develop anything. In comparison, what I really like about PureMVC was that it was pretty easy to learn and the core concepts are also easy to understand (at least to me). Regardless, this is not to say that Robotlegs is any better or worse than PureMVC.

Unlike my apprehensiveness for Robotlegs, I am really excited about Robert Penner's Signals project. I stumbled across this project while researching Robotlegs. I didn't quite understand it at first, but after checking out the source and giving a go I became instantly hooked on the idea and hope I can integrate it into my future projects. Basically what Penner has done is create an event/notification system that can pass around strongly typed objects to listeners instead of the native/traditional Event object. Signals are, to put it simply, an object that represents an event. Thus a signal object has its own API for registering and unregistering listeners. Signals also gives you the ability to define the types of signals an object should possess in your interfaces. This fulfills one of my biggest wishes for interfaces: a way to define the types of events an object should have to dispatch. As of now the project seems to still be in development with Penner experimenting how to make working with native events a bit easier. I highly recommend looking into his work, but don't expect much as he's apparently in Thailand until the beginning of January.

I'd like to donate them to a High School or College. Would anyone in academia like a Chinese or Spanish translated copy of our book? I'd prefer to hear from people who instruct New Media or IT courses, or is involved with a school's library.

I will only ship these to a school address. No home addresses. No student dorms and housing. Please email me at aircmr "@" nobien.net.

Well, at that time, MXNA was down, so only a few regular viewers saw it. So I figured I'd just throw it out there again that our book came out. It's a book featuring eleven applications that you can use "out of the box" and hopefully use to create your own rendition using Adobe Flex 3 and AIR. If you do create your own app based on ours, or found the book useful in guiding your own creation, we encourage you to tell us about it.

Also, you should pick up the Flex 3 Cookbook by friends Josh Noble and Toddly Anderson (again). Another book (that will be awesome) is Adobe AIR in Action and was written by my old co-workers Joey Lott, Katheryn Rotondo, Sam Ahn and Ash Atkins (also the tech-editor of our book).

So now that you're about $80 in the hole, I'll let you be.