1 Reply Latest reply on Nov 16, 2009 2:38 PM by Flex harUI

    Help removing a singleton from a dynamically loaded component.

    chrisisme

      Coming from an Object-C background where memory management is all done manually, getting used to Flex's memory handling and garbage collection has been a real chore. I have a long way to go, and a lot to learn.

       

      For now though I have a problem that I need some guidance with. We have a Flex and Air application that utilizes several other complex custom Flex components or mini apps. The main application is really more of a wrapper for all these other content items. Many of these sub items use a singleton (Application Controller) design pattern. In several cases I may reuse one of these sub components several times just changing it data provider. The problem is, even though I remove the subcomponent and any event listeners from the wrapper, the singleton never seems to get dealloced. So the next time the wrapper app loads the component, the old singleton is still laying around. Who owns it? My understanding was that the first object that gets a singleton instance owns that singleton, but now it seems the application (the wrapper) may be the one in control. The problem is the wrapper is dynamically loading these objects from a library and knows nothing about them or their controllers. The application only needs to pass them data provider strings.

       

      So, all of that to ask, what am I missing here. The wrapper is loading these MXML/AS components, using them, nulling them and removing them, but their singletons are sticking around. Any ideas?

        • 1. Re: Help removing a singleton from a dynamically loaded component.
          Flex harUI Adobe Employee

          If you haven't already, skim through the Modules and Marshall Plan presentations on my blog.  The presentations should have some diagrams that will help you understand applicationDomains.

           

          There is a class in Flex called "Singleton".  If code uses that to register singletons or there is similar code using similar techniques, then it is easy to get "first-in-wins" situations that you can't get out of because Singleton is in the main app's ApplicationDomain and, because it has a write-once registration policy, you can't "unregister".

           

          Even if you could unregister, you could run into other problems because it isn't just a matter of the few classes that act as singletons, all the other classes they use are also factors, so the usual recommendation is to load Singletons and their related classes into the main ApplicationDomain and don't attempt to unload them.  How to do that is described on my blog as the "shared code" module.

           

          Another option available is to "sandbox" the sub-applications using the various techniques described in the Marshall Plan.  It is less efficient, but better abstracted.

           

          Alex Harui

          Flex SDK Developer

          Adobe Systems Inc.

          Blog: http://blogs.adobe.com/aharui