Yay! That's the class I needed! :) To answer your question why. First I like to use MXML. Any tool can parse XML. Plus, with this class, I plan to drop it into all my future project and set properties on it. If I had more than one instance it would screw up the application. Other classes use some of its functionality so I am providing a getInstance(). The problem has been that the other classes may be declared before the MXML instance. So I updated my code to always call the getInstance() method and both problems have been solved!!!
On Sat, Jan 10, 2009 at 12:38 AM, Haykel BEN JEMIA <[email protected]>wrote: > You should probably implement the IMXMLObject interface. Override the > initialized method where you can set the class instance (to 'this'). > > The getInstance() method can create a default class instance if it's null > and return it. > > Don't save references to the class instance in the classes that need to use > it. Instead always call getInstance(). This way, until the MXML singleton is > initialized, a 'default' singleton will be used. Afterwards, the MXML > instance will be used. > > This said, why do you need the singleton to be MXML? > > Haykel Ben Jemia > > Allmas > Web & RIA Development > http://www.allmas-tn.com > > > > > > On Sat, Jan 10, 2009 at 5:47 AM, dorkie dork from dorktown < > [email protected]> wrote: > >> I'm stumped. I'm trying to create a singleton class that is also an >> MXML class. >> >> <managers:SingletonClass /> creates one instance obviously. But another >> class needs to reference this class. So class 2 calls >> SingletonClass.getInstance(). It's possible that class 2 will be created >> before the MXML SingletonClass instance. >> >> It's ok for me if there is a ghost instance as long as everything works >> like it should. As long as the instance that is in the main MXML file is the >> one thats in effect. >> >> Also, when debugging this, the id is always an empty string. I'm extending >> EventDispatcher. >> >> dorkie dork from singleton-town place >> > > >
