Disposable activities

[koma]

Hi,

In the new Places/Activities paradigm, Activities are disposable objects that are constructed just-in-time when they are needed. 

Views are long lived because DOM manipulations are expensive in terms of performance of your app, as per the docs.

So Activities don't keep state and Views do.

My problem :

If an Activity is making a lot of expensive server calls to fill select boxes and more and it uses this information to configure its View. 

The user acts on the view and selections and text values change. This is communicated with its Activity (Presenter).

Next the user moves to a Place without this Activity/View pair present.

When later the users navigates to a place where the given Activity is present again, the changes made to the view are still present, but the Activity is a fresh copy without state.

Now I can take several roads to sync state of my Activity :

1- re-initiliaze the Activity, making all the calls again and then syncing with the View state.

2- try to reconstruct the data based on the state of the view

3- Use static functions on the Activity to keep state of appearances

4- Use a helper/singleton Manager object to keep state, which is initialized with requestfactory and clientfactory at application startup.

Each option has disadvantages ;

1- make the expensive calls again, still have to sync the Activitiy state with the View state.

2- this is a lot of code and the View becomes too heavy weight, holding too much logic

3- the problem here is that requestfactory and clientfactory are only passed to the Activity when the ActivityManager creates the Activity. I can only make the calls with a real instance, unless I break out of the standard pattern and pre-init the static part of the Activity.

4- this is working but the Activity ends up rather empty, most logic now shifts completely to the singleton object.

Did I miss something in working with Places / Activity / Views ?

How do you solve these issues ?

thx

Koen

 

[koma]

Another problem with disposable activities is that when sending out updates over the event bus, there is no activity to handle the event and update the view (which is hiding). 

When navigating to a place where the view shows up again, the view will be out of sync with the rest of the application because it missed some updates.

Yes, I can just minimize it to height/widht=0 and never dispose of the activity/view combination, but I feel the architecture is flawed if that is the solution.

[Thomas Broyer]

It depends whether your data is "static" or is dependent upon a "parameter" of the place/activity. If it's static, I don't see it as a problem to make your calls from the view (and rules are there to be broken ;-) ). Or you can have an "initialized" flag on the view to tell the activity/presenter whether it has to do the work or not.

What I like doing is not presuming of the lifetime of the view (whether you'll have a new view each time or a singleton, or something in between [1]).

Also, disposable activities is not always the best match for your needs. I prefer keeping a "cache" in specialized objects, but you might prefer keeping it in the activity (as you say that your activity would be almost empty without it).

It's all a matter of balancing pros and cons, and choosing the right pattern for the job; and you don't have to stick to a single pattern for your whole app (for instance, we have one activity –among a hundred– that's not really disposable: if the current place is of the same kind of the previous one, we'll reuse the same activity rather than creating a new one).

[1] I'm thinking about caching views for a few minutes (or place changes) before disposing them, so that when, say, you switch back and forth between a list (master) and detail activities, you reuse the view; but if you don't use it for a while, then it's better to dispose it to free some memory.

[tanteanni]

this thread helped me much with this problem.
there are two approaches to keep activities alive. the "official" way made me  headache but it works: Thomas said "...if the current place is of the same kind of the previous one.." that means overriding equals() of that place (not the activity) and caching the activity in a CachedActivityFilter. To reroute the the place (you go to contentplace but you also want to menu place to display the cached menu) you also need FilteredActivityMapper. (good example for that).
but i think jens proposed a much simpler way (and i can't see any disadvantages about it?): Store the activity to be cached in activity mapper and return "lastActivity" instead of new one.

i have to admit that i am also not very happy about disposable activities by default

[koma]

Thx for the comments.

I guess pragmatism is the rule that you never break :-)

For now, I turned one of  the Activties/presenters into a singleton, so no longer disposable. 

This presenter works with the main view of the app and would be (almost) always present anyway.

Since it is never disponsed, of, this presenter never misses any of the events it is subscribed for.

It takes me one extra call to "init" this activity. The activity mgr returns MainActvity.getInstance() when necessary.

[Karthik Reddy]

@Thomas

".......................then it's better to dispose it to free some memory."  

I guess, this means, explicitly invoking "removeFromParent()"  on the view class.

Do you agree with my statement??? 

[Jens]

You do not have to call removeFromParent() yourself. As soon as a new activity gets active the view from the last activity will be removed from the display area (<displayarea>.setWidget(null) is automatically called before the new activity will be started). So if you cache views for a while, you just have to remove it from your cache, e.g. removing all references to it, so it can be garbage collected by the browser.