Challenge 3: WorkManager vs Foreground Service — Solution

(a) Backing up notes to the cloud once a day
    -> WORKMANAGER. This is deferrable, invisible background work with
    no need for the user to watch it happen — a PeriodicWorkRequest with
    a network constraint is exactly the intended use case.

(b) Playing a podcast episode while the app is backgrounded
    -> FOREGROUND SERVICE. The user is actively listening RIGHT NOW —
    this needs to keep running continuously and immediately, with a
    persistent notification (showing playback controls) that reflects
    ongoing, user-aware activity, not something that can be deferred or
    delayed by battery-saving constraints.

(c) Retrying a failed image upload with exponential backoff
    -> WORKMANAGER. Retrying with backoff on failure is a first-class,
    built-in WorkManager feature (Result.retry() plus its backoff
    policy) — this is squarely deferrable background work, even though
    it might complete relatively quickly.

(d) Showing live GPS navigation directions
    -> FOREGROUND SERVICE. The user is actively watching and relying on
    this in real time while possibly not looking at the app's main UI at
    all (e.g. screen off, or another app open) — it needs to run
    immediately, continuously, and visibly (a persistent notification
    with turn-by-turn info), exactly the "user is watching this right
    now" case WorkManager is not designed for.

Notes:
- The deciding question throughout is the same one from the chapter: is
  this something the user is actively watching/relying on in the moment
  (foreground service), or something that can happen whenever the system
  decides conditions are right (WorkManager)?
- (a) and (c) both being WorkManager cases despite one being scheduled
  and one being reactive-to-failure shows that "periodic" isn't the only
  qualifying trait — any deferrable, non-time-critical background task
  fits, regardless of what triggers it.