tezvyn:

WorkRequest: The Blueprint for Android Background Tasks

AI-drafted, machine-checkedintermediate

A WorkRequest is the blueprint for a background task in Android. It defines *what* work to do and *when*, letting WorkManager handle execution for tasks like syncing data. The footgun is putting logic in the request; it only configures, the Worker acts.

WHY IT EXISTS Android needs a reliable way to execute background tasks that can survive app closures and device reboots. Simple asynchronous operations are not guaranteed to finish. WorkManager provides this guarantee, and WorkRequest is the object we use to define and configure the work we want it to perform.

THE MENTAL MODEL A WorkRequest is a job ticket you hand to the WorkManager service. The ticket says: "Run the code in my DataSyncWorker class. But only start when the device has an unmetered network and is charging. If it fails, try again after 10 minutes." WorkManager is the foreman who reads this ticket, waits for the right conditions, and dispatches the worker to do the job.

HOW IT WORKS You create either a OneTimeWorkRequest or a PeriodicWorkRequest using its builder. This builder lets you specify several key parameters. First, the Worker class that contains the actual code to be executed. Second, a set of Constraints that must be met, such as requiring a network connection or device charging. Third, you can provide input Data as a simple key-value map. Finally, you can define a BackoffPolicy to control retry behavior. Once configured, you hand the request to the system by calling WorkManager.getInstance(context).enqueue(yourWorkRequest).

WHEN TO USE IT Use WorkRequest for deferrable, guaranteed background work. It's perfect for tasks that don't need to run immediately but must eventually complete, even if the app is killed or the device restarts. Common use cases include syncing local data with a server, uploading analytics, or applying filters to an image in the background.

WHEN NOT TO USE IT Do not use WorkManager for tasks that must execute immediately while the user is interacting with the app; use Kotlin Coroutines for that. It is also not for tasks requiring precise timing, where AlarmManager is a better (though restricted) fit. For long-running tasks that the user must be aware of, such as music playback, a foreground Service is the correct component.

ONE CANONICAL EXAMPLE To schedule a one-time photo compression task that only runs when the device is idle, you would first define a CompressWorker. Then you'd build the request: val constraints = Constraints.Builder().setRequiresDeviceIdle(true).build(). Then, val compressionRequest = OneTimeWorkRequest.Builder(CompressWorker::class.java).setConstraints(constraints).setInputData(workDataOf("IMAGE_URI" to uriString)).build(). Finally, you enqueue it: WorkManager.getInstance(context).enqueue(compressionRequest). This tells WorkManager to run your worker with the image URI, but only when the device is not in active use.

Get five bites like this every day.

Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.