google/dagger

Allow @IntoSet to target class/constructor

FunkyMuse opened this issue · 4 comments

The use case for this one is the following, for example I have an interceptors module where i'm forced to have a module

@Module
@InstallIn(SingletonComponent::class)
object NetworkInterceptorModule {
    
    @Provides
    @IntoSet 
    @Singleton
    fun connectivityInterceptor(@ApplicationContext context: Context): Interceptor =
        ConnectivityInterceptor(context)
    
    @Provides
    @IntoSet 
    @Singleton
    fun authorizationInterceptor(encryptedPreferencesManager: EncryptedPreferencesManager): Interceptor =
        BasicAuthInterceptor(encryptedPreferencesManager)
}

What would be more useful is for Dagger2 to be able to recognize and allow the following

@IntoSet
@Singleton
class ConnectivityInterceptor @Inject constructor(@ApplicationContext private val context: Context)

or

@Singleton
class ConnectivityInterceptor @Inject @IntoSet constructor(@ApplicationContext private val context: Context)

Instead of having a module every time and manually needing to provide every dependency this will save time and boilerplate to be written.

See #510 (comment) for an explanation of why this is not currently feasible.

See #510 (comment) for an explanation of why this is not currently feasible.

Thanks for the explanation, as I can see now that the current hurdle is in the "type" problem, which you'd need to scan for, but maybe it's possible for the subtype, as you can see in the sample above every interceptor is of a subtype of Interceptor, basically the implementation, I know this sounds cheesy and rushed comment but i'm just thinking out loud for the moment without too much knowledge about this problem.

Note that the comment in #510 mostly applies to Dagger.

If you're talking about Hilt, you could probably write your own Hilt extension, similar to https://github.com/sczerwinski/android-hilt to generate an @InstallIn Module that binds your implementation class to some interface in some component.

However, we're unlikely to make this a feature of Hilt. In particular, the API works okay for simple cases, like the one you mentioned above, but can quickly get out of hand for more complex use cases. Thus, IMO it's not a great candidate for an official Hilt feature.