Make ActionScript Design Patterns Mobile

Registering Mediators

If you look back at our ViewNavigatorApplication at the beginning, you’ll notice, that I’ve added an initial view:

1. firstView="com.digitaleavantgarce.view.components.HomeView"

This is the first view and the ViewNavigator sets it as the active view at the beginning.
I’ve moved it from the default package to a package that is more compliant to my overall structure.
It can be any view you like, but let’s say it has a button with the label “Click me” in it. It should read something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

1.	<s:View xmlns:fx="http://ns.adobe.com/mxml/2009"
2.	                xmlns:s="library://ns.adobe.com/flex/spark"
3.	                initialize="onInitalization(event)"
4.	                title="Getting Started">
5.	        <fx:Script>
6.	                <![CDATA[
7.	                        import mx.events.FlexEvent;
8.
9.	                        public static const NAME:String = 'HomeView';
10.	                        public static const CLICKED:String = NAME+'Clicked';
11.
12.	                        protected function onInitalization(event:FlexEvent):void
13.	                        {
14.	                                this.id = NAME;
15.	                        }
16.	                ]]>
17.	        </fx:Script>
18.	        <s:Button label="Click me" horizontalCenter="0" verticalCenter="0" click="dispatchEvent(new Event(CLICKED));"/>
19.	</s:View>

This should be familiar, but note two things:

First: Since the View does not have a name Property and I don’t want to implement an interface, I make sure that the id is equal to the NAME constant on initalization!

Second: When the button is clicked, it’s dispatching an event named CLICKED. Remember, that the views should not host logic, they just should forward the action to the framwork. Thus, a mediator should take care of the action.

But for now, there’s no mediator registered to the HomeView. Fortunately, we have already a ViewNavigatorMediator, which sends the Notification that our HomeView becomes the active view. And, fortunately again, we have a MediateViewCommand that get’s triggered, when the view changes. Let’s register the HomeViewMediator there!

A quick summary: The HomeView is getting instanciated and registered automatically by the ViewNavigator. When this happens, our ViewNavigatorMediator broadcasts the Notification with a reference to the HomeView. The notification itself triggers the MediateViewCommand. Here we can register the appropriate view.
That’s done with a few lines of code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

1.	package com.digitaleavantgarde.controller
2.	{
3.	        import com.digitaleavantgarde.ApplicationFacade;
4.	        import com.digitaleavantgarde.model.SomeUsefulProxy;
5.	        import com.digitaleavantgarde.view.HomeViewMediator;
6.
7.	        import org.puremvc.as3.interfaces.ICommand;
8.	        import org.puremvc.as3.interfaces.INotification;
9.	        import org.puremvc.as3.patterns.command.SimpleCommand;
10.	        import org.puremvc.as3.patterns.mediator.Mediator;
11.
12.	        import spark.components.View;
13.
14.	        /**
15.	         * Selects the appropriate Mediator and registeres it.
16.	         */
17.	        public class MediateViewCommand extends SimpleCommand implements ICommand
18.	        {
19.	                public static const NAME:String = ‘MediateViewCommand’;
20.
21.	                override public function execute(notification:INotification):void
22.	                {
23.	                        var view:View = notification.getBody() as View;
24.
25.	                        switch (view.id+‘Mediator’) {
26.	                                case HomeViewMediator.NAME:
27.	                                        facade.registerMediator(new HomeViewMediator(view));
28.	                                        facade.registerProxy(new SomeUsefulProxy());
29.	                                        break;
30.	                                // Add other Mediators likewise
31.	                        }
32.	                }
33.	        }
34.	}

Remember that the id of the view is equal to its Name. When we follow good practice, we’ll name our mediators by the scheme NameOfTheViewMediator. Thus, we can build a switch/case construct to select the appropriate mediator and register it by appending “Mediator” to the id of the view.

We also register a proxy here. The Proxy may load any data that is necessary for the view. This is not the scope of this article, but there’s an appendix at the end to make things complete!

