PureMVC Tutorial – Flex, PureMVC, Jabber and XIFF 3: Part 6 – The Application View & Mediator

Introduction
Part 1 – Frameworks
Part 2 – Directory structure
Part 3 – Application and ApplicationFacade
Part 4 – Notifications, Commands & Use Cases
Part 5 – Model & Proxy
Part 6 – The Application View & Mediator
Part 7 – The Login View & Mediator
Part 8 – The Roster View & Mediator
Part 9 – The Chat View & Mediator
Conclusion, Demo & Downloads

Congratulations on getting this far – we’re getting closer to our working Jabber client ๐Ÿ™‚  Before we get going with our first top-level mediator we’ll talk about views in a little more detail.  In PureMVC a view consists of:

  • One or more view components.  This is the thing that the user actually sees and interacts with – in Flash it will be a Sprite or MovieClip, and in Flex it will be an MXML file (or an AS file extending a flex component).
  • A mediator.  This is the PureMVC bit of the view and ‘heralds’ the view components.  Any interaction with the rest of the application is done through the mediator.  Note that although the mediator knows about the existence of the view components, the view components don’t know about existence of the mediator!
  • Events.  Although not strictly a part of the view, I find it helpful to think of events within the same bundle.  View components communicate with their mediator via events and its common to create custom events for various interactions within the view component.  For example, when we come to the Login view we’re going to be dispatching a custom LoginViewEvent to the LoginMediator when the user clicks on the ‘connect’ button.

PureMVC makes no assumptions about the way that you structure the tree of views and mediators, apart from requiring that there is one top-level mediator.  In the words of our great leader, Cliff Hall (the creator of PureMVC):

It is up to you as a developer to determine the granularity of the View Component that is handled a given Mediator. If a Mediator becomes too bloated dealing with all the children of its View Component simply create a Mediator for the more complicated child. For instance, if the child components of the Application instance are complicated enough to justify their own Mediators, then the ApplicationMediator typically creates and registers the appropriate Mediator for each of those children.

This means that you start off with one mediator for your application entry point (i.e. Application.mxml) and then add extra mediators as needed.  In general you tend to have one mediator per visual ‘section’ of your application, but this is by no means enforced.

Create our ApplicationMediator.as in the view folder with Add->New Mediator… (if you don’t see this menu item be sure you’ve installed the PureMVC FlashDevelop templates from PureMVC: First thoughts & FlashDevelop templates correctly).

At this point its a good idea to add in a helper method to allow you to retrieve the view component that this mediator is looking after (in this case Application.mxml).  To do this add the following private getter:

   1: private function get application():Application {
   2:     return viewComponent as Application;
   3: }

This saves having to constantly case viewComponent to the correct class every time we use it.  Unfortunately I couldn’t find a way to get a FlashDevelop template to downcase the class name so we can’t generate this function within the template, but you’ll soon get into the habit of typing it each time you create a new mediator.

Finally we need to add our new mediator to PureMVC using the registerMediator command in StartupCommand.  The execute method in this command should now read:

   1: override public function execute(notification:INotification):void {
   2:     facade.registerProxy(new XMPPProxy());
   3:     
   4:     facade.registerMediator(new ApplicationMediator(notification.getBody() as Application));
   5: }

Notice the argument passed to the Mediator – this is the view component that the mediator is supposed to look after (in this case Application.mxml).  notification.getBody() retrieves the argument passed along with the notification, and since we sent the notification (in Application.mxml) using facade.sendNotification(ApplicationFacade.STARTUP, this) that argument will be the Application object itself!

Now we’ll create the Login view and mediator.

4 comments

  1. ah. sorry, just seen it. I think the template for the startup command automatically creates the execute function with a ‘note’ not ‘notification’ parameter. my mistake ๐Ÿ™‚

  2. hi ,
    I have added helper method as get application() and return viewCompoent as Application.

    when trying to access component from main application as

    application.mycomponent

    It gives a compile time error saying unable to access mycomponent.

    how can i access myComponent with reference to application getter.

  3. Hey Prashant,

    If you are using an IDE that automatically adds your imports it might have got it wrong and added mx.core.Application or spark.components.Application instead of the actual Application.mxml that we are using.

    On reflection it probably wasn’t totally sensible for me to have used Application.mxml as the name of the view ๐Ÿ˜‰

    Good luck,

    Dave

Leave a Reply

Your email address will not be published. Required fields are marked *