Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: how to compile a modular (multicore) iOS AIR app  (Read 9308 times)
asinning
Newbie
*
Posts: 2


View Profile Email
« on: April 20, 2012, 11:39:07 »

Is a multicore architected application necessarily divided into multiple swfs?  If so, is there a way to compile it into a single AIR app for conversion to iOS?

Thanks!
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: April 20, 2012, 12:37:38 »

No, it does not have to be multiple swfs.

If you check out the Modularity and PipeWorks demos, all the modules are defined and compiled into a single swf. There it is done for convenience; having a demo composed of multiple projects would be a pain for developers to try out.

Each module is scoped to its own namespace, so if you wanted to separate them into multiple projects, you could easily do so. From there they could be rendered into separate swfs and then loaded dynamically by the host app, OR, you could create library projects and then compile them into the main application and instantiate them directly.

Some have thought these demos defeated the purpose of making modules because they aren't loaded dynamically. But in the case of iOS, although I haven't tried it yet, I don't believe you can load modules and run them in iOS. You can load a timeline-only swf and play it, but no code. Make sense if Apple controls the code you submit to the store, if they let you dynamically load and run modules, then effectively, you could slide in unapproved executable content that way.

So in some cases, you want the benefits of a modular app, from the standpoint that each module has its own PureMVC core and State Machine, can be managed as a separate project, and can still be treated as one big program.
« Last Edit: April 20, 2012, 12:47:34 by puremvc » Logged
asinning
Newbie
*
Posts: 2


View Profile Email
« Reply #2 on: April 22, 2012, 10:05:49 »

Thanks for the feedback and for pointing me to the Modularity and PipeWorks demos!

My first multicore project will most likely use Flash, not Flex, but the example is still very helpful.  Since making my initial post I was actually successful in creating a multicore test using a class as my second core.  So far it seems to be working.  The next step will be to hook up some pipes.

I have a question about namespaces.  Looking at the Modularity project, I see that the widgets are constructed using widgetmakers:CoolWidget and widgetworks:SuperWidget however, its not clear to me how having the modules scoped to their own namespaces comes into play?  If possible, could you give an example or point me to a place in the Modularity project where having a unique namespace is beneficial?

Thanks!
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: April 23, 2012, 07:57:05 »

I have a question about namespaces.  Looking at the Modularity project, I see that the widgets are constructed using "widgetmakers:CoolWidget" and "widgetworks:SuperWidget"; however, it's not clear to me how having the modules scoped to their own namespaces comes into play?  If possible, could you give an example or point me to a place in the Modularity project where having a unique namespace is beneficial?

The namespacing was used to distinguish them clearly from the rest of the code in the project since they are not built separately and dynamically loaded. The namespaces also illustrate the fact that these modules *could* even come from a third party library. Imagine you have a modular synthesizer environment, and you want to provide the ability for third party developers to create instruments and filters to expand your platform. A Native Instruments filter module would likely be shipped as something like: com.nativeinstruments.filters.distortion.*

Also, here's some more source code you can have a look at:
http://seaofarrows.com/srcview/
Logged
Pages: [1]
Print