That’s it. Now we can be sure that every view is registered automatically once the assigned view get’s active! In bigger applications you may want to unregister unused mediators, but that’s not necessary in most scenarios (because the ViewNavigator doesn’t unregister the views either).

Let’s take a look at the HomeViewMediator:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

1.	package com.digitaleavantgarde.view
2.	{
3.	        import flash.events.Event;
4.
5.	        import org.puremvc.as3.interfaces.IMediator;
6.	        import org.puremvc.as3.interfaces.INotification;
7.	        import org.puremvc.as3.patterns.mediator.Mediator;
8.
9.	        import spark.components.View;
10.	        import com.digitaleavantarde.view.components.HomeView;
11.
12.	        public class HomeViewMediator extends Mediator implements IMediator
13.	        {
14.	                public static const NAME:String = ‘HomeViewMediator’;
15.
16.	                private var homeView:HomeView;
17.	                public function HomeViewMediator(view:View)
18.	                {
19.	                        super(NAME);
20.	                        this.homeView = view as HomeView;
21.
22.	                }
23.
24.	                override public function onRegister():void
25.	                {
26.	                        homeView.addEventListener(HomeView.CLICKED, onButtonPushed);
27.	                }
28.
29.	                private function onButtonPushed(evt:Event):void {
30.	                        // Do something when the button is pushed
31.	                }
32.
33.	                override public function listNotificationInterests():Array {
34.	                        return [
35.
36.	                        ];
37.	                }
38.
39.	                override public function handleNotification(notification:INotification):void {
40.
41.	                        var name:String = notification.getName();
42.
43.	                        switch (name)
44.	                        {
45.	                                // Code goes here
46.	                        }
47.	                }
48.	        }
49.	}

The mediator gets a reference to the home view and starts listening for events when the “Click me” button gets clicked. It can than perform the necessary action. However, it can listen to notifications itself and handle them appropriate.
If you’d want to navigate to another view, for example after the CLICKED event, you’d just use one of ViewNavigators navigation functions. You have access to it via the navigation property of the view, in this case homeView.navigator!
This is PureMVC, ported to Flex Mobile!

Wrapping Up

This is complex stuff. Thank you so much for reading. We’ve build a MVC-Driven Flex Mobile App!
The basic idea is to hook to ViewNavigator and listen for the Event that is dispatched when the view changes – and register the appropriate Mediator on demand. We’ve covered some fundamentals of PureMVC along the way.
For those of you, who are already familiar with Pure MVC, the procedure may seem counterintuitive: We’re registering Mediators AFTER the associated View. But: We’ve managed to maintain the essence of the framework: We’ve kept things decoupled.
I’m looking forward to hear from your great mobile applications build with PureMVC!

APPENDIX
Alright, for those who have still energy, let’s briefly discuss the concept of proxies. We’ve instantiated a SomeUsefulProxy in our StartupCommand. A simple implementation of the proxy could read like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

1.	package com.digitaleavantgarde.model
2.	{
3.	        import com.digitaleavantgarde.model.vo.SomeUsefulVO;
4.
5.	        import org.puremvc.as3.interfaces.IProxy;
6.	        import org.puremvc.as3.patterns.proxy.Proxy;
7.
8.	        public class SomeUsefulProxy extends Proxy implements IProxy
9.	        {
10.
11.	                public static const NAME:String = ‘SomeUsefulProxy’;
12.	                public static const IMAGE_READY:String = NAME+‘ImageReady’;
13.
14.	                [Embed("data/image.png")]
15.	                private const UsefulImage:Class;
16.
17.	                public function SomeUsefulProxy()
18.	                {
19.	                        super(NAME, new SomeUsefulVO());
20.	                        vo.image = new UsefulImage();
21.	                        sendNotification(IMAGE_READY, vo.image);
22.	                }
23.
24.	                /**
25.	                 * @return data as SomeUsefulVO
26.	                 */
27.	                public function get vo():SomeUsefulVO
28.	                {
29.	                        return data as SomeUsefulVO;
30.	                }
31.	        }
32.	}

