Thank you so much for your detailed explaination. I've adjusted my Code.

But I do not understand, why this is a better approach then mine "all proxies report to a major proxy":

Actually it's fine for any mediator to know any proxy, just not the other way round. Here again, the direction of the coupling is key. If anything's truly reusable in your app it'll be the Model region; the proxies.

In my Examlpe I use a LocalStorageProxy. If in the future, the Datasource would change to an XML, I'd have to adjust the Mediator. If the LocalStorageProxy would process its data and pushes it to an ApplicationProxyVO, no one would have to care (the decoupling would work in both directions). Would you mind to drop a line bout this? Thanks!

... after reviewing my upper post, I saw, that I broke my own approach 

The LocalStorageProxy does not report to the ApplicationProxy, thus the LocalStorage is coupled to the ApplicationMediator. I'll fix that

Thanks for pointing that out.

I've adjusted my ApplicationMediator. I had a discussion in the german flashforum. Someone gave me the interesting opinion, that the Mediator are upstreamed Controllers (while I was thinking there are downstreamed views ...).

Thus, most of the time I have to main Heroes in my Apps: The ApplicationMediator & the ApplicationProxy: The ApplicationProxy hosts all neccessary data & Proxies that are coupled to a concrete source (e.g. XMLProxy, DatabaseProxy ...) report to him & the VO. Thus, other proxies are more or less plugins to the Main ApplicationProxy.

On the other hand, the ApplicationMediator hosts a reference to the BaseView & handles some stuff like listening for Events that all Mediators care about.

Thus, I'm registering Mediators directly from the ApplicationMediator (and am using Commands rarely). Guess that's bad practice, huh?

Here's my final version.

E.g. the ApplicationFacade.LOG notification is logged always when something bad happens (Error Events). If I want to handle it via AlertBoxes or redirect it to the Javascript console or whatever, I can do it here.

The  ResourceLanguage Change (Basically it makes the IResourceManager available from none flex-based as3 files & manages access to language classes) should result in update the language in all Mediators - (setLang() is defined by the interface). Thus, an ApplicationMediator comes in handy for me.

Another Problem on the ViewNavigator: The element property of the ElementExistenceEvent returns a View - thus I cannot access the MyMediator.NAME const, as best practise would recommend without casting every single Mediator.

That's why I set the id == MyMediator.NAME on initalize & use it as synonym in the AppMediator ...

:

protected function onInitalization(event:FlexEvent):void
{
this.id = NAME;
                        }


:

package com.digitaleavantgarde.view
{

import com.digitaleavantgarde.ApplicationFacade;
import com.digitaleavantgarde.model.LocalStorageProxy;
import com.digitaleavantgarde.utils.lang.ResourceLanguage;

import flash.net.registerClassAlias;

import org.puremvc.as3.interfaces.IMediator;
import org.puremvc.as3.interfaces.INotification;
import org.puremvc.as3.patterns.mediator.Mediator;

import spark.components.View;
import spark.components.ViewNavigator;
import spark.events.ElementExistenceEvent;

import views.AnotherView;
import views.HomeView;

public class ApplicationMediator extends Mediator implements IMediator
{
public static const NAME:String = 'ApplicationMediator';

private var viewNavigator:ViewNavigator;

private var activeView:View;

public function ApplicationMediator(viewNavigator:ViewNavigator)
{
                        this.viewNavigator = viewNavigator;
super( NAME, viewNavigator );
}

override public function onRegister():void
{
viewNavigator.addEventListener(ElementExistenceEvent.ELEMENT_ADD, switchView);
}

override public function listNotificationInterests():Array {
return [
ApplicationFacade.LOG,
LocalStorageProxy.LANGUAGE
];
}

override public function handleNotification(notification:INotification):void {

var name:String = notification.getName();

switch (name)
{
case ApplicationFacade.LOG:
trace(notification.getBody());
break;

case LocalStorageProxy.LANGUAGE:

ResourceLanguage.getInstance().setLang(notification.getBody() as String);

if(activeView!=null) {
var viewToUpdate:ILanguageMediator = this.facade.retrieveMediator(activeView.id) as ILanguageMediator;
viewToUpdate.setLang();
}
break;
}
}

private function switchView(evt:ElementExistenceEvent):void {

if(activeView!=null) {
this.facade.removeMediator(activeView.id + 'Mediator');
}

activeView = evt.element as View;

switch(activeView.id) {
case(HomeView.NAME):
this.facade.registerMediator(new HomeViewMediator(activeView));
break;

case (AnotherView.NAME):
this.facade.registerMediator(new AnotherViewMediator(activeView));
break;
}
}

}
}

This works great for me, but I'm bit afraid of programming cross the purpose of the framework

Well, thanks. I got it up and running. Since I'm fairly new, would you mind take a look if this is ok?

Thank you all!

The Event is not ViewNavigatorEvent.VIEW_ADD, but ElementExistenceEvent.ELEMENT_ADD!

See: http://opensource.adobe.com/wiki/display/flexsdk/View+and+ViewNavigator

I'm booting the framework with the ViewNavigator like this:

:

<?xml version="1.0" encoding="utf-8"?>
<s:ViewNavigatorApplication xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
firstView="views.TemplateHomeView"
applicationDPI="240"
initialize="onInitalization(event)">
<fx:Script>
<![CDATA[
import com.digitaleavantgarde.ApplicationFacade;

import mx.events.FlexEvent;

private var facade:ApplicationFacade = ApplicationFacade.getInstance();


protected function onInitalization(event:FlexEvent):void
{

// Booting Framework
facade.startup(this.navigator);

}
]]>
</fx:Script>
</s:ViewNavigatorApplication>

The rest is pretty straighforward, I have an application mediator and can handle the events.

Proof of concept:

:

public function ApplicationMediator(viewNavigator:Object=null)
{
super( NAME, viewNavigator );

viewNavigator.addEventListener(ElementExistenceEvent.ELEMENT_ADD, function(evt:ElementExistenceEvent):void {

var activeView:View = evt.element as View;
trace(activeView.title); // traces the title
});
}


Thanks for your answers.

I'll dive in & report

Hello all,

I'm reactivating the thread, 'cause I'm getting started with Flex Mobile too and am lacking a great idea of integrate it with pureMVC.

May I ask you to bring us up to date your research?

I'm playing around with a few ideas. Most of them are build this way:

I'm registering a navigatorMediator as MainMediator & it holds a reference to the Navigator and a <vector> with all views. When the user navigates, the navigatorMediator is called, registeres a dependent mediator and so on.

This is somewhat counterintuitive and I'm wondering if there's a better solution.