Repository navigation
Extend new Fragment Scope for EBean #2214
Description
Activity
I think it would overload the
@EBeanannotation. Maybe we should add another annotation instead, but i still think this is too much already. @dodgex WDYT?Well, I guess that what I'm proposing could be applied to the Activity scope as well, probably another annotation would be better for this.
But well, with fragments is quite common scenario, that you have a Fragment, holding a ViewPager, which hold other fragments.. there it would be really useful. Basically we are extending the scope, permitting to the programmer define, in what scope a given Bean is valid.
Well, if @dodgex considers it is useful, we could go with another annotation for it, maybe simply
@Scope, which has several options "tags, ids, classes".. It would apply to the fragments or even different activities (by class).Note that in the current implementation, is not that much, basically we need "to find the bean holder", that's all, everything else works like in #2206
After reading the issue for like 3 times i think i understand what you want.
I agree with @WonderCsabo that it would overload the
@EBeanannotation. but I'm not sure how possible it is to have a second variable that limits where it might be injected. that would require the@Beanannotation handler to take care of the second annotation too.On this case is the
@EBeanwhich should take care of the other annotation.. But well, there are several cases like this already on the code.. For instance, the@EActivityshould take care of the@DataBound. So the@EBeanshould take care for this case of the@Scope@dodgex the injection is really "handled" on the
@EBean.. The newBeanHoldermechanism is implemented like this, for instance, for the Activity scope:public static ActivityScopedBean_ getInstance_(Context context) { if (context instanceof BeanHolder) { BeanHolder beanHolder = ((BeanHolder) context); ActivityScopedBean_ bean = beanHolder.getBean(ActivityScopedBean_.class); if (bean == null) { bean = new ActivityScopedBean_(context); beanHolder.putBean(ActivityScopedBean_.class, bean); bean.init_(); } return bean; } ActivityScopedBean_ bean = new ActivityScopedBean_(context); bean.init_(); return bean; }
So, basically the proposed
@Scopeannotation what should do here is to find "the rightBeanHolder. Something like:public static ActivityScopedBean_ getInstance_(Context context) { BeanHolder beanHolder = findBeanHolder(context); //Do the injection from beanHolder if found //default to normal constructor }
So basically, what
@Scopewould do, is to implement thisfindBeanHolder().So,
@Beancontinues calling the normalgetInstance_method like beforeokay. you are right with this. sorry. :)
but honestly i think if possible the scope should be checked while generating the injecting code to validate if a injection is valid at compile time rather than on runtime.
e.g. fail if you try to inject a fragment scoped bean in an activity or some other bean. or if it is injected into another bean and the other bean is not scoped [the same way].
@WonderCsabo wdyt?
Well, this would be a validation, which can be done on the
@Bean.. That would not change the current code I think. I think the validations are quite valid to do them in theBeanHandler.. If @WonderCsabo agrees with it, I can do them. Note that there are 2 scenarios:- Bean injected on the Activity or Fragment being scoped with that.
- Bean injected in another bean.. in that case, the Scopes should be the same then.
@smaugho if it can be done without adding too much complexity, let's do it.
We resently added Fragment Scope for EBean annotated classes on #2206. Its usage right now is simply to ensure that the EBean is the same if it is injected in the same fragment scope. There is some cases of uses in which could be useful, though there are other cases in which its usability increases.
It is common to have fragments which contains multiple subfragments. Or to have a collection of fragments which are related in functionality.
I do propose to extend the Fragment scope for this cases, for doing so,
@EBeanshould support 2 extra parameters,fragmentId, andfragmentTag. This is an example of usage:This will increase the usability of the new Fragment scope. You could have complete sections on the app sharing the same instance of a Bean, which is really useful.
For doing this, basically to inject the Bean, it is used exactly the same mechanism implemented on #2206, merged with a search of Fragment by ID or by Tag (similar to how the
@FragmentByIdor@FragmentByTagwork).The fragment will be injected using the first
BeanHolderfound, so if a serie of fragmentsId is provided, the first one would be the "holder" of the bean. In the case of not existing the second and so on.In cases where there is a "parent fragment" of course, the best is that the programmer select this parent fragment as the holder (only providing its ID to the
@EBean) (like a fragment with a ViewPager which contains multiple other fragments).If the parameters
fragmentIdorfragmentTagare not provided, then it works exactly how it is currently implemented.