To keep things simple, I’ve just embedded an image. You may opt to load an XML here or connect to a database or whatever.
We then assign this image to our ValueObject and broadcast a notification to inform interested parties that the image is ready. I’ve also implemented a method named vo() that returns our ValueObject, this is just good practise.
The class of the ValueObject would read like this:

1
2
3
4
5
6
7
8
9

1.	package com.digitaleavantgarde.model.vo
2.	{
3.	        import flash.display.Bitmap;
4.
5.	        public class SomeUsefulVO
6.	        {
7.	                public var image:Bitmap;
8.	        }
9.	}

Just a class with the data as public property. If you’d want to access this image, say in the HomeViewMediator, you’d have to adjust the listNotificationInterest()-Method and the handleNotification()-Method like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

1.	override public function listNotificationInterests():Array {
2.	        return [
3.	                SomeUsefulProxy.IMAGE_READY
4.	        ];
5.	}
6.
7.	override public function handleNotification(notification:INotification):void {
8.
9.	        var name:String = notification.getName();
10.
11.	        switch (name)
12.	        {
13.	                case SomeUsefulProxy.IMAGE_READY:
14.	                      var bmp:Bitmap = notification.getBody() as Bitmap;
15.	                      // Do something with the bitmap, like place it somewhere in the view
16.	       }
17.	}

You could also retrieve the proxy and its value object via the facade.retrieveProxy() Method, if you wouldn’t include the image as body of the notification. This may be the case, if more complex data is involved.
Hope that helps to get you started!
If you want to play around with the example: Download the entire project and add PureMVC to the build path.

Optimizing Mobile Apps with Design Patterns

PureMVC Goes Mobile

Let’s build a cross-platform compatible, MVC-driven & ready-to-compile Mobile Application with the Flex Framework!
A year ago, finding people who bet serious money on Flash missing a connection to the mobile world was an easy task. This is no longer the case nowadays. Adobe has introduced an iOS Compiler and AIR for Android & Blackberry Playbook. With the latest release of Flex SDK 4.5.1, the average Flash-Coder is transformed to a crossplatform-ready mobile developer. Amazing times. Let’s look at how to adjust the Standard Port of the famous PureMVC Framework to be mobile-ready! The Flex SDK ships with an integrated Navigation for Mobile Views, the ViewNavigator. There is an excellent introduction to the topic, that can be found here, but I’ll give a brief overview about the concept:

Mobile Applications – especially on Smartphones – are restricted in a very important feature: Space. If you adapt a Web app to mobile, you’ll typically have much more views because you have to present the same content on smaller displays. Flex comes to the rescue by introducing the ViewNavigator. The ViewNavigator is a container, that holds references to the available views and makes navigation between them easy. You can imagine it as an array – where the view at the zero index is visible & active. It’s not a coincidence that the ViewNavigator has array-esque methods like popView() or pushView()!

The ViewNavigator is a nice way to handle views, because it’s an easy way to navigate through an app: Every view holds a reference to the ViewNavigtor – the navigator property – and can forward the application to another view on demand.
Well, it’s not all roses with the ViewNavigator! A view has its own control-mechanism as property – while it should be vice versa. Another downside: The registering and instantiation of views are becoming tasks of Flex, while you normally want to handle those tasks in your infrastructure framework of choice! Mine is PureMVC. I want to show you a way to hook PureMVC to the registering process of the ViewNavigator to build nicely decoupled applications for the mobile world. Some experience with PureMVC is recommended, but I’ll give you a quick …

Crash Course in PureMVC

You might have guessed, that PureMVC is a reference implementation of the MVC-Design Pattern. By my personal definition, MVC is not a design pattern but a composition of design patterns. And, again by my personal definition, PureMVC is a perfect composition. Take a look at the conceptual diagram! (Also, take a look at Chandima’s work on PureMVC on this blog. Minimalist PureMVC and Move the Cheese )

