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
