2009/7/23 Michael Burton <[email protected]>:
>
> Thanks for the link, Aleksey.
>
> Yeah, it seems like binding every configuration constant to an
> instance a viable workaround for some situations, but it doesn't seem
> like it's really the right solution.
>
> In particular, on Android I don't want to load all of the resources at
> the time the module is started.  Some of them can be memory intensive
> (eg. bitmaps), and many of my Android activities will never use most
> of them at all.
>
> I can understand the arguments I've read elsewhere (eg. Dhanji here
> http://bit.ly/1FPeAq ) that configuration data doesn't belong in code,
> but every once in awhile we all have to work with frameworks that
> force you to jump through hoops, and it seems like Guice could make
> this sort of thing a lot easier with just a small tweak...

I agree; it would be really nice to be able to write a @Provides
method which has the binding annotation instance as a parameter; so
that you can write a single method which extracts values from the
annotation instance & uses those to create the required object to
inject - rather than having to explicitly bind every permutation of
values of the annotation to instances/providers.


> That being said, perhaps someone knows a way to do this already?  Is
> it possible to get access to the Annotation instance from within a
> provider?  I've been trying to follow the discussions here, but
> haven't really been able to figure out what's supported and what
> isn't.
>
> http://code.google.com/p/google-guice/issues/detail?id=258
> http://code.google.com/p/google-guice/issues/detail?id=27
>
> Can I get this sort of capability with something like Guiceyfruit?
> (And if so, can I use Guiceyfruit without AOP since AOP's not
> supported on Android)

Unfortunately not in the example you show....

@Inject
public void setString( @StringResource(R.string.foobar) String foobar)

GuiceyFruit currently focusses on using an annotation to specify a
parameterised injection point (like @Resource) which only tends to
work on a field or property injection point - not on annotations on
parameters at a regular @Inject injection point.

If you did it more like this...

@StringResource(R.string.foobar)
public void setString(  String foobar)

then you could bind the StringResource annotation as an injection
point like the way @Resource is supported; you can then write a kind
of provider which takes the StringResource annotation and uses its
values to create an object.

e.g.

http://code.google.com/p/guiceyfruit/source/browse/trunk/guiceyfruit-core/src/main/java/org/guiceyfruit/jsr250/ResourceMemberProvider.java

for code sharing reasons much of the heavy lifting is actually in this
base class

http://code.google.com/p/guiceyfruit/source/browse/trunk/guiceyfruit-core/src/main/java/org/guiceyfruit/jsr250/NamedProviderSupport.java

So in GuiceyFruit you'd implement a class which extends
AnnotationMemberProviderSupport<StringResource> then you bind it in
your GuiceyFruitModule via the bindAnnotationInjector() method
http://code.google.com/p/guiceyfruit/source/browse/trunk/guiceyfruit-core/src/main/java/org/guiceyfruit/jsr250/Jsr250Module.java

-- 
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"google-guice" 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-guice?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to