I am using Dagger-2 (ver: 2.7) and AutoFactory (ver: 1.0-beta3). I am facing a peculiar issue.
I have a a class MyRequest who's ctor takes 2 parameters as:
- ConnectivityManager conmgr
- int somevalue
I created the ctor as
@Autofactory
public MyRequest(@Provider ConnectivityManager conmgr, int somevalue){
//
}
I have a module containing the following
@Provides
@SystemScope
public final ConnectivityManager provideConnectivityManager(App app) {
return (ConnectivityManager)
app.getSystemService(Context.CONNECTIVITY_SERVICE);
}
In the same module I do the following
@Provides
@SystemScope
public final MyRequestFactory providesMyRequestFactory(ConnectivityManager connectivityManager {
return new MyRequestFactory(connectivityManager);
}
I am getting build error incompatible types: ConnectivityManager cannot be converted to Provider < ConnectivityManager >.
Any idea how to solve this ?
As in the AutoFactory example, if your constructor takes a
Foo, your AutoFactory's generated constructor will take aProvider<Foo>instead. This is so your factory will request a newFoo(orConnectivityManager) once for each call togetwithout necessarily sharing instances between them.It may be the case that you want
FooorConnectivityManagerto be the same instance for all instances of the created object (MyRequesthere), but that's for you and Dagger to dictate, not AutoFactory. Consequently, AutoFactory will always generate code that takes Providers, whether you use them that way or not.Luckily, the fix is very easy: Dagger can inject a
Provider<ConnectivityManager>just as easily as it can inject aConnectivityManager(as it can for any binding), so you can just change your@Providesmethod like so......but because your generated factory will have an
@Injectannotation, you would probably be better off deleting the@Providesmethod entirely and letting Dagger use that constructor forMyRequestFactoryinjections. Though you'll lose the@SystemScopescope annotation from the@Providesmethod, that's no problem: With theProvider<ConnectivityManager>injection above, you don't have to worry about the lifecycle of the generated factory, so you can fall back to a default unscoped provision.