Exercise 1: requestLocationAndNotify() — Requesting Authorization Then Conditionally Scheduling — Possible Solution
============================================================================================================================

func requestLocationAndNotify() async {
    let center = UNUserNotificationCenter.current()
    let granted = (try? await center.requestAuthorization(options: [.alert, .sound, .badge])) ?? false

    if granted {
        let content = UNMutableNotificationContent()
        content.title = "Permission Granted"
        content.body = "You'll now receive task reminders."

        let trigger = UNTimeIntervalNotificationTrigger(timeInterval: 5, repeats: false)
        let request = UNNotificationRequest(
            identifier: "permission-granted-confirmation",
            content: content,
            trigger: trigger
        )

        UNUserNotificationCenter.current().add(request)
    }
}

HOW IT WORKS: The function first awaits a real
center.requestAuthorization(options:) call, matching the chapter's own
established pattern - try? converts a thrown error into a real nil,
and ?? false provides a safe, real fallback so granted is always a
plain, non-optional Bool regardless of whether the request itself
succeeded, failed, or threw.

The real if granted check ensures the notification is only actually
scheduled when the user genuinely approved the permission request -
attempting to schedule a notification after a denied or still-pending
request would simply never display anything to the user anyway, so
the check avoids doing pointless real work in that case. When granted
is true, the function builds a real UNMutableNotificationContent, a
UNTimeIntervalNotificationTrigger firing after 5 real seconds, wraps
both in a UNNotificationRequest with a real, specific identifier, and
adds it to the real UNUserNotificationCenter, exactly following the
chapter's own scheduleReminder(for:) pattern.

ANSWER: requestLocationAndNotify() awaits UNUserNotificationCenter's
own real requestAuthorization(options:) call, safely defaults granted
to false on any error via try?/??, and only builds and schedules a
real confirmation notification when granted is actually true -
correctly gating the scheduling step behind the real permission
result.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly implements the real authorization-then-conditional-
scheduling flow using the chapter's own established UserNotifications
API patterns, only scheduling work that would actually be visible to
the user.