Android Worker: For Deferrable Background Tasks

WHY IT EXISTS: Before WorkManager and its Worker class, reliable background processing on Android was a complex mix of APIs like JobScheduler, FirebaseJobDispatcher, and AlarmManager, each with its own limitations and compatibility issues. Worker was created to provide a single, consistent, and backward-compatible API to handle guaranteed, deferrable background tasks without the boilerplate.

THE MENTAL MODEL: Think of a Worker as a durable to-do item you hand to the Android operating system. You tell the system, "Here's a task, and here are the conditions it needs to run, like network access. Please get it done whenever is best for the device's health, even if my app isn't running." The system then takes full responsibility for its execution.

HOW IT WORKS: You define a custom class that extends Worker and place your background logic inside the doWork() method. This method returns a Result: success, failure, or retry. To run it, you create a WorkRequest, such as a OneTimeWorkRequest or PeriodicWorkRequest. You can attach Constraints to this request, like requiring network connectivity or device charging. Finally, you enqueue this request with the WorkManager service, which intelligently schedules and executes your Worker based on the constraints and system health.

WHEN TO USE IT: Use a Worker for tasks that are important and must eventually complete, but don't need to run right now. It's perfect for work that can be deferred until conditions are optimal. Good examples include uploading analytics, syncing app data with a remote server, or applying filters to a saved image in the background.

WHEN NOT TO USE IT: Do not use a Worker for tasks that must execute immediately and are tied to a user interaction; use coroutines or threads scoped to your UI for that. Avoid it for tasks that need to run at an exact time, as AlarmManager is better suited for that. For long-running, user-initiated tasks like music playback or navigation, a foreground service is the correct tool.

ONE CANONICAL EXAMPLE: A classic use case is uploading a user's new profile photo. The app creates a OneTimeWorkRequest for an UploadWorker with a constraint that network must be available. WorkManager enqueues the task. If the user loses their connection or closes the app, WorkManager safely holds the request. When the device is online again, WorkManager executes the UploadWorker to complete the upload, guaranteeing the photo gets sent without requiring the app to be open or the user to wait.