I am currious what whould be the performance impact of removing listeners in the onUnload method instead of leaving them there (assuming we don't create memory leaks). I mean: in my case I have a left menu that shows screens on the right side. These screens are a bit complex and contains much logic that is contained in the presenter following the MVP pattern. Once the display is created I leave it created and the user merely swiches screens when going to another screen. I don't remove any (local) listeners when switching screens, but could do that and I am currious if removing (deactivating) about 10 listeners would result in a better performance. I mean: suppose I have 20 menu items, with about 10 listeners, I would have 200 listeners (own and direct gwt listeners). But when I remove them, I would never have more then around 10 listeners active as the others are removed when the screen isn't visible.
The only thing is that, like mentioned above, I have to inform my presenter about the onUnload event, and often more fine-grained components that contain the listener (that are connected to the presenter). This isn't always very elegant I think. Talking about the event bus. I use a MVC implementation which is similar to the one used by mygwt (when it was still called mygwt), for the course grain events, like start app, load app data, init app, etc. And use the MVP for the fine (local) grain events. This seems to work fine in my case. Example: I have about 10 course grain controllers like ControllerMenu, ControllerHeader, etc... These will contain their own child controllers that are well controlled by their parent. The controllers are connected through a super Controller class to an event dispatcher (the event bus). The controller will register the interested events and get informed when the event happens (example: app init, load app data). The dispatcher will wait dispatching events when needed like when data is loaded from the server (kind of the Handler Manager has an intern queue to overcome concurrent access problems). The controller always has at least one View implementation class that is responsible of creating the screen. The controller will forward his event to his View when needed. Just a brief overview how I use the "event bus" system. I am not so crazy about a global handlermanager as event bus as it's very sensitive to memory leaks as we don't have weak references in javascript. I also have a global model that contains some global data, like member/ partner name, etc... But I don't permit any listener subscription to this data. I had this in the past, but it's too tricky and if a developer forget to clean up his listener you have a memory leak (like mentioned above). I "solved" this by pushing a Global data change event on my event bus to the controller that are interested in this event. The controller will push it to the view and then the view can do whatever he want and have his own listeners if he wants. This works in my case, as: I have a fixed number of controllers so the number of "global listeners" can't grow. Note that memory leaks can still exists, but then only in a local view, such that the damage is much less severe. Also because I am planning to remove the complete view in the future when too many views exists I won't the problem at all. I mean: the view will automatically be created if it doesn't exist. Just sharing my experience..... Ed --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
