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.

Let me outline my situation hypothetically...

1. I have an Application class. This class is the document class of an FLA. The application has a navigation component in it. Each navigation button corresponds to a section. Hypothetically these sections are Home, Gallery and News.

2. I have 5 mediators. ApplicationMediator , NavMediator, HomeMediator, GalleryMediator, and NewsMediator. ApplicationMediator and NavMediator are registered in the shell during startup. Note, I'm using the Flash IDE so the Nav component is on the stage already and a child of Application.

3. NavMediator listens for clicks on the nav component and sends out a note to load a section. The ApplicationMediator hears this note and unloads the current section (if there is one) then loads the necessary section into a new Loader object. By default the home nav button is selected to load the home section when the app starts.

4. Once a section is loaded, lets assume its the Home section, the HomeMediator must be registered in the View. This is where I got stumped. Here are my two initial ways of register the mediator:

4.A. After loading is complete, the HomeMediator is registered in the view from ithin ApplicationMediator like so:

facade.regsiterMediator( new( HomeMediator( loader.content as Home ) );

The problem with this is that it requires HomeMediator be imported into ApplicationMediator (including the mediators for the other sections as well). Additionally, within HomeMediator (and other section nediators), I have a getter for the view component that looks like this:

public function get home():Home
{
   return viewComponent as Home;
}

This ends up compiling Home (the section's FLA document class) into the main application SWF in addition to HomeMediator. I certainly don't want this to happen. I want all the code for the home section to be contained within the home SWF.

4.B. Rather than register the mediator in the ApplicationMediator, I would register the HomeMediator in the constructor of the Home component similar to the way the Application starts up. Like so:

public function Home()
{
   ApplicationFacade.getInstance().registerMediator( new HomeMediator( this ) );
}

In some cases I would also manually send a notification to initialize the section so that it would run standalone. This method requires that I import ApplicationFacade into the Home component, thus compiling any classes that are imported into that class (commands, and the Application view component) into the Home SWF. I don't want this to happen either because I don't want to bloat each section with main application code.

So therein lies my dilemma. Each section is unloaded when a new section is requested to keep the memory usage of the site/app to a minimum because, in the real project, each section is rather large (some even use Papervision). I'm just totally stumped when to register the mediator for the loaded section without having unnecessary code compiled into the shell or the section.

Also, thanks to Simon for making me rewrite my situation a bit better. It was perhaps a bit confusing before.

I resorted to the PureMVC forums and was told that the Multicore version of PureMVC would solve my problems. I haven't had time to look into Multicore yet, but I was wondering if anyone out there has used the Multicore version on a, what might be, smiliar project (one that loads and unloads sections). Also note, that I'm not using Flex here, I'm using the Flash IDE (and FlashDevelop) to publish my content. So I'd love to hear the thoughts, experiences, etc from any one thats gone this route or has some sort of solution for using the non-multicore version of PureMVC. Thanks in advance.