ok, thanks for your responses. usually we don't have the activities bound as singleton explicitly, but as we saw now, they're injected into the ``MasterPanelAcitivityMapper`` via constructor arguments, which makes it de-facto to singletons ;)
we also thought about inheriting ``AbstractActivity`` and implement some ``reload`` method via ``PlaceChangeEvent.Handler``, but I don't like to build stuff that is usually not GWT managed. so I think we'll try building activityproviders and see how this works without singleton behavior. best, andi On 13 Jul., 16:06, Jens <jens.nehlme...@gmail.com> wrote: > In general its better to not use singleton activities because the browser > can not garbage collect them if they are not needed anymore (not active) and > you always have clean new instances. So I would change the > UserProfileActivity to a non singleton. > > If you really do not want that (maybe the UserProfileActivity loads a large > number of static data that you do not want to reload every time a user > navigates between user profiles) then you have to define a method like > setPlace(newPlace) and call it in your ActivityMapper before returning your > singleton/cached instance. Alternatively you can implement > PlaceChangeHandler in your activity and listen for UserProfilePlace changes > and then update the internal state of the activity. > > Personally I implement PlaceChangeHandler because its more like an "opt-in" > approach (If you have not many singleton/cached 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 google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
