CODEWITHSUNDEEP
androiddependency-injectiondagger-2daggerdagger-hilt
vbp
vbp

Reputation: 1205

How inject dagger non empty constructor module dependencies to hilt

Hilt is not supportting non epmty constructor modules. If we need to migrate partially to Hilt from dagger , how we can inject dependencies from legacy dagger modules having non empty constrctors to hilt components such as HiltViewModel.

// Legacy Dagger module
@Module
public class DaggerModule {    
    private final Boolean customBoolean;
    
    DaggerModule(Boolean customBoolean) {
        this.customBoolean = customBoolean;
    }

    @Provides 
    @Singleton
    CustomClass provideCustomClass() {
        return CustomClass(customBoolean);
    }
}

@Module
public class AnotherDaggerModule {    

    @Provides 
    @Singleton
    AnotherClassDepndsOnCustomClass provideAnotherClass(CustomClass customClass) {
        return AnotherClassDepndsOnCustomClass(customClass);
    }
}


// Migrated Hilt module

@HiltViewModel
class HiltViewModel @Inject constructor(
  private val anotherClass: AnotherClassDepndsOnCustomClass
) : ViewModel() {
  ...
}

Since we are not using components to pass some custom parameters while initialising modules, is there any solution which I'm not aware already exists?

While running the app, the app crashing with error DaggerModule must be set.

Upvotes: 1

Views: 1269

Answers (1)

Jeff Bowman
Jeff Bowman

Reputation: 95764

You'll need to refactor.

The documentation on Migrating to Hilt describes this case under the heading "Handling Component Arguments", since instantiable modules would otherwise be treated as component arguments passed through a Builder or Factory:

Hilt components cannot take component arguments because the initialization of the component is hidden from users. [...]

If your component has any other arguments either through module instances passed to the builder or @BindsInstance, read this section on handling those. Once you handle those, you can just remove your @Component.Builder interface as it will be unused.

Under "Component arguments" the Hilt documentation confirms that a refactor is required:

Because component instantiation is hidden when using Hilt, it is not possible to add in your own component arguments with either module instances or @BindsInstance calls. If you have these in your component, you’ll need to refactor your code away from using these.

You can consider some of these structures:

Replacement module / subclassing Modules

In your example, you might need to create a replacement Module that provides a binding for CustomClass. This might be as straightforward as subclassing the Module and providing a public no-arg constructor that provides the super(value) constructor call your module needs. If your Module would only ever get a single value in your graph (but might get a different value in a separate application), then this might be enough.

@Module
public class AdaptedDaggerModule extends DaggerModule {
    AdaptedDaggerModule() {
        super(true);
    }
}

Note that module subclasses are somewhat limited in utility, and should not be used for testing overrides.

Custom subcomponents

However, you also wrote "components are created in respective modules where we need to use" in a comment, and you can continue doing so using custom subcomponents in Hilt, with more comprehensive documentation in javadoc or the main Dagger subcomponent documentation. Because you would create this component through an explicit call to a Builder or Factory, you could provide the Module instance there. Subcomponents inherit bindings from their parent components, so you could avoid specifying your entire list of Modules.

Note that doing this as a subcomponent is mostly valuable when you have a dense tree with multiple references to the instance you're providing in the constructor. If this is simply a matter of combining graph-based constructor arguments with one-off constructor arguments, assisted injection is probably a better option.

/** Subcomponents are usually declared on modules. You can also reuse one you have. */
@Module(subcomponents={YourSubcomponent.class})
public interface IncludeThisInYourHiltModuleList {}

@Subcomponent(modules={DaggerModule.class, AnotherDaggerModule.class})
public interface YourSubcomponent {
    AnotherClassDepndsOnCustomClass anotherClass();

    @Subcomponent.Builder
    interface Builder {
        Builder daggerModule(DaggerModule daggerModule);  // arbitrary name
        YourSubcomponent build();  // arbitrary name
    }
}

@HiltViewModel
class HiltViewModel @Inject constructor(
  private val yourSubcomponentBuilder: YourSubcomponent.Builder
) : ViewModel() {
  fun yourMethod() {
    val subcomponent = 
        yourSubcomponentBuilder.daggerModule(DaggerModule(false)).build()
    val anotherClass = subcomponent.anotherClass()
    // ...
  }
}

Constructor values in Hilt-managed components

The most difficult case would be where your Module would want separate values in each of your Hilt-managed components, e.g. each Activity needing to pass a different constructor argument. In that case you might need to rephrase the customBoolean (or other parameters) as deriving the value from the Activity instance itself. This maintains Hilt's expectation that it can create an Activity component for each Activity instance that Android unpredictably creates or recreates, and it can do so without specifying any other constructor parameters.

Upvotes: 3

Related Questions