On Sunday, January 9, 2011 2:28:07 AM UTC+1, zixzigma wrote:
>
> > What's the point in implementing Provider yourself?
>
> is there a way to not implement the Provider myself ?
> through GIN's assisted inject ?
>
The whole idea of Provider is that Guice/GIN implement them!
You only have to "ask" for it and GIN will provide it, e.g.
@Inject
MyObject(SomeObject thisWillBeAnInitializedInstance, Provider<SomeObject>
thisWillBeAProvider) {
...
}
Then, depending on the scope you bound your type to (in GIN, limited to
singleton or not), the provider will either always return the same instance
(initializing it once the first time you call the provider's get() method)
or a new instance each time (Provider acting like a factory, without the
possibility to parameterize the object).
Assisted-inject is something else: you can define a factory interface (will
methods taking arguments) and GIN will implement them, mixing dependency
injection with the values you passed to the method.
> > The way you wrote it, yes (and it's therefore totally useless).
>
> you are correct, the way I wrote it, wouldnt defer instantiation of
> activities,
> so it is useless.
>
> however if I instead use a Factory
>
> public class MyActivityFactory implements
> AppActivityFactory<MyActivity> {
>
> MyActivity getActivity(){
>
> return new MyActivity();
> }
>
> }
>
> this way, I can defer the instantiation of MyActivity until the time
> it is actually requested.
> and I can pass in other dependencies to MyActivity from this
> MyActivityFactory.
>
But you then have to maintain the dependencies that you'd manually inject
into the activity's constructor. And to be sure you respect the scopes, you
need similar "factories" for each dependency.
You'e just re-invented the Provider.
my goal is to have a registry to hold all activities that are used in
> the application.
> to avoid early instantiation of activities.
> From your comments I realized it might be better
> to keep a map of ActivityFactories instead of Activity instances,
> so that upon request, these ActivityFactories can supply the
> appropriate Activity.
>
> I am not sure however having an ActivityFactory for each Activity, is
> a good idea,
> because with 150 Activities, having 150 ActivityFactories might be too
> much.
> is there a better/alternative way ?
>
If you don't need to pass arguments, then just inject Provider<MyActivity>
instead of Activity and you have a "factory" of the activity type (that will
defer instantiation) instead of an early-instantiated Activity instance.
> and I intend to further expand these ActivityFactories to help in
> CodeSplitting,
> through AsyncProxyProvider.
>
> therefore this is the reason I was planning to use one Provider per
> Activity, now I am going to use
> one Factory per Activity.
>
> but you hinted on GIN assisted inject. could you please elaborate a
> little on that ?
> and in your opinion is the idea behind using ActivityFactory flawed ?
> can you think of an alternative approach or suggest a way to improve
> what I'm trying to achieve ?
>From your current working code that maps things to activities, *just*
replace Map<foo, Activity> with Map<foo, Provider<Activity>>.
Then, look at the code generated by GIN (pass "-gen someFolder" to the GWT
compiler or DevMode) to better understand what it does (maybe use a smaller
project and iterate adding/changing things and looking at the generated
code).
--
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.