PureMVC is build around four singletons, known as the Core Actors. Three of them are predictably named: Model, View and Controller. I’ll come to them in a moment. The fourth is the Facade, a design pattern meant to hide complexity from the client. The client may be a Flex Application or the Document Class of an Actionscript Project, respectively the Stage (it may be much more, because PureMVC is ported for many languages)! The client forwards a reference to itself to the Facade, and the Facade boots the framework. Thus, if views are instantiated later, the Facade forwards it to the client.

The participants of the model are named proxies, but they are not following the exact definition of the Proxy pattern. There task is to supply data from all kind of sources (XML, Database …) to Value Objects. Value Objects are simple classes without methods. They host the supplied data as public properties. All proxies are hosted in the Model-Singleton and can be retrieved from it via the Facade.
The business logic is shared among commands – stateless classes that are executing tasks. Commands are hosted in the Controller-Singleton. You are registering commands via the Facade.

The last actor – the View – hosts the Mediators. They are the interface between views and the framework. The views itself are standing outside the MVC-implementation, so they can be replaced easily. The Mediators are registering the views and listen for user actions inside of them. Then they decide how a model should be manipulated based on that action. Or they trigger a command to do it and await a notification on how to present the changed model state to the user. Since all core actors are hidden from the client, you are registering mediators like its companions: via the Facade.

Notifications are PureMVC’s own implementation of the observer pattern. Mediators can register for Notifications they care about, and Commands are registered to a notification. Models do not listen to Notifications. Notifications can be send by all participants of MVC and they can contain a generic object. Notifications are a very cool alternative to Actionscripts event system, as they are available to classes that do not implement the IEventDispatcher Interface. If you want to dive in any further, read the excellent documentation on puremvc.org! If you’re hungry to build a MVC-driven mobile app, keep reading. I’ll explain details along the way.

Finally, we’re arriving the essential topic of this article: How to adjust this composition for mobile needs?

The Bootstrap

As said above, normally the Mediators are taking care of the instanciation and registering of the views. However, in Flex Mobile Applications, the ViewNavigator claims to do it – and we have to live with it. My approach is to provide a mediator for the ViewNavigator itself and listen for events that indicate a change of the view. Then we forward this information to a command that figures out, which mediator to register.

Normally you’d give a reference to the basic view to the Facade. That way, all views that are instantiated by the mediators can be placed in the base view. Since we do not place or instantiate views in mobile navigation (the ViewNavigator does), we give a reference to the ViewNavigator to the Facade. Thus, we can build our hook to ViewNavigatorEvents later.
Fire up a new Flex Mobile Project and adjust the code like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

1.	<?xml version="1.0" encoding="utf-8"?>
2.	<s:ViewNavigatorApplication
3.	        xmlns:fx="http://ns.adobe.com/mxml/2009"
4.	        xmlns:s="library://ns.adobe.com/flex/spark"
5.	        firstView="com.digitaleavantgarde.view.components.HomeView"
6.	        applicationDPI="240"
7.	        initialize="onInitalization(event)">
8.	        <fx:Script>
9.	                <![CDATA[
10.	                        import com.digitaleavantgarde.ApplicationFacade;
11.	                        import mx.events.FlexEvent;
12.
13.	                        private var facade:ApplicationFacade = ApplicationFacade.getInstance();
14.
15.	                        protected function onInitalization(event:FlexEvent):void
16.	                        {
17.	                                // Booting Framework
18.	                                facade.startup(this.navigator);
19.	                        }
20.	                ]]>
21.	        </fx:Script>
22.	</s:ViewNavigatorApplication>

This is just the prelude to PureMVC. Now let’s look how to use the framework! Let’s start with the Facade:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

