That said, it’s a complex topic, and I’d rather defer on the side of assuming the user needs all the possible details for this complex subject.

First off, mad props you actually successfully implemented multi-core. Most complicated shiz I’ve ever seen in my life.

Second, Mediator’s already have a reference to facade built in, so not sure I get what you mean about reference back to the Facade.

Third, that’s my point; avoiding writing clean up code, and instead just using a weak reference is easier to get away with now than it was back in Flash Player 9. That said, there is still many other things to clean up often, not just listeners, hence if you’re going to clean up other stuff, you might as well clean up listeners. However, using weak listeners that you later plan to clean up is fine; I don’t see the harm there; it’s just the intent makes no sense. If you’re going to use a weak listener as well as listening for the PopUp’s CloseEvent.CLOSE in order to write clean-up code… don’t use a weak listener. People reading the code will get confused.

Good article, albeit very long-winded!

I’ve found that while trying to keep code D.R.Y., and particularly when utilizing a multi-core application, doing something like ApplicationFacade.getInstance() can cause issues. Primarily because of the direct dependence of a singular(not in just pattern, but in purpose) ApplicationFacade (which in a multi-core app is never the case), and a RTE regarding casting. Because of this, my mediators typically have a reference back to the Facade that is critical to remove the references to.

I typically use weak listeners anyway, often removing when I’m no longer needing them. The best example I can think of is a popup that plays a playlist of audio (such as composite instructional audio), but the user has the opportunity to close the window at any time. To avoid having to write the destroying of the event listener, I rely on the weak listener… Is this bad practice? I’ve yet to see a leak in this regard, but have come across others that I haven’t been able to identify yet (specifically speaking, loading a semi-to-complex SWF created in Flash).

Secondly, yes, I do do it that way. I’ve only had to register multiple same type Mediators in one AIR project. That was the exception to the rule. PureMVC out of the box doesn’t support this anyway because all the Mediator’s have to have different names so clearly Cliff didn’t think this would be a common practice. That said, people like Joel Hooks have stated to DO do this often… :: shrugs ::

Either way, yeah, my ApplicationMediators do get kind of big, but the easy way to fix is just refactor into multiple Facade’s that reside in their respective domain. You have to do this anyway if you’re creating modules, or just generally large projects. Loading everything up front, while easier to read, makes it hard to scale and unload parts from memory. If you load all Mediators once, for example in your Facade, then you have to write code elsewhere to re-register it.

Additionally, those 2 lines of code allow a clean separation in a View. If you need to test a View in isolation because someting funky is going on, you can just comment out those 2 lines of code, and the View no longer has dependencies on the framework. In large applications, this is a must. Otherwise, solving GUI related bugs takes a loooooong time.

…for smaller projects, no, I register everything up front.

ApplicationFacade.getInstance().registerMyView(this);

to:

facade.registerMediator(new MyViewMediator(new MyView()));

This would only work for registering Mediators of the same type. Surely you don’t create a custom register method for every Mediator type in your application? Just curious