AbstractActivity handling and start

[pansen]

hey,

I'm asking you guys for a best practice. Imagine the following case:

- there is a class ``UserProfileActivity`` where you as user see your
profile
- you switch from your profile to another persons one, this causes the
class ``UserProfileActivity`` to be used again
- ``UserProfileActivity`` won't get a call to ``start`` again, cause
the ActivityManager knows this is the same instance again. But it
needs a notification to reload its data for another user...

Problem: for the ``ActivityManager`` this is the same thing, for the
user/context/content its not.

I see two solutions so far, but I'm not that much convinced of any.
Maybe there is one much better ;)

- any activity must be handled as a unique instance - no singletons
- we apply a custom interface that triggers some kind of
``reloadData`` method.

Anyone has two cents left ;)

andi

[Thomas Broyer]

I prefer the "no singleton" approach, because you don't have to clear state between calls of the activity, but there are alternatives:

• have your activity listen to PlaceChangeEvent
• have your ActivityMapper update the activity before returning it (this is the approach used in the Expenses sample app from the GWT SDK)

[Jens]

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).

[pansen]

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