Architect periodic and on-demand sync with WorkManager

WHAT THIS TESTS: Whether you understand WorkManager as the unified deferrable background work API and can avoid duplicating logic across periodic and immediate requests. Interviewers want to see that you know how to use enqueue policies, constraints, and input data to keep the architecture DRY and race condition free.

A GOOD ANSWER COVERS: First, use a single Worker subclass for both paths so sync logic lives in one place. Second, use setInputData to pass a trigger reason flag so the Worker can log or branch if needed. Third, schedule the hourly sync with PeriodicWorkRequest using a unique name and ExistingPeriodicWorkPolicy.KEEP to avoid stacking duplicate periodic jobs. Fourth, handle the push notification by enqueuing a OneTimeWorkRequest under a different unique name with ExistingWorkPolicy.KEEP or APPEND_OR_REPLACE depending on whether you want to drop an in flight manual sync. Fifth, add Constraints such as NetworkType.CONNECTED to both requests so they do not waste battery when offline. Sixth, mention expedited work for the push path if the user experience requires near immediate execution while respecting App Standby buckets.

COMMON WRONG ANSWERS: Creating two separate Worker classes that copy and paste the same sync logic. Using enqueue without an ExistingWorkPolicy, which causes the work queue to grow unbounded every time a push arrives. Using a ForegroundService directly instead of WorkManager, which forces you to manage lifecycle and permissions manually and ignores power management best practices. Using a PeriodicWorkRequest for the push path, which is semantically wrong and introduces unnecessary scheduling overhead. Ignoring constraints entirely, leading to battery drain and ANR risks.

LIKELY FOLLOW UPS: How would you handle retry and backoff if the server is rate limiting? What happens if the periodic work fires while the one time push work is already running? How do you test this Worker, including injection of the repository or API client? Would you use a CoroutineWorker or ListenableWorker, and why? How do you observe the work state to show a sync spinner in the UI?

ONE CONCRETE EXAMPLE: Imagine a mail app that syncs every hour. You define MailSyncWorker that takes input data with key TRIGGER mapping to PERIODIC or PUSH. In Application.onCreate or a dedicated scheduler class, you enqueue PeriodicWorkRequest with a 1 hour repeat interval, constraints requiring an unmetered network, and the unique name mail_sync_periodic. When FCM delivers a new_mail push, the FirebaseMessagingService builds a OneTimeWorkRequest with setExpedited if the user tapped the notification, sets input data to PUSH, and enqueues it under mail_sync_immediate with ExistingWorkPolicy.KEEP. Both paths execute the same doWork block, but the push path might pass a boolean to the repository forcing a full folder refresh instead of an incremental delta.

Source: developer.android.com