On Wednesday, March 30, 2011 7:58:43 PM UTC+2, pete wrote:
>
> Hallo,
>
> I'm not sure how GWT handles this, so I want to evaluate a short
> example scenario for memory leaks. Suppose I write my own handler
>
> public Interface BlubbHandler {
> void onBlubb(BlubbEvent event);
> }
>
> have my presenter
>
> public class MyPresenter {
> private final MyView view;
> private final StringContainer justToBeFinal;
>
> @Inject
> public MyPresenter(MyView view) {
> this.view = view;
> view.addBlubbHandler(new BlubbHandler(){
> justToBeFinal.setText("BLUBB");
> });
> }
> }
>
> and now my Widget is disposed. Will the memory it uses ever be freed?
> Or does the reference to view prevent view from being disposed,
Yes.
> and
> the reference of view's BlubbHandler to justToBeFinal prevent
> MyPresenter to be disposed?
>
It depends how the view keeps a reference to the BlubbHandler (or rather *
who* keeps a reference to it).
Having A keeping a reference on B, and B a reference on A doesn't
(necessarily) create a memory leak: both will be reclaimed when there's no
longer any reference to any of them.
> I'm not even sure, how it would be in Java, but I think in Java this
> would cause a memory leak, wouldn't it?
> So do I have to add a dispose() method to pesenter, that must be
> called to null out the BlubbHandlers of view?
> And how is this handled with GWT's own event system? Or with event
> systems constructed on top of GWTs own one, using SimpleEventBus and
> extending / implementing GWT's classes?
>
As I said above, it depends *who* keeps a reference on the handlers, and its
lifetime. If you're using a HandlerManager (or EventBus) that has the same
lifetime as the view, then you've just changed the A->B->A above to
A->B->C->A, but it's still OK.
> Anyone who is more versatile in these matters and can help me would be
> very appreciated :-) I don't want to find out after lines and lines of
> code, that I'm memory leaking like stupid...
Given that anything related to the DOM is quite heavyweight and slow, it
could be a good idea to keep some views around as singletons (instead of
building a new one each time). Presenters are on the other hand generally
lightweight objects, so having them short-lived makes them easier to code
(as you don't have to reset their internal state each time they're reused).
That means it's good practice to include "dispose" methods in presenters to
"detach" from the view, thus preventing memory leaks (if you create 10
presenters for a single view, and never "detach" them, you'll still have all
10 in memory *and* listening to events *and* probably trying to update the
shared view all at once; bad for memory usage, bad for performance, and
highly error prone!)
As Jambi suggested, GWT 2.1 Activities makes it easy, as an activity's
lifecycle is clearly define: it starts (time where you "attach" to the view)
and then either is cancelled (before it has finished
asynchronously-starting) or is later stopped (time to "detach" from the
view).
In the end, it all depends how you manage the lifecycle and lifetime of your
objects.
--
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.
