Thursday, February 23, 2012

Re: Using non disposable activities extracting parameters from a place

Thank you Thomas!

I ended up doing something similar to what you say, moving GIN
injected dependencies into my ActivityMapper and using them to build a
new Activity (I'll switch to a provider as soon as possible).
I actually ended up subclassing ActivityManager (and extending
Activity itself) to provide a different switching behavior, since I
had some needs for optimization.
Maybe I'll go back to the default as I clean up my own code using the
Places/Activity architecture (I'm on an hand-made MVP, with no place
tight behavior, by now).

Thanks very much for your collaboration (and of course for your blog
posts on the whole framework, I found them way clearer than the
official documentation on this matter).

Regards
Lorenzo

On Feb 23, 3:15 pm, Thomas Broyer <t.bro...@gmail.com> wrote:
> On Thursday, February 23, 2012 1:22:38 PM UTC+1, l.denardo wrote:
>
> > My problem is that the two activities are actually singletons (not-
> > disposable), since they have different dependencies injected through
> > GIN.
>
> If this is the only reason, then it's not a good reason. It's too easy to
> not use singletons with GIN to not take advantage of it: replace your
> dependency on CalendarActivity to a dependency on
> Provider<CalendarActivity> in your ActivityMapper (same for
> ResourceActivity) and you're done, and you'd have eliminated your issue at
> the same time.
>
> I wonder what is the best way to have a correct state change when
>
> > place chages occur.
> > *Build a GIN provider or the like for activities and have a different
> > Activity object returned each time
>
> Definitely (unless you have a good reason to do otherwise)
>
> > *Do the "new object" loading immediately when the ActivityMapper calls
> > the setter instead of the start(...) method
> > *Any other way?
>
> Tracker whether the activity is started or not (as I said on some other
> similar thread in the past few weeks, this is something you should already
> be doing anyway IMO) to determine what to do when the setter is called:
> either wait for the activity to be started, or start loading the data right
> away if the activity is already "live and running".

--
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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

No comments:

Post a Comment