1.	package com.digitaleavantgarde
2.	{
3.	        import com.digitaleavantgarde.controller.*;
4.
5.	        import org.puremvc.as3.interfaces.IFacade;
6.	        import org.puremvc.as3.patterns.facade.Facade;
7.	        import org.puremvc.as3.patterns.observer.Notification;
8.
9.	        import spark.components.ViewNavigator;
10.
11.	        public class ApplicationFacade extends Facade implements IFacade
12.	        {
13.	                public static const NAME:String = ‘ApplicationFacade’;
14.	                public static const STARTUP:String = NAME + ‘Startup’;
15.	                public static const MEDIATE_VIEW:String = NAME + ‘MediateView’;
16.
17.	                /**
18.	                 * Returns an instance of the ApplicationFacade Singleton.
19.	                 *
20.	                 * @return ApplicationFacade
21.	                 */
22.	                public static function getInstance():ApplicationFacade
23.	                {
24.	                        if (instance == null) instance = new ApplicationFacade( );
25.	                        return instance as ApplicationFacade;
26.	                }
27.
28.	                /**
29.	                 * Register controllers.
30.	                 */
31.	                override protected function initializeController():void
32.	                {
33.	                        super.initializeController();
34.	                        registerCommand(STARTUP, StartupCommand);
35.	                        registerCommand(MEDIATE_VIEW, MediateViewCommand);
36.	                }
37.
38.	                /**
39.	                 * Fired by the viewComponent on startup.
40.	                 */
41.	                public function startup(viewNavigator:ViewNavigator):void
42.	                {
43.	                        sendNotification(STARTUP,  viewNavigator);
44.	                }
45.	        }
46.	}

What’s happening here? I’m implementing some necessary stuff and am following some best practices of building a PureMVC application. In sequence … As said, the Facade is a singleton. Thus, I’m implementing a getter to the instance in the getInstance()-Method. It’s returning a reference from the heap or is instantiating one, if none is already instantiated.
Before that, I’ve defined a static constant NAME. This is good practice, to avoid naming conflicts. You should do this in every – again EVERY – member of your PureMVC Application. This is essentially in proxies and mediators, as they can be retrieved from the Facade by name.

I also defined to other static constants, STARTUP and MEDIATE_VIEW. They will be associated with the Observer-System of PureMVC, the Notifications. If you want to broadcast a Notification along your application, you’ll do this by name. You can see this in action in the method startup(), which we called in our ViewNavigtorApplication! The method startup() does broadcast a notification, using the sendNotification() Method, that is implemented by the Facade, the proxies, the commands & the mediators!

It takes three parameters: The name of the notification (equal to the name of an event in Actionscripts event system) and a generic object (in our case a reference to the view navigator). You might add a third parameter, the type as String. This is normally obsolete, as the receiver of the notification should know how to cast the object.

Notifications can be caught by mediators and commands. The STARTUP Notification is associated with the StartupCommand: I’ve overridden the initializeController() Method to register some commands. I usually register all my commands here. In bigger projects, you might consider to register them on demand.
I’ve registered a command which class is named StartupCommand, that is instantiated when the Notification STARTUP is broadcasted, and a command which class is named MediateView. This will be triggered later, when the view changes.
To summarize: I have given access to the Facade via a getInstance() method, I have defined a name and some constants that are used as name for Notifications and I’ve registered two Commands. One of them is executed on startup.
The StartupCommands kicks in after the framework is booted. Its job is to start you application:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

1.	package com.digitaleavantgarde.controller
2.	{
3.
4.	        import com.digitaleavantgarde.view.ViewNavigatorMediator;
5.
6.	        import org.puremvc.as3.interfaces.ICommand;
7.	        import org.puremvc.as3.interfaces.INotification;
8.	        import org.puremvc.as3.patterns.command.SimpleCommand;
9.
10.	        import spark.components.ViewNavigator;
11.
12.	        /**
13.	         * Registers the ViewNavigationMediator,
14.	         */
15.	        public class StartupCommand extends SimpleCommand implements ICommand
16.	        {
17.
18.	                public static const NAME:String = ‘StartupCommand’;
19.
20.	                override public function execute(notification:INotification):void
21.	                {
22.	                    facade.registerMediator(new ViewNavigatorMediator(notification.getBody() as ViewNavigator));
23.	                }
24.	        }
25.	}

There are two types of commands available in PureMVC: Simple & Macro. MacroCommands are classes that are executing multiple SimpleCommands, if you want to spread business logic among multiple SimpleCommands. We’re using the SimpleCommand here, as we do not have much logic to implement.
SimpleCommands have to overwrite the execute() method, were all actions take place.
We are registering the ViewNavigatorMediator.

