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: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Alex Harui Sent: Monday, April 27, 2009 1:39 PM To: flexcoders@yahoogroups.com 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 <http://blogs.adobe.com/aharui> From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Battershall, Jeff Sent: Monday, April 27, 2009 6:43 AM To: flexcoders@yahoogroups.com 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: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Alex Harui Sent: Friday, April 24, 2009 5:43 PM To: flexcoders@yahoogroups.com 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: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Battershall, Jeff Sent: Friday, April 24, 2009 11:57 AM To: flexcoders@yahoogroups.com 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: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Battershall, Jeff Sent: Thursday, April 23, 2009 10:13 AM To: flexcoders@yahoogroups.com 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: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Gregor Kiddie Sent: Thursday, April 23, 2009 9:40 AM To: flexcoders@yahoogroups.com 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 <blocked::http://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 is.helpd...@inps.co.uk ________________________________ From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Battershall, Jeff Sent: 23 April 2009 14:32 To: flexcoders@yahoogroups.com 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
