Multi-page Flash apps without MultiCore?

[jlahr]

I'm working a Flash project with a half dozen or so different screens. My understanding based on posts in this forum is that any project that requires loading multiple SWFs is a good candidate for MultiCore.

Since I'm new to PureMVC in generally and want to avoid the added complexity of MultiCore, I'm curious if people have been able to implement complex, multi-page Flash movies without it. I'm assuming that if I can't load external SWFs without MultiCore the only other option is to store each page as it's own MovieClip and load them dynamically. If that's true, am I correct in assuming that these clips will all have to load when the app is open and there's no way to load a MovieClip on demand?

If anybody has solutions that have worked for them, I'd love to hear them.

Thanks.

[dihardja]

I had a multiple swf flash project with the puremvc standard version once. Although the multicore looks a bit more complex than the standard version, you will figure out that during the development (especially if more than one developer is involved) the multicore version is definitely the preferred one.

The progress of using the standard version for a multiple swf flash project could be like this.

1) You have a main.swf ( the container where the pages are loaded into )
2) Each page ( the swfs which will be loaded into the main.swf ) are only views which doesnt implement any business logic at all and are also not linked to any class.
3) After an swf is loaded into the main.swf, execute a command and pass the loaded swf as a view component
4) This command then handles the business logic for the given view.

The disadvantage of using the standard version for a multiple swf flash project is that the whole project is then one huge module which can not be divided. 
     

[puremvc]

Since I'm new to PureMVC in generally and want to avoid the added complexity of MultiCore

This is a misconception. MultiCore is no more complex than Standard, it simply allows for multiple sets of the Model, View, Controller and Facade to exist, so that each loaded swf/module ('core') can have its own insulated startup process and so forth. Each core looks like a standard PureMVC app.

Any project that loads multiple swfs/modules will inherently be slightly more complex. Whether you use PureMVC or not, you still have to figure out how the modules will communicate with each other.

And you still have any number of possible architectures with the parent swf (the 'shell') directly puppeteering the children being the most common brute force approach. That leads to a lot of communication burden being placed on the parent.

With MultiCore, you also have a 'take it or leave it' option for combating this problem; the Pipes utility. With Pipes, you usually end up replacing the shell's communication burden with plumbing burden, but in the end you can reach some of those other architectures where the loaded modules communicate with each other in a loosely coupled way; exchanging messages rather than knowing each other's internals or implementing interfaces and giving them references to each other.

Again, whether you're using PureMVC or not, once you begin developing an application that loads multiple swfs/modules and sets them up to communicate amongst themselves, you are making the parent less involved in module to module communication, but you are shouldering a new burden of creating interface and/or message protocols for the modules to communicate with each other.

So from the standpoint of approaching a modular project of any sort, it's easy to see how MultiCore (and optionally Pipes) might seem more complex. Because the reasons for using it are more complex. MultiCore enables modular development without adding a lot of baggage. You can't help the new level of concerns that modular development intrinsically brings with it.

-=Cliff>