I don’t think of modules as “app in an app”. Modules are intended to have some known dependencies on the loading environment, more like DLL’s in Windows. Sub-apps are intended to be stand-alone and hence is the unit for cross-versioning.
The primary goal of modules is to move code out of a SWF into other SWFs in order to affect download time. It also has advantages in multi-person teams and large projects by not requiring full re-builds for certain changes, but that won’t affect the user experience. Because it is all about download time, and AIR doesn’t really have download time, then there is little user advantage to separating an AIR app into multiple SWFs. However, proper use of modules encourage good encapsulation and that does have a potential benefit to the startup time of your app. That’s because AS classes are still “functions” and not pre-layed-out in memory like many other executable formats. Here’s an example: Suppose there is a component Foo: Class Foo { private var something:Bar; public function someFunction():String { } } The very first time Foo is used in the app, both Foo and Bar are initialized (all static variables that are not initialized to compile-time values are setup). So, let’s say Bar looks like this: Class Bar { private static table:Object = { name: “Alex”}; private static names:Array = [ “Jeffry”, “Alex” ]; } And further, suppose your app just looks like this: <Application> <states> <State name=”login” /> <State name=”normal” /> <states> <LoginDialog includeIn=”login” /> <Foo id=”foo” includeIn=”normal” /> <Application> As you can see, Foo is not needed and won’t be instantiated until after the login dialog does its thing. However, at startup time, the VM’s verifer will need to verify that Foo exists because “foo” is a property on the Application. This will cause Bar to be verified, which will cause the table object to be created and the names array to be created. None of that will show up as a hot spot in the profiler, but you did waste cycles calling: Foo$cinit() { Bar$cinit(); } Bar$cinit() { table = { name: “Alex”}; names = [ “Jeffry”, “Alex”]; } Eventually, that might add up to something. On the other hand, if you use a module, and use an interface that doesn’t mention Bar, you will save those cycles at startup. Like I said, it usually doesn’t add up to much, but something to keep an eye on, especially if there are large static data tables. On 6/21/10 4:56 AM, "Jeffry Houser" <jef...@dot-com-it.com> wrote: Components and Modules are two different things for very different purposes. I do not believe it is an "either or" situation. Module are usually designed to be an app in an app; basically a self contained complete set of functionality. Where as components are designed to be flexible units focused on a single task; and [in theory] optimized for reuse across multiple projects. On 6/21/2010 7:46 AM, Wally Kolcz wrote: In the beginning of my Flex web development I used components to separate different functionality of my web applications. Being acutely aware of load time and different user bandwidths, I switched to now develop my applications in modules. This has made my web applications load faster. Now I am developing 2 pieces of software using AIR and not sure which approach is better. One I started with the same approach using modules, but now that its time to work on the other I am curious if there are any glaring benefits to developing in Modules with AIR. Load time seems relatively short since its using the computers processing power. My apps are certainly faster loading than Adobe's ;). Application install size is not really a factor since none of software application are remarkably huge. It seems a lot easier for me (and much much lazier) to just take each sub application, put it into a Group component and use a viewstack to move around the application rather then loading and unloading separate modules. Now that I am getting into more custom software development, I would love some advice from the experts here on this 'best practice'....Modules or Components. Thanks! -- Alex Harui Flex SDK Team Adobe System, Inc. http://blogs.adobe.com/aharui