By paddloPayday loans

Home > MVC, PureMVC > Move the Cheese: A non-Flex Actionscript example of a PureMVC Multicore Application

Move the Cheese: A non-Flex Actionscript example of a PureMVC Multicore Application

Although it may be a small conceptual leap for someone who has experience with the single-core version of PureMVC to visualize how multicore works, it can be a little daunting for a novice. This post describes the design and development of a simple game concept to exemplify the utility of PureMVC multicore. This is a pure AS3 app that doesn’t use the Flex framework. You can download the source and build the app  in Flex/Flash Builder (as an AS3 project) or Flash CS3/4.

DEMO

VIEW SOURCE

DOWNLOAD

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:

?View Code ACTIONSCRIPT3
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.

?View Code ACTIONSCRIPT3
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.

movethecheese

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.

actors_with_cores

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.

?View Code ACTIONSCRIPT3
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.

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.

talking_snails

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

?View Code ACTIONSCRIPT3
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

?View Code ACTIONSCRIPT3
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
	}
}
root_view_components

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.

DEMO

VIEW SOURCE

DOWNLOAD

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).

?View Code ACTIONSCRIPT3
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.

DEMO

VIEW SOURCE

DOWNLOAD

Share
Categories: MVC, PureMVC
  1. July 22, 2009 at 11:50 pm | #1

    Great post, we will add it asap.

  2. July 23, 2009 at 12:01 am | #2

    Great tutorial, thanks!

  3. David
    July 23, 2009 at 1:54 am | #3

    A very useful example, thanks.

  4. David Wilhelm
    July 23, 2009 at 6:30 am | #4

    Nice vivid examples. I like the snail :)

  5. July 23, 2009 at 9:47 am | #5

    Thanks. I’ve finally got straight this multicore thing. Those Flex examples weren’t helping much. :)

    • Chandima Cumaranatunge
      July 23, 2009 at 10:29 am | #6

      Thanks to everyone for the nice remarks.. Rafael, you represent the exact target audience for this post – good to know that I’ve hit the target.

  6. July 26, 2009 at 7:15 am | #7

    Thanks Chandima for taking the time to create this example. Would you be kind enough to explain why you have the display logic for the rat within the mediator? Is this just to keep this example simple? Would it not be better practice to have a view component for this in a package like com.as3dp.puremvc.movethecheese.actors.rat.view.components ?

    Both this article and your previous single core article have proved extremely enlightening over the last couple of days. Thanks again.

    • Chandima Cumaranatunge
      July 26, 2009 at 9:03 am | #8

      Hi Hoss,

      Yes indeed! I didn’t put it into a separate package as the display code was simple. However, thinking back, I should have stuck with convention and put it into separate components package like you suggest. I’m glad to hear that the examples are helpful – thanks.

  7. sitron
    July 27, 2009 at 1:23 am | #9

    hello!
    thanks for this very interesting example!
    just a concern about file size: am i right in thinking that both “shell.swf” and “rat.swf” will contain puremvc classes? is there a way to optimize this?
    thanks.

    • Chandima Cumaranatunge
      July 27, 2009 at 8:50 am | #10

      @sitron, You are correct! Rat.swf is a full fledged application and contains the PureMVC classes. This is because Rat.swf is not an ActionScript module. I grappled with this issue when developing this example.

      In the Flex framework, Flex modules extend the mx.modules.Modules class. This class extends FlexSprite and is already a display object. In the Flex famework, the Rat would extend mx.modules.Modules and could be compiled as a Flex module optimized for the main application. The optimization ensures that there is no code duplication.

      However, you cannot use the mx.modules.Modules class for the pure Actionscript application. To create a module in an ActionScript project, you must extend the mx.modules.ModuleBase class. I have no idea why, but this class does not extend DisplayObject. Modules in ActionScript seem to be designed for code as opposed to display objects.

      I didn’t do any deep research on this topic, but decided that one cannot have modules that are display objects in an application that doesn’t use the Flex Framework (I hope I’m wrong – it’s a win for all of us if this assumption is incorrect).

      For more details on modules and loading sub applications. See:

      http://livedocs.adobe.com/flex/3/html/help.html?content=modular_2.html and http://livedocs.adobe.com/flex/3/loading_applications.pdf

  8. August 5, 2009 at 6:53 am | #11

    I think PureMVC Standard is wonderful, and I like some things about it better than Cairngorm. Last year I wrote my first MultiCore application. I learned a valuable lesson from that experience: pipes are malarky, and MultiCore is rubbish. Here are the reasons why:

    (1) Pipes are not built-in. You have to download that part of the framework separately.

    (2) Setting up pipe connections between two cores is extremely complicated. No wonder there are no non-trivial examples online.

    (3) There is a better way to modularize applications, and it doesn’t require pipes at all. Remember that when the Flash Player loads modules, it’s loading CLASSES, NOT instances or data. There is no need for a module to act like a full-blown application. Your modules should contain low-level, re-usable components, like related groups of views, proxies, and mediators. The main facade can then register those once the module is completely loaded. Design your modules to be plug-ins rather than cores. It’ll make things so much easier. This was ultimately the direction that I took with my MultiCore application.

  9. Allan
    August 13, 2009 at 8:17 am | #12

    Nice tutorial– When I compile the code for Flash CS3 it appears that the ApplicationMediator class is attempting to import a class that exists only in the Flex framework: mx.utils.ObjectUtil. At least, that’s the only instance that a search of my hard drive turned up. Fortunately I have the Flex SDK.
    Dang, that mouse is spooky.

  10. Mayur Kala
    August 20, 2009 at 6:15 am | #13

    Great Tutoriual.
    Thanks.

  11. Chandima Cumaranatunge
    August 27, 2009 at 12:05 pm | #14

    Hi Andrew,

    I share your admiration for the original PureMVC standard implementation. I was hooked after taking one look at the conceptual diagram. The framework was light, used the design patterns that I understood well and the symmetry was really elegant.

    You have made some provocative comments and I’ll try to address all of them.

    The fact that Pipes are not built-in is by design. Cliff has frozen the framework and additional functionality can only be added through utilities. I like this because it keeps the framework light and doesn’t break portability of the core framework.

    However, I do share your dislike for Pipes because of their complexity. The architecture is indeed elegant because it models UNIX pipes, but fails the original test of why I like PureMVC so much – the fact that I could learn it easily. I took a look at the pipes utility and the examples and decided to stick with interfaces for inter-core communication.

    You have piqued my interest, but I can’t visualize the modular application you describe. Some example code or link would be very helpful. I was disappointed to find that it is not possible to develop a true modular core without using the Flex framework. However, I do like the multicore concept as it enabled distributed development. Implementing multiple instances of the same “actor” is possible using single core, but requires additional code. Multicore provides a more elegant solution to this requirement.

  12. Chandima Cumaranatunge
    August 27, 2009 at 12:09 pm | #15

    Hi Allan,

    Thanks for pointing out that the mx.utils.ObjectUtil package resides in the Flex framework. I should have checked this beforehand.

    Using the mx.utils.ObjectUtil package is not absolutely necessary. I used it because it provided an elegant way to generate a unique key for a core.

    All one needs to do is return a unique string in the get key() method.

  13. September 4, 2009 at 1:07 pm | #16

    Chandima: I’m talking about the mx.modules.Module class. You can compile modules into separate SWF’s, and your application can load them at run-time to get new functionality. This is better than trying to use cores. A core is essentially a module that has to be instantiated and incorporated into the framework with pipes. The alternative is to load a module through a proxy, and then when it’s completely loaded, instantiate it and register it as a new view. You can package the appropriate views, mediators, and even additional proxies into a module. Ideally you put classes into your module that your application can use but should not necessarily include for every user experience.

  14. Stephen Downs
    September 17, 2009 at 4:54 pm | #17

    Thank you for this information. I’m puzzling over one recommendation though, and that is your advice to keep the facade key a private method of the particular application core class.

    By keeping this key private to the application core, no other actors that comprise the subsystem of the application can access the facade. I thought the point of an application facade was to simplify the API, not completely cloak it.

    In my PureMVC implementations, I’m very frequently doing things like getting abstracted localized data from model proxies via calls from an integral subcomponent to the facade (a retrieveProxy call). It seems like a class proliferation (or in this case an app proliferation) nightmare if I have to create separate cores for every integral subcomponent in my system, and build special pipes or interfaces just to call on proxy models, which is implied by closing up the facade.

    Or perhaps I’ve missed something?

    I can understand the concern about hiding the application key to actors that aren’t a part of the application, but there has to be a more elegant and non-restrictive solution.

  15. Chandima Cumaranatunge
    September 18, 2009 at 3:18 pm | #18

    Hi stephen,

    An exposed core key is like a global variable that exposes everything inside a core. If this is desirable in an application I don’t see a problem with it.

    One of the big advantages multicore brought to the table was better testability. Allowing each core to be independently tested. You can only do this if access to cores are controlled (e.g. via interfaces) and inter-core dependencies are injected ( e.g. setApplicationShell — setter injection ).

    Exposing a core key and allowing another core to access its proxy creates a hard dependency between the cores. Much like class ‘A’ accessing a public method in Class ‘B’ makes ‘A’ dependent on ‘B’. It is more desirable to inject dependencies as it makes dependancies explicit.

    I do realize that this all sounds quite purist but it can be very important if you are doing TDD. Miško Hevery calls this issue “hidden collaborators” and describes it in detail on his talk on global state and singletons.

    http://misko.hevery.com/2008/11/21/clean-code-talks-global-state-and-singletons/

    http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singletons/

    Incidentally, the Modularity demo on the PureMVC site exposes core keys as well ( see the widget components ).

    http://trac.puremvc.org/Demo_AS3_MultiCore_Flex_Modularity

    However, that is not necessary for the app to work.

  16. Stephen Downs
    September 21, 2009 at 12:35 pm | #19

    Re: Incidentally, the Modularity demo on the PureMVC site exposes core keys as well ( see the widget components ).

    Yes, that is precisely what I was going to mention! I’ve been doing all my multicore PureMVC coding thus far following the Modularity example, which is why I questioned your approach.

    Thank you for taking the time to respond and provide additional links and explanation. It does begin to make sense that injecting dependencies makes the relationship explicit.

    I will have to revisit this in my current multicore PureMVC application where I’m trying to smoothly implement globally controlled localization throughout all the disparate modules/cores. In the single core past I’ve created a ResourceProxy class that wraps the ResourceManager (Flex) and provides a few enhancements. Each mediator sets the localizable strings in the component it shepherds on initialization by performing a retrieveProxy on the facade, getting a reference to the ResourceProxy, sending the key for the string it needs to localize, then setting the result on the bindable property of the component. When a locale change occurs, an ApplicationFacade.LOCALE_CHANGE notification is sent, and all views that are concerned with dynamically changing their locale strings can pick up on that via their mediators re-querying the ResourceProxy for updated strings.

    Implementing this is a proper multicore fashion, I suppose I would create an ILocalizable interface for each module to adhere to, which includes a setResourceSource method and a setLocale method. The shell would have to include accessor methods for all the needed methods of ResourceProxy. As each view is loaded in the module, the mediator of that view would query the module facade to provide the localization data by passing a key string, which the facade will pass to the main module class that adheres to the ILocalizable interface, which in turn will ask the shell (resourceSource) for the localized data via a public method (at which point the shell can retrieve the true ResourceProxy reference and get the value), and send the value back to the mediator so it can be set. When a locale change occurs, an ApplicationFacade.LOCALE_CHANGE notification is sent in the main shell app, and all loaded modules that are ILocalizable will have their setLocale methods called (at which point they can query for new data). It’s a few more steps, and requires the main shell application to include a number of accessor functions for ResourceProxy.

    Perhaps a multicore application that requires heaps of data passing would benefit from a pipes-style implementation instead. I’m still pondering this.

  17. David Pesta
    October 22, 2009 at 8:35 pm | #20

    I’m really getting the hang of understanding all of this. One thing that really boggles me though is your use of “app” in ApplicationMediator.as on lines 55-57 (and other places):

    55 cheese.x = app.stage.stageWidth / 2;
    56 cheese.y = app.stage.stageHeight / 2;
    57 app.addChild( cheese );

    When I replace “app” with “viewComponent” in every case, it still works perfectly. I have two questions:

    1. Why does using “app” NOT break the program? (What does it reference?)
    2. Why did you use “app” instead of “viewComponent”?

    What is perplexing about my first question is that the Mediator.as class clearly makes “viewComponent” the class member, not “app”. Why does using “app” even work? I know this must be a basic AS3 question, but it has me scratching my head. :D

  18. David Pesta
    October 23, 2009 at 4:04 pm | #21

    I found the answer to #1 inside ApplicationMediator.as:

    110 public function get app():MoveTheCheese
    111 {
    112 return viewComponent as MoveTheCheese;
    113 }

    I guess I’m still wondering the benefit of doing this. I suppose it brings clarity to the code rather than just using “viewComponent”, which can be ambiguous depending on what context you are in.

  19. Chandima Cumaranatunge
    October 23, 2009 at 5:09 pm | #22

    Hi David,

    The first time I looked at PureMVC mediator code, I had the same confusion. It is a “best practice” in PureMVC (see docs) to do it this way and I’ve stuck with it.

    In addition to providing clarity it also casts the viewComponent to its proper type. This is useful as the injected viewComponent is assigned to a property of type Object in the Mediator. See the Mediator.as here:

    http://puremvc.org/pages/docs/AS3/standard/framework_source/

    This practice saves you from casting the viewComponent to its type each time you access/manipulate it.

  20. David Pesta
    October 24, 2009 at 8:04 am | #23

    If it’s a best practice, that means it will save me trouble later on. Thanks again!

  21. David Pesta
    October 30, 2009 at 4:03 pm | #24

    Hello Chandima,

    I have come across an even more interesting issue that I cannot seem to figure out. This involves attempting to load an SWF core from a different domain, which can be useful when distributing various SWF game areas among different content servers to distribute to a massive audience.

    Using your Move the Cheese program as an example, in ApplicationMediator.as, focusing on lines 72 and 100:

    72 var url:String = “http://localhost.rat.com/Rat.swf”;

    100 IActor(rat).setApplicationShell( app as IApplicationShell );

    The only change I make to your program is line 72 as shown above. (Your program works perfectly before I make that change.) Then, after placing Rat.swf in the right place on my local webserver, and running the program again, I get the following runtime error in my debugger:

    TypeError: Error #1034: Type Coercion failed: cannot convert Rat@15d8431 to com.as3dp.puremvc.movethecheese.interfaces.IActor.
    at com.as3dp.puremvc.movethecheese.view::ApplicationMediator/completeHandler()[C:\Documents and Settings\David Pesta\Desktop\MoveTheCheese\source\src\com\as3dp\puremvc\movethecheese\view\ApplicationMediator.as:100]

    I even tried having Rat.swf give full Security permissions to all external SWF files by putting Security.allowDomain(“*”); inside of a constructor for Rat (and I can confirm by other means that Security.allowDomain(“*”); is behaving properly there). However, I continue to get the same error message.

    I’ve repeated all of this a number of times to be confident in what I am experiencing. Is there something else that I can try to get it to work? Some special trick that I don’t know about?

    I genuinely appreciate your help.

  22. David Pesta
    October 31, 2009 at 2:47 pm | #25

    I have created a series of very thorough examples that demonstrate what appear (for now) to be limitations to multicore using interfaces: http://forums.puremvc.org/index.php?topic=1516.0

    That forum post will probably be more helpful than the comment I posted above. :)

  23. Chandima Cumaranatunge
    November 1, 2009 at 7:01 pm | #26

    Hi David, the issue with loading the swf from a different URL sounds like a cross-domain policy issue. However, you seem to have taken care of that. Did you try to place a policy file in the web root and see if that fixes it?

    1
    2
    3
    4
    
    <?xml version="1.0"?>
    <cross-domain-policy>
      <allow-access-from domain="*" />
    </cross-domain-policy>
  24. David Pesta
    November 2, 2009 at 6:16 pm | #27

    Yes, the crossdomain.xml file is necessary inside of localhost.rat.com. It also requires passing a LoaderContext object as a 2nd parameter to the loader.load method inside ApplicationMediator.as:

    var context : LoaderContext = new LoaderContext(true);
    context.securityDomain = SecurityDomain.currentDomain;
    context.applicationDomain = ApplicationDomain.currentDomain;
    loader.load( new URLRequest(url), context );

    It works good, as long as you are viewing the app shell swf within an HTML object using a web browser pointing at a domain via http (not viewing the file locally with the browser). Otherwise you get a different security error.

    I am so pleased at how responsive and helpful the PureMVC community is. Thanks again Chandima.

  25. January 1, 2010 at 9:25 pm | #28

    Thanks for sharing! You tutorial was very helpfull for me, thanks again.

  26. sideDoor
    January 8, 2010 at 12:28 am | #29

    Great stuff again! Hilarious, “someone moved my cheese” – I will have to cop that!

    I went through your pureMVC minimalist example and now this one, and you know what? I get it all! It’s like a new Lego set! Thanks so much!

    Uh, now, what about this Class: import mx.utils.UIDUtil

    To use: UIDUtil.getUID(this);

    I’d like to use this util, but my compiler can’t find this Class, what’s the dealio here?

    I’m running FB 3.0.2, and tried using both Flex SDK 3.4 and 4.0, targeting Flash Player 10. Do I have to muck about with the flex-config.xml file to ensure the appropriate player is targeted, er something? What can’t I find this Class?

    Thanks again,
    sd

  27. Chandima Cumaranatunge
    January 8, 2010 at 8:12 am | #30

    @sideDoor That was an oversight on my part. The UIDUtil.getUID class is only available in the Flex Framework ( as pointed out by @Allan ). It will be available if you create the app as an ActionScript project in Flash/Flex Builder.

    You don’t have to use the mx.utils.ObjectUtil package. I used it because it provided an elegant way to generate a unique key for a core.

    All one needs to do is return a unique string in the get key() method.

  28. sideDoor
    January 8, 2010 at 12:12 pm | #31

    @Chandima

    Oh, cool, I actually did a search of the page using “UIDUtil” to see if others were having/solving the issue, but didn’t skim close enough to see Allan’s post on ObjectUtil…

    Thanks for your time!

  29. February 26, 2010 at 12:58 pm | #32

    Thanks. This is a great post. I am trying it out now.

  30. sideDoor
    April 4, 2010 at 10:01 pm | #33

    Hello again,

    I don’t understand this:

    “If you expose the key, which is the unique identifier that identifies a core, anyone can get its facade and manipulate it.”

    Could you expand? Do you mean you don’t want to expose the Facade of a Core outside of the Core? What would be the harm in accessing a Core’s Facade?

    Thanks, sd

  31. Chandima Cumaranatunge
    April 5, 2010 at 6:46 am | #34

    Hello @sideDoor,

    Stephen Downs raised the same issue in a previous comment. My response here:

    http://www.as3dp.com/2009/07/22/a-non-flex-actionscript-example-of-a-puremvc-multicore-application/#comment-3018

  32. Maki
    April 13, 2010 at 4:08 am | #35

    Hi Chandima,

    Thanks for a great article.

    It would be interesting to see your response to Andrew Strader’s comment on September 4, 2009 at 1:07 pm

    Thanks,

    Maki

  33. Chandima Cumaranatunge
    April 13, 2010 at 7:47 am | #36

    Hi Maki, My response is a couple of comments below Andrew’s. I do share his dislike for Pipes. Cliff Hall is currently working on a new modular architecture based on PureMVC. I think it’s still in alpha.

  34. Maki
    April 13, 2010 at 11:46 am | #37

    That sounds really interesting. Would you happen to have a link?

    Cheers,

    Maki

  35. Chandima Cumaranatunge
    April 13, 2010 at 2:31 pm | #38

    @Maki, I haven’t seen it myself, but it’s a modular client platform called “Imagn” – You can sign up for a beta when it becomes available.

    http://futurescale.com/v3/company/contact-us

  36. Michael
    November 10, 2011 at 12:23 am | #39

    Hi Chandima,

    First of all, i recently started learning and doing a puremvc standard version for a flash project.

    After reading through this article, i knew i had to use the multicore version. Thanks for this wonderful and simple demo(+1 its not flex).

    Btw, i enjoyed reading your book as3 design patterns. Haven’t finished it though.

    Best regards,
    Michael

    • Chandima Cumaranatunge
      November 10, 2011 at 7:05 am | #40

      Hi Michael, I’m glad the article demonstrated why the multicore version is what everyone should be using for pmvc projects. Thanks for the note and good luck on your projects.

  1. January 15, 2010 at 4:56 pm | #1
  2. January 22, 2010 at 10:22 am | #2
  3. March 3, 2010 at 11:33 am | #3
  4. June 17, 2010 at 10:57 am | #4
  5. June 23, 2010 at 10:08 am | #5

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>