Challenge 2: A Constrained Periodic Worker — Solution

val constraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .setRequiresCharging(false)
    .build()

val periodicSyncRequest = PeriodicWorkRequestBuilder<LogSyncWorker>(6, TimeUnit.HOURS)
    .setConstraints(constraints)
    .build()

WorkManager.getInstance(context).enqueue(periodicSyncRequest)

// What happens if the network constraint isn't met when the 6-hour
// interval elapses:
// WorkManager does NOT skip that scheduled run entirely — instead, it
// holds the work as pending and waits until the constraint (a connected
// network, in this case) is actually satisfied, then runs it as soon as
// that happens. The work isn't lost or silently dropped; it's simply
// delayed past its originally intended interval mark until conditions
// allow it to run. Once it does run, the periodic schedule continues
// from there for the next interval.

Notes:
- setRequiresCharging(false) is written explicitly here even though
  false is the default, purely to make clear the intent (this task
  should run regardless of charging state) rather than leaving it
  implicit — Constraints.Builder() without any charging call would
  behave identically.
- PeriodicWorkRequestBuilder<LogSyncWorker>(6, TimeUnit.HOURS) reuses
  the SAME LogSyncWorker class from Challenge 1 — the same Worker class
  can back either a one-time or periodic request, since the scheduling
  behavior is entirely determined by which WorkRequest type wraps it,
  not by anything in the Worker class itself.
- 6 hours is safely above WorkManager's enforced 15-minute minimum
  interval for periodic work, so no adjustment or warning would occur
  here.