The ViewNavigatorMediator

Let’s take a look!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

1.	package com.digitaleavantgarde.view
2.	{
3.	        import com.digitaleavantgarde.ApplicationFacade;
4.
5.	        import org.puremvc.as3.interfaces.IMediator;
6.	        import org.puremvc.as3.interfaces.INotification;
7.	        import org.puremvc.as3.patterns.mediator.Mediator;
8.
9.	        import spark.components.View;
10.	        import spark.components.ViewNavigator;
11.	        import spark.events.ElementExistenceEvent;
12.
13.
14.	        public class ViewNavigatorMediator extends Mediator implements IMediator
15.	        {
16.	                public static const NAME:String = ‘ViewNavigatorMediator’;
17.
18.	                private var viewNavigator:ViewNavigator;
19.	                private var activeView:View;
20.
21.	                public function ViewNavigatorMediator(viewNavigator:ViewNavigator)
22.	                {
23.	                        this.viewNavigator = viewNavigator;
24.	                        super( NAME, viewNavigator );
25.	                }
26.
27.	                override public function onRegister():void
28.	                {
29.	                        viewNavigator.addEventListener(ElementExistenceEvent.ELEMENT_ADD, switchView);
30.	                }
31.
32.	                override public function listNotificationInterests():Array {
33.	                        return [
34.
35.	                        ];
36.	                }
37.
38.	                override public function handleNotification(notification:INotification):void {
39.
40.	                        var name:String = notification.getName();
41.
42.	                        switch (name)
43.	                        {
44.	                                // ToDo
45.	                        }
46.	                }
47.
48.	                private function switchView(evt:ElementExistenceEvent):void {
49.	                        sendNotification(ApplicationFacade.MEDIATE_VIEW, evt.element as View);
50.	                }
51.	        }
52.	}

As you’ve seen in the StartupCommand, we’ve given the ViewNavigatorMediator a reference to the ViewNavigator. We forward it to the parent class, to hold it as generic object. However, to have a strictly typed ViewNavigator, we save it to a private var, too.
We then override the onRegister() method and register an EventListener for the ElementExistenceEvent.ELEMENT_ADD-Event on the ViewNavigator (previously, the event was named ViewNavigatorEvent.VIEW_ADD but was changed).
This Event is dispatched every time when the view changes. This gives us the chance to register the appropriate mediator.
Note that we do not register the mediator here, because it’s business logic. We just take the view-property of the event – a reference to the new active view – and broadcast it along with a MEDIATE_VIEW notification. Please remember, that we have registered the MediateViewCommand for this notification in our Facade. Thus, everytime the view changes, the Command gets triggered and the new active view gets injected in it. That’s our hook!

Before we go on, let’s briefly discuss the listNotificationInterests() and handleNotifications() methods. Similar to registering commands to a specific Notification, you can register Mediators to them: Just return an array with the name of the notification, that the mediator cares about in listNotficationInterests()! The handleNotfications() method will be triggered, when that Notification is broadcast. You can then choose the appropriate action with the getName() method of the Notification and a simple switch/case construct. This is mainly associated with proxies, which are not focus of this article. Read the appendix for an example!

(Part II of this Post will be Available Next Week.)

The basic difference between single-core ( now known as the standard version ) and multicore is that multicore allows multiple MVC triads (multiple cores in PureMVC parlance) to be embedded inside a single application. The general recommendation is to use PureMVC multicore for all projects as it affords a lot more power in terms of developing modular applications and unit testing. However, developers who are new to PureMVC should first develop a simple single-core application first to get familiar with the framework. My previous PureMVC post describing a minimalist example will get you started with the basics. From here onwards, I’m assuming that you have a basic understanding of how the standard version of PureMVC works.

The coding differences between standard and multicore

The coding difference between the standard and multicore versions is indeed trivial. In the standard version,  there is only one PureMVC core ( MVC triad ). So, the call to access the facade and initialize the single core is as follows:

1
2

