topleft

PureMVC

larger smaller reset larger Futurescale, Inc.
  • fixed-width
  • fluid-width
  • Home
  • About
  • Code
  • Docs
  • FAQ
  • Forums
  • News
  • Showcase
  • Contact
  • Jobs
topright
Demo_AS3_MultiCore_Flex_Modularity
  • Login
  • Help/Guide
  • About Trac
  • Preferences
  • Wiki
  • Browse Source

Context Navigation

  • Start Page
  • Index
  • History
  • Last Change

TracNav

  •  PureMVC Manifold...

  •  Contributors
  •  Repositories
  • Ports...

  •  ActionScript 2
  •  ActionScript 3
  •  C #
  •  ColdFusion
  •  Haxe
  •  Java
  •  JavaScript
  •  Objective C
  •  PHP
  •  Python
  •  Ruby
  •  Propose a Port

TracNav

  • AS3 MultiCore :  Modularity...

  • Downloads
  • Installation
  • Release Notes
  •  Live Demo
  •  View Source
  •  Discussion
  • Project Owner...

  •  Cliff Hall

PureMVC AS3 MultiCore / Flex Demo - Modularity

This demo illustrates simple usage of the PureMVC AS3 MultiCore Framework using Flex Modules.

Techniques Illustrated

  • Full PureMVC applications running inside Modules (simulating third party apps) running inside a another Flex app.
  • Defining interfaces for communications between Modules and the host application.
  • Interacting with the host application from a module.

Discussion

This demo instantiates and interacts with several Flex Modules, which are separate swf files loaded at runtime. The PureMVC AS3 MultiCore port has no problem running multiple Modules or loaded Flash applications based on PureMVC and running them simultaneously, and this demo shows that. Further, it demonstrates how to approach the next step of designing your MultiCore application, which is to define the APIs the host application and the Modules or 'cores' will use to talk to each other.

The demo presumes a widget hosting application wherein Widgets created by third party developers can run within the host. There is an interface that Widgets must implement in order to be hosted, and an interface for the host to implement in order for the Widgets to interact with it.

If you are familiar with PureMVC programming, you'll note only a few minor differences. One is that each ApplicationFacade's getInstance factory method takes a string argument now. The Modularity application passes in its name. The Widgets pass in a unique 'widget key'. What's going on here? Well in the MultiCore framework, the Facade, Model, View and Controller, are all Multitons.

This is a slight variation on the Singleton pattern where the Singleton instance becomes an instance map, with many instances, referenced by key. Thus each PureMVC 'core' must have a unique key. The Main app is only run once so we use a constant string 'Modularity'. However the widgets could possibly be instantiated more than once (they're not, but they could be), so they have a 'getWidgetKey' method that generates a new key based on the instance id and a unique URI for the widget.

In this simple demo, the host application (Modularity) has a Flex ApplicationToolBar which the widgets are actually instantiated in. This is done declaratively in MXML. More evolved Module loading mechanisms are beyond the scope of this demo.

The ApplicationToolBar is actually a custom component called WidgetShell which implements the IWidgetShell interface. So this toolbar holds the widgets and implements the API that the widgets use to interact with the host application.

The Widgets do similar things, but are in separate packages, and separate swf files, which could be made by separate companies. The idea is

Both Widgets do this:

  • Have their setWidgetShell method called
  • Have a Button with their name on it as the sole visual component.
  • The button dispatches an event.
  • Startup like normal (albiet very simple) PureMVC apps,
    • Registering a Proxy with some data
    • Registering a Mediator that manages the Widget application
    • The mediator listens for the event dispatched when the user clicks the widget's button.
    • When the button is pressed:
      • The Mediator creates a new button and calls the WidgetShell's addComponent method
      • Adds an event listener to the button, (so that this mediator can later hear its click and have it removed)
      • The WidgetShell sends a custom event (within the host app) of called AddComponent, passing the new button,
      • The WidgetShellMediator (in the host app) hears this translates it into a notification which it sends
      • The WidgetCanvasMediator (in the host app) hears the Notification and adds the component to its WidgetCanvas (really a Flex VBox).
      • The Mediator also calls the WidgetShell's setStatusMessage method with some text
    • When the new button is added to the WidgetCanvas, it is a part of the host app's display hierarchy, but still mediated by the Widget application!
    • When the added button is clicked, the mediator in the Widget initiates another process similar to adding a component, only to have it removed.

Download in other formats:

  • Plain Text

Trac Powered

Powered by Trac 0.11.7
By Edgewall Software.

Powered by the Subversion, Trac & Bugzilla Hosting Experts, Codesion.com

Copyright © 2006-2008 Futurescale, Inc.