Thanks Pedro,
I've seen what your describing in the docs - I'm looking at this via the
profiler which is giving me feedback as to number of live instances,
etc.
Here's what I'm basing my statements on:.
1) I start up my app, which loads modules at runtime based upon user
choice from a menu.
2) Module exectues Cairngorm Event/Command/Delegate to get array to
populate a combo box. I'm passing a reference to the module's model in
my Cairngorm event and the model is updated upon completion of the
Command.
3) Combobox is bound (via MXML) to the model.
4) If I don't interact with the combobox, I can then logout and unload
the module successfully. The profiler tells me there was previously 1
instance of the module and now there are zero instances.
5) If I make the combobox active (by interacting with it in any way),
and then logout, the module remains in memory, with the profiler
reporting one instance instead of zero.
6) If I then login again, the Profiler reports 2 active instances of the
module. Note that any model objects are duplicated as well. For
example, if my list of suppliers (used to popuate my combobox) (a
strongly typed AS class) was previously 64, the profiler now reports
there are 128 instances.
There's my behavior. When my UI object (in this case ComboBox), becomes
active, the binding becomes active and then the module will not unload,
even if I set the modules model to null before attempting to unload. It
would appear that I need to invalidate all outstanding bindings to any
data object before the module will fully unload. This would seem to
indicate that MXML binding (via curly braces) isn't going to allow this.
Jeff
-----Original Message-----
From: flexcoders@yahoogroups.com
[mailto:flexcod...@yahoogroups.com] On Behalf Of Pedro Sena
Sent: Thursday, April 23, 2009 8:43 AM
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] Unloading Modules - Binding is the
Enemy?
Jeff,
Calling GC programmatically does not mean that it will be
executed.
Like java, the GC in flex is not under programmer's control. You
may call it, but it won't be executed if it is not necessary.
"Clicking the Run Garbage Collector button does not guarantee
that all objects that are eligible for garbage collection will be
garbage collected. Garbage collection is typically triggered by the
allocation of memory for new resources."
http://livedocs.adobe.com/flex/3/html/help.html?content=profiler_6.html
Regards,
Pedro Sena
On Thu, Apr 23, 2009 at 9:34 AM, Battershall, Jeff
<jeff.battersh...@dowjones.com> wrote:
Pedro,
I've been running the GC immediately after unload -
programmatically. The module instance is released immediately if
binding is inactive. The moment binding becomes active to a UI element
of the Module, the instance will not be released. I was thinking that
having the model object I'm binding to be local to the module would
address the behavior, but sadly it does not appear to work.
Jeff
-----Original Message-----
From: flexcoders@yahoogroups.com
[mailto:flexcod...@yahoogroups.com] On Behalf Of Pedro Sena
Sent: Thursday, April 23, 2009 8:26 AM
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] Unloading Modules -
Binding is the Enemy?
Hi Jeff,
The fact that you unload a module does not mean
that it will be garbage collected(the memory won't be released as soon
as you unload your module). Unload the module makes it available for
garbage collection.
As far as I know, the module 'garbage' will be
collected by the GC when necessary, so don't think that unload a module
means free memory in the exactly same moment.
I'm supposing that you are testing in your
development machine(probably a good machine) so I suggest you to test it
in a limited machine to see if this memory is released when it is
necessary , that is the point.
HTH,
Pedro Sena
On Thu, Apr 23, 2009 at 9:09 AM, Battershall,
Jeff <jeff.battersh...@dowjones.com> wrote:
In testing via the Profiler, binding UI
objects in a module to a model
(even if local to the module) appears to
be causing a module's failure
to unload. This happens as soon as the
UI component becomes active. In
fact, even if the source object (data
provider) is set to null, the
binding persists and will prevent a
module from unloading. Does this
issue have to be such a PITA? It appears
that using curly braces for
binding in MXML can create Modules that
won't unload.
In FP 10, the Loader class has the new
unloadAndStop() method. Would be
extremely handy to have something
similar for Modules. Basically you
want to remove all listeners to a model
and then unload the module.
Seeking enlightenment - anyone got any?
Jeff Battershall
Application Architect
Dow Jones Indexes
jeff.battersh...@dowjones.com
<mailto:jeff.battershall%40dowjones.com>
(609) 520-5637 (p)
(484) 477-9900 (c)
--
/**
* Pedro Sena
* Systems Architect
* Sun Certified Java Programmer
* Sun Certified Web Component Developer
*/
--
/**
* Pedro Sena
* Systems Architect
* Sun Certified Java Programmer
* Sun Certified Web Component Developer
*/