// standard version
var facade:ApplicationFacade = ApplicationFacade.getInstance();

The facade is a singleton in the standard version. The getinstance call will always return the same facade instance as should be the case when the application is restricted to only one MVC triad. In the multicore version, there can be multiple PureMVC cores. Each facade is a named singleton that represents a separate PureMVC core. To access the facade of a particular core, you must pass its name ( or key ) as an argument in the getInstance call. The key is a string that serves as the unique identifier for a particular PureMVC core.

1
2
3

// multicore version
var facade:ApplicationFacade =
              ApplicationFacade.getInstance( applicationKey );

After you access a particular core through its facade, the programming idioms for multicore are almost identical to the standard version. There are a couple of small caveats and this post by Toby Ashley has a more detailed explanation of the differences.

The conceptual differences between standard and multicore

There is no real point in having multiple PureMVC cores in an application if they are deaf and mute. The power of multicore is realized when the cores talk to each other. However, this is where multicore throws another layer of abstraction ( and an ulcer or two ) into the mix. Cores don’t talk with each other using notifications, the now familiar communication method between the model, view and controller tiers. Communication between cores can be accomplished in two ways:

1. Using interfaces.
2. Using the Pipes Utility.

It’s all about communication

Understanding multicore is really about figuring out how to plumb your application to enable cores to talk with each other. However, at this point in time, there are very few examples out in the wild. On top of that, there are hardly any non-Flex examples. The rest of this post will show how to develop a non-Flex PureMVC multicore application that uses interfaces for inter-core communication.

When multicore came out, I felt like someone had moved my cheese because I was very comfortable with the standard version. Don’t get me wrong, multicore was the next logical iteration for PureMVC and Cliff Hall has masterfully shepherded its growth. If you feel like the cheese has moved a little bit, you will like the example app. It is called “Move the Cheese” (obviously).

Move the cheese

Move the cheese is a little game – move the piece of cheese to prevent the rodents from getting to it. Don’t expect any compelling gameplay – I chose this particular scenario to exemplify the utility of PureMVC multicore.

Screenshot showing two rats moving towards the cheese.

The Flex framework examples of multicore have a modular architecture. For example, the Modularity multicore demo  ( see source ) has a main application (the shell) that loads two types of widgets: coolwidget and superwidget. Each widget has a separate PureMVC core associated with it. The shell application has a PureMVC core as well. Coding-wise, the advantage of this modular approach is the loose coupling between the application shell and the widgets as they are completely defined by interfaces. This is particularly useful in the sense that you can write some specs for the behavior of a widget, provide the IWidget interface and let a developer go his/her merry way and develop the widget. It can be plugged into the main application shell when it’s done. This is the primary advantage of multicore, it enables the development of independently functioning modules.

In a game context, each level can be a separate module that can be loaded when the player gets to that stage. This is advantageous in a resource allocation sense as well because assets are loaded only when needed. I’m taking a different approach with “Move the Cheese” ( for simplicity’s sake ). Instead of loading levels as modules, I’m going to consider the actors ( Rats in this case ) as loadable modules. The argument being that the same actor can appear in multiple levels and will be loaded as needed. Will each rat need a separate PureMVC core? How about the cheese?

Actors vs. props

Everything is happening on the stage, so let’s extend the theater metaphor. It is helpful to consider view components that need to function independently as actors on the stage; everything else is a prop. If you think a view component  needs a brain ( logic ) to figure how they need to behave ( state ), it is quite possible that it may benefit from an MVC architecture. The rats have to figure out where the cheese is located, and move towards it at a particular speed. I think that requires some grey matter ( in a figurative sense ). Coupled with the potential re-use, I argue that each rat should be a loadable module with an associated PureMVC core.

The cheese on the other hand is a prop. Yes, it is an interactive object because the user can drag it, but it doesn’t function independently (no logic and no state). It just sits there until moved – just like a prop on the stage.

The stage ( a.k.a application shell) should have a core associated with it by default because it places actors and props on stage and brokers the communication between them.

The application shell and the rat view components have PureMVC cores associated with them.

