Injecting WorkManager into ViewModels with Dagger Hilt. No Context, No Boilerplate, Always a WorkQuery Back

Hakim — Wed, 10 Jun 2026 09:13:00 +0000

WorkManager is the right tool for deferrable, guaranteed background work in Android. But the default setup pushes you toward boilerplate fast: you end up calling WorkManager.getInstance(context) inside ViewModels, "passing Context where it doesn't belong", re-registering observers scattered across the codebase, and getting no consistent way to query the state of your enqueued work.

This tutorial shows how to build a clean, injectable WorkManagerHandler using Dagger Hilt, a single interface that any ViewModel can receive through constructor injection, with zero Context and a guaranteed WorkQuery callback on every call so you always know what to observe.

By the end, you'll have:

A WorkManager singleton provided through Hilt
A custom Configuration.Provider that plugs Hilt's HiltWorkerFactory into WorkManager at initialization
A WorkManagerHandler interface with a WorkManagerHandlerImpl that encapsulates enqueueing, chaining, and query registration
ViewModels that declare WorkManagerHandler as a plain constructor dependency

The pattern scales cleanly as you add workers: each new worker is one method on the handler, and the ViewModel never knows or cares how work is scheduled underneath.

Prerequisites: familiarity with Dagger Hilt basics, Jetpack WorkManager fundamentals, and Kotlin coroutines. A working Android project with Hilt already configured is assumed.

Part 1: Application Setup and Custom Configuration.Provider

By default, WorkManager initializes itself automatically using its own internal factory. The problem is that Hilt-injected workers need Hilt's factory HiltWorkerFactory to resolve their @Inject constructor dependencies. If you let WorkManager self-initialize, your workers won't have access to any of your Hilt bindings.

The fix is to disable auto-initialization and take manual control via Configuration.Provider and AndroidManifest.xml

1. Disable auto-initialization

In your AndroidManifest.xml, remove WorkManager's default initializer:

<application ...>

    <provider
        android:name="androidx.startup.InitializationProvider"
        android:authorities="${applicationId}.androidx-startup"
        android:exported="false"
        tools:node="merge">
        <meta-data
            android:name="androidx.work.WorkManagerInitializer"
            android:value="androidx.startup"
            tools:node="remove" />
    </provider>

</application>

This tells Jetpack Startup to skip the default WorkManager setup so you can wire it yourself.

2. Implement Configuration.Provider in your Application class

@HiltAndroidApp
class CustomApp : Application(), Configuration.Provider {

    @Inject
    lateinit var workerFactory: HiltWorkerFactory

    override fun onCreate() {
        super.onCreate()
        WorkManager.initialize(this, workManagerConfiguration)
    }

    override val workManagerConfiguration: Configuration
        get() = Configuration.Builder()
            .setWorkerFactory(workerFactory)
            .build()
}

A few things worth noting here:

@HiltAndroidApptriggers Hilt's code generation and makes the Application class an injection entry point, this is what makes @Inject lateinit var workerFactory work.
HiltWorkerFactory is Hilt's bridge into WorkManager. When WorkManager instantiates a worker, it will use this factory, which knows how to satisfy @Inject
We call WorkManager.initialize() manually in onCreate(), after Hilt has performed field injection, which means workerFactory is guaranteed to be non-null by the time it's used.

Why this matters for the rest of the tutorial
Without this setup, any @AssistedInject or @Inject constructor in a worker class will silently fail at runtime, WorkManager will either crash or fall back to a no-arg constructor it can't find. Getting this right first means everything built on top of it will actually work.

Part 2: Providing the WorkManager Singleton and Writing Your First CoroutineWorker

With the Application class wired up, the next step is making the WorkManager instance available across the app through Hilt, and writing a worker that can actually receive injected dependencies.

1. Provide the WorkManager singleton
In your Hilt module, add a @Provides binding for WorkManager:

@Module
@InstallIn(SingletonComponent::class)
object WorkManagerModule {

    @Provides
    @Singleton
    fun provideWorkManagerInstance(
        @ApplicationContext context: Context
    ): WorkManager = WorkManager.getInstance(context)
}

A few things to note:

