Comments (18)
Two components with the same scope can break scoping.
From your example:
Component1 c1 = Dagger_Component1.create();
Component2 c2_a = Dagger_Component2.builder().component1(c1).build();
Component2 c2_b = Dagger_Component2.builder().component1(c1).build();
c1
has singletons which are used across c2_a
and c2_b
but the singletons from Component2
get separate instances in c2_a
and c2_b
.
from dagger.
@cxzhang2 you can use the default java accessibility system to block provisions to be "passed" to a child subcomponent. I.e. if package com.example.foo
has the @Component
and uses a package-private annotation @Private
, then a subcomponent in com.example.bar
won't be able to access provisions from the parent since Java won't allow it to reference com.example.foo.Private
. That's what we've been recommending.
from dagger.
I quickly made a simple project to test and simplified my setup. I get the error below as soon as I create the DataComponent, and have AppComponent use it as a dependency. If i only use AppComponent and ActivityComponent ( the latter depends on the former ), i have no issues.
So I'm either doing something wrong entirely and Snapshot 12 didn't mind ( most probable ), or there's a new issue in Snapshot 13.
Error:(36, 14) error:.di.ActivityComponent depends on scoped components in a non-hierarchical scope ordering:
@singleton di.DataComponent
@singleton di.AppComponent
@qast.di.PerActivity di.ActivityComponent
from dagger.
Similar issue, If you want more than 2 Components deep dagger is unusable.
from dagger.
This is by design.
from dagger.
@JakeWharton I appreciate that, looking through #96, its to make components stricter. It just makes things like this impossible:
@dagger.Component(dependencies = {ActivityComponent.class, AppComponent.class}, modules = ScreenModule.class)
@PerScreenScope
interface ScreenComponent {}
//--
@dagger.Component(dependencies = AppComponent.class, modules = ActivityModule.class)
@PerActivityScope
interface ActivityComponent {}
//--
@dagger.Component(modules = AppModule.class)
@Singleton
interface AppComponent {}
This was done to stop chances of depending on different lifecycled scopes (e.g. @PerActivity
scope getting cleaned up before @PerScreen
.) Which I understand.
But then I wish hierarchy component injection worked. (injecting something in the @PerScreen
throws "May not reference binding with difference scopes")
Unless I am missing something? Docs are pretty light right now, but I guess thats due to the API changes.
from dagger.
@JakeWharton, care to explain or point me to some resources on how to either set up multiple components? ( Imagine I'd like to have modules and components per seperate layer (data/business/...))
I've read @chrisjenx's explanation and understand the choice, but it seems to me that both components in the @singleton scope (or any same scope) should be able to depend on one-another?
from dagger.
@Trikke I agree with what happened with Cyclic dependencies that will stop potential cases where you get multiple singletons. If you want to seperate your Data/Business logic, I use different Modules.
@JakeWharton if thats the case surely this should be acceptable:
Component1 c1 = Dagger_Component1.create();
Component2 c2 = Dagger_Component2.builder().component1(c1).build();
Component3 c3 = Dagger_Component3.builder().component2(c2).build();
c3.inject(ClassWithDependencencyInComponent1 classWithDep);
As you can build multiple c3
's off one c2
's which in turn will have a route to the c1
singletons?
from dagger.
@chrisjenx Yep. I wasn't disagreeing with your use case. Not at a place where I can test it right now.
from dagger.
@JakeWharton Ahh OK, My use case throws up in my face at the moment then. Hopefully a bug or me doing it wrong...
Error:(48, 5) error: ui.mortar.ActivateAddCard.Component scoped with @qualifiers.PerScreen may not reference bindings with different scopes:
@Singleton class io.database.DatabaseManager
//---
(That component depends on an Activity component, which depends on the App component)
from dagger.
@chrisjenx , I already had different modules for separation of data/logic, and had components laid out in the same way. I'm still new to this stuff, so I'll have to read up on how to structure components properly. Although i think i had practically the same use case as you described above as something that should be possible.
from dagger.
I ended up using different scopes for each of my subcomponents while my main component is annotated with @Singleton
. Is this how you should do it or is there a way to not having to create scopes for each component?
@Singleton
@Component(modules = DatabaseModule.class)
public interface MainComponent {
DatabaseProvider databaseProvider();
}
@OrderScope
@Component(dependencies = MainComponent.class, modules = OrderModule.class)
public interface OrderListComponent {
void inject(OrderListActivity activity);
}
@ScanningScope
@Component(dependencies = MainComponent.class, modules = ScanningModule.class)
public interface ScanningComponent {
void inject(ScanActivity activity);
}
from dagger.
A few things -
Firstly, greg is working out a more flexible sub-component approach for this. It'll be cleaner, I think.
If you're going to do subcomponents in three levels, and you want to shuttle your singletons to the bottom layer, in the current code, just have your middle-tier component extend the application-level component. THis will expose those bindings to the lower-tier component without requring that you have your lower-tier depend on two scoped components.
@dagger.Component(dependencies = ActivityComponent.class, modules = ScreenModule.class)
@PerScreenScope
interface ScreenComponent {}
//--
@dagger.Component(dependencies = AppComponent.class, modules = ActivityModule.class)
@PerActivityScope
interface ActivityComponent extends AppComponent {} // <---- note here, the pass-through contract.
//--
@dagger.Component(modules = AppModule.class)
@Singleton
interface AppComponent {}
if you do this, then all the contract of AppComponent is visible to ScreenComponent via ActivityComponent. then you don't have to do the multiple dependencies (which are disallowed)
That said, I think the forthcoming @SubComponent
approach will make this a little cleaner, and with fewer methods, etc. But for now, the above should be a reasonable way to go.
from dagger.
Also, during migration, you can disable the "singleton can't depend on singleton" bit with an annotation processor flag -Adagger.disableInterComponentScopeValidation=warning (or none). It is intended as a migration aid from dagger 1 so please don't rely on it, as it may not be there forever. It doesn't disable all validations, but should at least permit you to do the singleton->singleton stuff while you migrate to separate meaningful scoping annotations.
from dagger.
@cgruber Thanks for that, thats pretty much what I have done, I have Dependent interfaces for each activity scope which expose the singleton and app scopes up the tree.
@SubComponent
sounds better, as there feels like way too much boilerplate right now.
I'll stay posted.
from dagger.
Any update on this? Is it sane to want the access controls of component dependencies and the transitive-ness of @subcomponents?
i.e., some flag to toggle for Subcomponents to honor the provision methods of the parent component interface (and thus restrict access to non-exposed provisions in parent modules)?
from dagger.
is there a final solution to handle this requirement?i mean the 3-level Component dependencies.
from dagger.
@ronshapiro I see, thank you!
from dagger.
Related Issues (20)
- Dagger 2.50 KSP fails to generate field in implementation for a @Named field HOT 2
- Conflicting documentation for dagger.android and Hilt optional inject HOT 3
- [KSP] dagger-android hanging indefinitely on a large multi module project HOT 2
- Optional bindings in a parent component can sometimes use bindings from child components HOT 2
- NullPointerException dagger.spi.shaded.androidx.room.compiler.processing.XTypeElement.getAnnotation HOT 6
- Problem with Injection of DAO HOT 1
- error: [Hilt] Could not get element for com.foo.viewModels.FooViewModel_HiltModules.BindsModule: java.lang.NullPointerException HOT 1
- Missing release notes for 2.51 HOT 1
- `LazyClassKey` doesn't work when providing a `Map<Class<*>, Provider<?>` with a scope
- @AssistedInject in ViewModel using Dagger (NOT Hilt, just dagger) does not compile: cannot be provided without an @Inject constructor or an @Provides-annotated method HOT 6
- [issue] Dagger doesn't compile or doesn't give a right error message when ViewModelFactory is implemened on Kotlin rather than on Java HOT 4
- Having an issue with Dagger Hilt Proguard Rules HOT 12
- Following dagger.dev tutorial doesnt create singleton in v2.51 HOT 2
- Multibinding with Nested Complex Keys uses the wrong AnnotationCreator HOT 1
- [Hilt] onCreate() in my Application doesn't called on Instrument test HOT 4
- [Dagger-Hilt] Error when applying obfuscation other than Proguard (Allatori) HOT 3
- error: [Hilt] Expected @AndroidEntryPoint to have a value HOT 3
- @IntoSet analog for injectable classes HOT 3
- Hilt Generated Code having not used code? HOT 2
- [Dagger-Hilt] Can't get viewModel in composable by Hilt HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dagger.