What is a PureMVC core?

It is helpful to take a step back at this point and visualize the birth cycle of a PureMVC core. All PureMVC applications do something like the following – usually in the constructor.

1
2
3

var facade:ApplicationFacade =
         ApplicationFacade.getInstance( applicationKey );
facade.startup( this );

The first statement initializes the PureMVC core ( e.g. creates the model, view and controller named singletons). In the second statement, the application passes a reference to itself to the ‘startup’ method in the facade. The application in most cases is the root view component (e.g. the document class in a Flash CS3 app, a Flex MXML application). In short, the root view component initializes a PureMVC core and injects itself into it. I couldn’t help but visualize this scenario as a snail without a shell, creating one and crawling inside it.

Birthing a PureMVC core: The snail and shell analogy.

How do cores talk to each other using interfaces?

Cores talking with each other is a bit of a misnomer. Each PureMVC core is well encapsulated like a snail that hides inside its shell. Talking depends on how much the root view component (snail body) exposes itself outside the PureMVC core. It is the view components that really do the talking between cores. The language they speak is defined by interfaces. A core that doesn’t talk is like a snail that never comes out of its shell.

The view component (snail body) needs to expose itself outside the PureMVC core (shell) to talk.

We can now get back to the application and define some interfaces.

Application specs

Now that we have thought through the application, let’s nail down some specifications. The application shell will know where the cheese is located, so it has to expose the cheese location to the rats. The rats in turn need to have a reference to the shell so that they can query the shell and get the cheese location. The application shell also takes the responsibility to place the rats on the stage and  update them at specific time intervals. So, the rats needs to expose initialization and update methods as well. Let’s write a couple of interfaces: IActor for the rats and IApplicationShell for the application.

IApplicationShell interface

1
2
3
4
5
6
7
8
9

package com.as3dp.puremvc.movethecheese.interfaces
{
	import flash.geom.Point;
 
	public interface IApplicationShell
	{
		function get cheeseLoc():Point;
	}
}

IActor interface

1
2
3
4
5
6
7
8
9

package com.as3dp.puremvc.movethecheese.interfaces
{
	public interface IActor
	{
		function setApplicationShell( shell:IApplicationShell ):void;
		function init():void
		function update():void
	}
}

Inter-core communication through interfaces implemented by their root view components

The root view component of  the application shell will implement the IApplicationShell interface and the rat view component will implement the IActor interface. The rest is mostly code and I don’t want to do a huge code dump on the post. So feel free to browse the source, or better yet, download it into a Flex/Flash builder or Flash CS3/4 and make it your own. I will discuss a few things to look out for before wrapping up the post.

Don’t expose core keys

If you expose the key, which is the unique identifier that identifies a core, anyone can get its facade and manipulate it. This breaks encapsulation. Use the UIDUtil.getUID static method and use the private getter (learned this from an app created by Joel Hooks).

1
2
3
4
5
6
7
8

/**
 * Get unique identifier for this puremvc core
 * Use this key in the call to getInstance( key )
 */
private function get key():String
{
	return UIDUtil.getUID(this);
}

See MoveTheCheese.as and Rat.as to see how this is used in context.

Building multiple applications in a Flex project

If you download the source and build the app, MoveTheCheese.as is the default application. Rat.as need to be built as an application as well because it is loaded in the application mediator. Right click on the project in the Flex Navigator view and choose properties > ActionScript Applications. Now add Rat.as to the runnable applications list.

Advantages of loading Rat.swf

Take a look at the ApplicationMediator class ( ApplicationMediator.as ) constructor. The first rat is instantiated using the new keyword and typed as Rat. The second rat is a loaded Rat.swf file and is typed as DisplayObject. All we know about Rat.swf is that it is a display object that implements the IActor interface. All implementation details are hidden. The loadable rat exemplifies the power of loadable modules. We can easily load a whole bunch of rodents, ants and all kind of pests that conform to theIActor interface. We can distribute development to multiple developers requiring only the swf file in return.

Have a blast with multicore – make sure those snails stick their heads out of their shells.