@Singleton ensures the entire app shares one WorkManager instance, this is important because WorkManager itself is a singleton under the hood, and wrapping it consistently avoids subtle state mismatches.
@ApplicationContext is a Hilt built-in qualifier. It gives you the application'Context without you having to pass it manually anywhere. This is the last time Context appears directly in this tutorial.
This binding is what gets injected into WorkManagerHandlerImpl later. The ViewModel never touches WorkManager directly. 2. Write your first CoroutineWorker with Hilt injection A regular Worker subclass can't receive Hilt injections through a normal @Inject constructor because WorkManager controls instantiation. The solution is @HiltWorker combined with @AssistedInject:

@HiltWorker
class YourWorker @AssistedInject constructor(
    @Assisted context: Context,
    @Assisted workerParams: WorkerParameters,
    private val someDependency: SomeDependency  // injected by Hilt
) : CoroutineWorker(context, workerParams) {

    override suspend fun doWork(): Result = coroutineScope {
        //Do some work
        Result.success()
    }
}

Breaking this down:

@HiltWorker marks the class so Hilt's code generator knows to produce a factory for it. Without this, HiltWorkerFactory won't know the worker exists.
@AssistedInject is used because WorkManager must provide context and workerParams at runtime;Hilt can't know those at compile time. @Assisted marks those two parameters as runtime-provided; everything else (someDependency) is resolved from the Hilt graph normally.

The worker is ready. The singleton is in the graph. Next we build the interface that ViewModels will actually talk to.

Part 3: The WorkManagerHandler Interface and Its Implementation

This is the core of the pattern. Instead of ViewModels calling WorkManager directly, they talk to a WorkManagerHandler interface. The implementation handles enqueueing, chaining, and always hands a WorkQuery back so the caller knows exactly what to observe.

1. Define the interface

interface WorkManagerHandler {

    fun initializeYourWorker(
        inputData: Data,
        workQuery: (WorkQuery) -> Unit
    )
    fun observeWorkInfo(workQuery: WorkQuery): Flow<List<WorkInfo>>

}

A few design decisions worth calling out:

Every method takes a workQuery: (WorkQuery) -> Unit callback. This is the contract: you will always get a WorkQuery back, no matter which worker you trigger. The ViewModel uses it to observe work state without knowing anything about IDs or tags internally.
Data is WorkManager's key-value input container. Keeping it as the parameter type rather than raw primitives means the handler stays agnostic, it doesn't need to know what the data means, only that it gets passed into the worker.
The interface has no Context, no WorkManager, no lifecycle references. It is a pure behavioral contract.

2. Implement the interface

class WorkManagerHandlerImpl @Inject constructor(
    private val workManager: WorkManager
) : WorkManagerHandler {

    override fun initializeFiltersWorker(
        inputData: Data,
        workQuery: (WorkQuery) -> Unit
    ) {
        val request = OneTimeWorkRequestBuilder<YourWorker>()
            .setInputData(inputData)
            .build()

        workManager.enqueue(request)

        val query = WorkQuery.fromIds(mutableListOf(request.id))
        workQuery(query)
    }

    override fun observeWorkInfo(workQuery: WorkQuery): Flow<List<WorkInfo>> {
    return workManager.getWorkInfosFlow(workQuery)
}
}

Breaking this down:

@Inject constructor with WorkManager as the only parameter, Hilt resolves this from the singleton we provided in Part 2. No Context needed anywhere here.
WorkQuery.fromIds() is built immediately after enqueueing, before the callback fires. This means the ViewModel receives the query in the same call stack as the enqueue, there is no race window where work is running but unobservable.

3. Bind the implementation in your Hilt module

The interface and implementation need to be connected. Add an abstract binding to your module:

@Module
@InstallIn(SingletonComponent::class)
abstract class WorkManagerBindingsModule {

    @Binds
    @Singleton
    abstract fun bindWorkManagerHandler(
        impl: WorkManagerHandlerImpl
    ): WorkManagerHandler
}

Note that @Binds requires an abstract function in an abstract module, it cannot live in the same object as @Provides functions. If your existing module is an object, either convert it to an abstract class or create a separate module as shown above. Both approaches are valid.

The handler is fully wired into the Hilt graph. Any class that declares WorkManagerHandler in its constructor will get a fully functional implementation injected with no setup, no context, no boilerplate.

Part 4: Injecting into a ViewModel and Observing Work State

This is where the pattern pays off. The ViewModel declares WorkManagerHandler as a plain constructor dependency, triggers work through it, and observes the returned WorkQuery all without touching Context,WorkManager, or any lifecycle plumbing directly.

