Is it crazy to think that I could have a multiple views registered with the same Mediator? For example if I have 10 view classes that are reporting their loading and progress to a progress bar, I'd think that they should be registered with the same Mediator, for example ViewProgressMediator. Also, I keep getting into situations where I wish all classes that subclass a certain class, let's say they subclass LoaderSprite, would it be possible to register all classes that subclass LoaderSprite with a Mediator ViewProgressMediator? These are sort of one in the same question. Right now, the only other alternative I can think of is to create separate Mediators for each View.

Any thoughts?

Good to know, thanks Cliff. I decided to yank out a lot of the View functionality out of the Mediator. I started to think about what happens when I pull the View out of the application and drop it somewhere else, and in that light it seemed like the Mediator was doing too many thing for the View. In my mind, the Mediator is just there to facilitate interoperability between other part of the application, not to be like a mom that's always wiping the kid's nose. I also feel like instantiating the views inside the Mediators, then adding that view via viewComponent.addChild(view) isn't as readable as adding that view straight to the viewComponent itself. Just a thought...

Is it a good idea to instantiate you views within their mediators? I just received a project where the views were instantiated inside their mediators. Is there any benefit to me. I feel like this further couples the view to the mediator, and doesn't make a whole lot of sense. The way I'm used to doing it is to instantiate views in my main application, then on startup link your views to their mediators. Any advice? Thanks.

You say it's nice to have state in Flex and I think you're right. I'm sort of stuck in a situation where I need to decide whether I can learn StateMachine really fast or just implement Flex states project. What would you recommend? I can only guess I'll be back with questions aboutStateMachine...

I'm building a test air app in Flash 5 Professional and had a couple of questions. I wonder how you guys are dealing with the different view states? Since I'm not in Flex or Flash Builder and don't have access to the different view states, I'm wonder what is the best way to control them in the Flash / PureMVC world. My application has a few simple states that need to either show or hide at different times. It's pretty simple, only one of a few views will be showing at any time.

The way I'm thinking to do it is to have the main application, or ApplicationMediator keep track of times. These transitions won't be fired by user clicks, only will be fired based on different times during the day. After the time is reached, I plan to fire events telling what state the app is in, like ApplicationFacade.StateOne, ...StateTwo (of course naming these events a bit more in accordance with the actual view for each state). Then have each Mediator interested in an ApplicationFacade.ViewStateChange event, passing along with a note saying which state should show it self (at which point, all others would hide and possibly destroy themselves).

Would this be a good way to go about doing it? I'm interested in hearing how others are dealing with multiple view states from the PureMVC perspective.

Thanks for the reply Tek.

I'm am totally new to PureMVC. Thanks for having me here. So far I noticed PureMVC solving a lot of questions I had when starting to develop larger flash projects, most notable managing multiple view / component events, how to keep track of them and how to make sure others knew about them.... can be a nightmare.

I've been using the project example CafeTownsend (found on this site) as a guide while writing my own sample app (a Flash Builder app that connects to twitter api). One thing that stood out to me after trying to write this sample application was the role that the Controller or Commands play. They seem to have a really passive role from what I see in other MVC frameworks like Ruby. I'm not totally versed in MVC frameworks, and I'm sure there is an explanation, but I couldn't figure it out. I was surprised that the Mediators were connecting directly to the Proxies when they needed data, not involving the controller very much during that process. Is that a normal thing in MVC?

In my application now, I can use my Flex components (Views) along with Mediators just fine to get the data I need from the Proxies. The event model makes sense and it's pretty clear how things are less coupled than other approaches and more reusable. I'm just having a little bit of trouble figuring out what role the Commands play in this process. As of now, based on the Cafe Townsend project, the Commands simply instantiate the views on startup. I don't know why but it seems a little bit odd for me to think of a Command as a Controller. If anybody wouldn't mind shedding some light on the roles that Commands play, share insightful tutorials that would be great.

Thanks