Hi Thomas, Yes, that would explain it and thank you very much for your input.
About life cycle management, most of the classes in question are created anonymously as in my original example with the FluidTmpltDeletedGWTEvent.Handler. I guess I could keep a reference to the returned EventHandler in the enclosing class and prior to assignment to it check if the reference variable contains a valid reference (non null) and call removeHandler if it does. The funny thing is I hardly ever see life cycle management in JavaScript code, at least from my experience anyway, so I guess i just perpetuated a bad practice. My bad :) I started developing my latest application prior to the release of GWT's native MVP implementation. When 2.1 was released I thought about refactoring the application to use the native MVP noting that it held numerous benefits but I hesitated and still do because GWT's native MVP implementation didn't support DAOs (I am using Objectify) and it appeared to be a work in progress both in terms of the framework itself and its documentation which I regrettably think is quite bad. I also believe that sometimes applications benefit more from tight coupling of some of their components making for an all around leaner application though obviously in general loose coupling should be the overall goal. At some point I will probably bight the bullet and move to MVP but not until I sense a little more maturity in the native implementation provided by GWT and a better documentation set to go along with it. Thanks again for shedding some light on and answering my question. Jeff On Tue, Dec 21, 2010 at 4:07 AM, Thomas Broyer <[email protected]> wrote: > Actually, because the EventHandler has a reference to the class that > created it (in most cases, and it's true in your case), then as long as it > is referenced by the EventBus, it won't be garbage collected, and neither > will be its "owner" class. There's no "dead event handler", only things that > you no longer use but haven't destroyed, so they're still there, listening > and handling events, without anyone to notice it (because your code no > longer has any reference on them). > You really should clean after yourself; onLoad/onUnload on widgets might be > a solution; but having a real lifecycle for your classes would be best (this > is where MVP shines through, e.g. the start/onCancel/onStop methods of > activities) > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-web-toolkit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > -- *Jeff Schwartz* -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
