Would be really helpful a removeAllEventListenerss() on event EventDispacher.... Or even a dispose() method on UIComponent class that remove listeners, clean references, and whatever else is necessary to clean memory.....
VELO On Mon, Apr 27, 2009 at 3:36 PM, Battershall, Jeff < [email protected]> wrote: > > > Thanks Alex, very much. The main app is only handling login/logout > duties and the event-command-delegate classes to do so. I moved away from > ModelLocator in the concern that it, being a singleton, may be keeping a > reference to UI objects that are using ModelLocator objects as dataProviders > and thus prevent a clean unload. After all, by definition, a singleton is > going to persist after a module is unloaded, true? Maybe I was wrong about > that, but I'll tell you, I was trying everything to get that module to > unload. Everyone was a suspect. Bear with me while I try to get my wits > around this stuff. What I'm doing how is keeping all my models local to the > module that uses them and injecting data via command and delegate classes. > This seems to work ok. > > As far as PopUps, I'm calling removePopUp() and also removing listeners to > custom events I've defined in the popup. > > I'm also seeing some behavior where the module will remain in memory after > unloading (as reported by the profiler) until I create a new instance of > that particular module class and populate the dataProvider of one of its > children. The holy grail of a 100% clean module load/unload has not been > attained, but I believe I'm getting closer. > > Jeff > > -----Original Message----- > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Alex Harui > *Sent:* Monday, April 27, 2009 1:39 PM > *To:* [email protected] > *Subject:* RE: [flexcoders] Unloading Modules - Binding is the Enemy? > > Every time I’ve debugged a suspected Binding leak, I’ve found that it > sets up weak references in the right places and the problem was always > somewhere else. However, I wouldn’t bet against there being a scenario out > there that does leak. We’re looking at other module unloading scenarios > right now so I’d still be willing to look at a simple test case. > > > > IMHO, the main app should “never” reference the model. If you have a model > Singleton, the module can bind to the singleton. IMHO, that’s a better > model/view design anyway. I would expect all popups related to the module > to be removed in order for the module to unload. > > > > One aspect of the modules design is that it does not require an unload() > command. The design was that you would load a module and generate an > instance (or several) of the module’s classes and once you’ve cleaned up all > references to those instances, the module would go away in a future gc > pass. That way, you wouldn’t have to track instances and know when it is > time to call unload(). In order to implement such a design, the module SWF > is given an unload() call right away so that its generated instances are > supposedly the only remaining references to the modules classes thus > preventing garbage-collection. Given the current design, I don’t think we > can ever substitute unloadAndStop() for that unload call. Also, no testing > has been done by the Flex team as to what impact unloadAndStop will have in > ActionScript if references to objects suddenly become invalid. IMHO, > unloadAndStop should only be used when there are well-defined boundaries > such as around a sub-application since sub-apps tend to be more > self-sufficient. Modules are much more tightly integrated with the main > application. > > > > However, Modules or no Modules, we realize that debugging memory leaks is > hard work. The Gumbo profiler has a new backreference display that > eliminates most extraneous backreferences, and we welcome any other ideas > for tools and techniques for finding leaks. > > > > Alex Harui > > Flex SDK Developer > > Adobe Systems Inc. <http://www.adobe.com/> > > Blog: http://blogs.adobe.com/aharui > > > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Battershall, Jeff > *Sent:* Monday, April 27, 2009 6:43 AM > *To:* [email protected] > *Subject:* RE: [flexcoders] Unloading Modules - Binding is the Enemy? > > > > > > > Alex, I was using 3.2 - an oversight on my part - I upgraded to 3.3 and > it does seem to help but I'm also calling focusManager.deactivate() as > well. Since that, the combobox isn't an issue. > > > > However there any number of different things I was doing that were causing > problems - like binding myModule.currentState to a model. One of the > challenges is injecting model data into the module that doesn't create a > refererence to the module anywhere. PopUpManager seems to be problematic if > the popup contains strong refereneces to the module or its associated model. > > > > > I am making progress and what I'm hoping for in the end is a definitive set > of best practices concerning the use of modules. Hopefully some of these > issues might be made easier with somehting like loader.unloadAndStop() but > for modules. > > > > Jeff > > -----Original Message----- > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Alex Harui > *Sent:* Friday, April 24, 2009 5:43 PM > *To:* [email protected] > *Subject:* RE: [flexcoders] Unloading Modules - Binding is the Enemy? > > Jeff, which version of Flex are you using? Can you make a test case in two > 20-line mxml files? > > > > Alex Harui > > Flex SDK Developer > > Adobe Systems Inc. <http://www.adobe.com/> > > Blog: http://blogs.adobe.com/aharui > > > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Battershall, Jeff > *Sent:* Friday, April 24, 2009 11:57 AM > *To:* [email protected] > *Subject:* RE: [flexcoders] Unloading Modules - Binding is the Enemy? > > > > > > > > Gregor, > > > > It does seem to be connected to the ComboBox issue - is this in the Adobe > BugBase? It doesn't turn up in my searches. I can get the reference to > release if I navigate to another module and then logout, but if I change the > selected index of the combo box to greater than -1 before that, it will not > release no matter what I do. > > > > This is a royal PITA because my instantiation code is based upon a first > time load of the module and if I cannot unload a module then my method of > injecting model objects into my module will have to be re-done. If there's > no workaround for this bug, then Modules are effectively broken if something > as commonplace as a combobox prevents an unload. > > > > Jeff > > > > -----Original Message----- > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Battershall, Jeff > *Sent:* Thursday, April 23, 2009 10:13 AM > *To:* [email protected] > *Subject:* RE: [flexcoders] Unloading Modules - Binding is the Enemy? > > Gregor, > > > > Very interesting indeed. If I login, load the module, interact with the > combobox, logout, the instance remains in the profiler. However if I do all > that and THEN load another module and logout, the number of instances of the > first module goes to zero. These modules are being loaded into a ViewStack, > BTW. > > > > Is this the FocusManager bug you described? Is there a workaround? > > > > I'd be thrilled to discover that Binding was not the culprit here. > > > > Jeff > > -----Original Message----- > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Gregor Kiddie > *Sent:* Thursday, April 23, 2009 9:40 AM > *To:* [email protected] > *Subject:* RE: [flexcoders] Unloading Modules - Binding is the Enemy? > > It does sound like you are describing the bug where the focus manager holds > onto the reference of the combo box and stops the module unloading… > > If you lose the combobox focus, does the module unload? > > > > Gk. > > *Gregor Kiddie* > Senior Developer > *INPS* > > Tel: 01382 564343 > > Registered address: The Bread Factory, 1a Broughton Street, London SW8 3QJ > > Registered Number: 1788577 > > Registered in the UK > > Visit our Internet Web site at www.inps.co.uk > > The information in this internet email is confidential and is intended > solely for the addressee. Access, copying or re-use of information in it by > anyone else is not authorised. Any views or opinions presented are solely > those of the author and do not necessarily represent those of INPS or any of > its affiliates. If you are not the intended recipient please contact > [email protected] > ------------------------------ > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Battershall, Jeff > *Sent:* 23 April 2009 14:32 > *To:* [email protected] > *Subject:* RE: [flexcoders] Unloading Modules - Binding is the Enemy? > > > > > > > > > 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 > > >