1. Inject the handler into a ViewModel

@HiltViewModel
class MyViewModel @Inject constructor(
    private val workManagerHandler: WorkManagerHandler
) : ViewModel() {

    private val _workState = MutableStateFlow<WorkInfo?>(null)
    val workState: StateFlow<WorkInfo?> = _workState.asStateFlow()

    fun fetchData(dataType: String) {
        val inputData = workDataOf(
            DATA_KEY to dataType
        )

        workManagerHandler.initializeYourWorker(inputData) { workQuery ->
            observeWork(workQuery)
        }
    }
    private fun observeWork(workQuery: WorkQuery) {
    viewModelScope.launch {
        workManagerHandler
            .observeWorkInfo(workQuery)
            .collect { workInfoList ->
                _workState.value = workInfoList.firstOrNull()
            }
    }
}
}

One note:
The WorkQuery that comes back from the handler callback is immediately handed to observeWork(). Because the query is built right after enqueue inside the handler (as we saw in Part 3), by the time observeWork() runs the work is already enqueued and observable.

2. Observe work state in your Composable

@Composable
fun MyScreen(
    viewModel: MyViewModel = hiltViewModel()
) {
    val workState by viewModel.workState.collectAsStateWithLifecycle()

    LaunchedEffect(Unit) {
        viewModel.fetchData("category_data")
    }

    when (workState?.state) {
        WorkInfo.State.ENQUEUED,
        WorkInfo.State.RUNNING -> {
            CircularProgressIndicator()
        }
        WorkInfo.State.SUCCEEDED -> {
            // render results
        }
        WorkInfo.State.FAILED,
        WorkInfo.State.CANCELLED -> {
            // show error state
        }
        else -> Unit
    }
}

Common mistakes to avoid
Calling WorkManager.getInstance() directly in a ViewModel. This bypasses the injected singleton and can produce a second instance if auto-initialization wasn't properly disabled. Always inject WorkManagerHandler and let the handler own the WorkManager reference.

Forgetting tools:node="remove" in the manifest. If the default initializer is still active, WorkManager self-initializes before HiltWorkerFactory is ready. Workers will fail to instantiate any @Inject dependencies silently.

Using @Inject instead of @AssistedInject in a worker. WorkManager provides context and workerParams at runtime, Hilt cannot know them at compile time. Without @AssistedInject and @Assisted, the worker constructor will either fail to compile or crash at runtime.

Building WorkQuery before calling enqueue(). The request ID exists as soon as the request object is built, but the work isn't registered with WorkManager until after enqueue(). Always build the query after the enqueue call to guarantee the work is observable immediately.

Swapping WorkManagerHandler and WorkManagerHandlerImpl or assuming it's the same in the @Binds declaration. This is one of the most common Hilt mistakes and the error message does not always make it obvious. The rule is: the return type is the interface, the parameter is the implementation — not the other way around.

// WRONG — will fail to compile or inject incorrectly
@Binds
@Singleton
abstract fun bindWorkManagerHandler(
    impl: WorkManagerHandler         // ❌ interface as parameter
): WorkManagerHandlerImpl            // ❌ implementation as return type

Or:

@Binds
@Singleton
abstract fun bindWorkManagerHandler(
    impl: WorkManagerHandlerImpl         // ❌ implementation as return type
): WorkManagerHandlerImpl            // ❌ implementation as return type


// CORRECT
@Binds
@Singleton
abstract fun bindWorkManagerHandler(
    impl: WorkManagerHandlerImpl     // ✅ concrete class Hilt knows how to build
): WorkManagerHandler                // ✅ the type the rest of the graph asks for

Wrapping up

The pattern covered in this tutorial gives you:

A single WorkManagerHandler interface that any ViewModel can receive with no setup cost
Workers that participate fully in the Hilt dependency graph via @HiltWorker and @AssistedInject
A guaranteed WorkQuery on every enqueue so the UI always has something to observe
The ability to add as many workers as you want.

The boundary between WorkManager and the rest of your app is now the WorkManagerHandler interface, which means it is also the boundary you can mock in tests.

DEV Community: Hakim

Injecting WorkManager into ViewModels with Dagger Hilt. No Context, No Boilerplate, Always a WorkQuery Back