Bring back Notifications support with new Scheduler #45
Labels
enhancement
New feature or request
Comments
1 task
Supereg
added a commit
that referenced
this issue
Oct 29, 2024
…ecurrence Rule (#44) # New Task model using SwiftData and Schedule creation using Calendar Recurrence Rule ## ♻️ Current situation & Problem This PR completely rethinks the Scheduler package. We introduce an updated Task model that is completely backed by SwiftData. Further, we provide a new `Schedule` model that provides greater flexibility for formulating recurring events. Instead of formulating events based on intervals using [`DateComponents`](https://developer.apple.com/documentation/foundation/datecomponents), we use the new [`RecurrenceRule`](https://developer.apple.com/documentation/foundation/calendar/recurrencerule) infrastructure introduced with iOS 18. Using a `Schedule`, you can generate a potentially infinite list of `Occurrence`s. A `Task` uses the occurrences of its Schedule to generate `Events`. When events are marked as completed, they are associated with an `Outcome`. Both a `Task` and an `Outcome` can be extended with arbitrary data. This is enabled using the `@Property` macro, that allows to define custom properties on tasks and outcomes using a [`SharedRepository`](https://swiftpackageindex.com/stanfordspezi/spezifoundation/2.0.0-beta.2/documentation/spezifoundation/shared-repository)-backed storage implementation. `Task` are stored in an versioned, append-only store. Modifying the contents of a Task (e.g., instructions, schedules, ...), appends a new Task version and marks it as effective for the specified date. This allows to modify tasks without changing previous events or occurrences. Something that was impossible with the previous implementation. Lastly, the updated Scheduler provides additional support for UI components out of the box. We provide the new `@EventQuery` property wrapper that you can use in your SwiftUI views. It allows to easily and efficiently query Events directly in SwiftUI. Additionally, we provide several, reusable UI components out of the box to visualize events in your application. **Notifications are currently no longer supported with this version of SpeziScheduler: #45 (This is now tackled in #49 which will most likely be merged alongside this PR). An example of how to configure tasks with this new model is depicted below: ```swift import Spezi import SpeziScheduler class MySchedulerModule: Module { @dependency(Scheduler.self) private var scheduler init() {} func configure() { do { try scheduler.createOrUpdateTask( id: "my-daily-task", title: "Daily Questionnaire", instructions: "Please fill out the Questionnaire every day.", category: Task.Category("Questionnaire", systemName: "list.clipboard.fill"), schedule: .daily(hour: 9, minute: 0, startingAt: .today) ) } catch { // handle error (e.g., visualize in your UI) } } } ``` ## ⚙️ Release Notes * New version Scheduler Store using SwiftData. * New Task module using Events and Outcomes. * New Schedule model based on RecurrenceRule allowing for greater flexibility when specifying schedules. * Introduces new UI components to easily visualize events. * New `@EventQuery` property wrapper to easily query events in your SwiftUI view. ### Breaking Changes * This version of SpeziScheduler is not compatible with the previous version. All previously persisted data will be permanently deleted when using this new version. Already scheduled Notifications may currently not be removed and may be continue to be delivered. ## 📚 Documentation The documentation catalog was completely restructured, highlighting all the new API and functionality. ## ✅ Testing New unit and UI tests have been written to verify functionality. We aimed to set a focus on unit tests for fastest possible test execution. ## 📝 Code of Conduct & Contributing Guidelines By submitting creating this pull request, you agree to follow our [Code of Conduct](https://github.com/StanfordSpezi/.github/blob/main/CODE_OF_CONDUCT.md) and [Contributing Guidelines](https://github.com/StanfordSpezi/.github/blob/main/CONTRIBUTING.md): - [x] I agree to follow the [Code of Conduct](https://github.com/StanfordSpezi/.github/blob/main/CODE_OF_CONDUCT.md) and [Contributing Guidelines](https://github.com/StanfordSpezi/.github/blob/main/CONTRIBUTING.md).
1 task
Supereg
added a commit
that referenced
this issue
Oct 29, 2024
# Support for scheduling notifications ## ♻️ Current situation & Problem The newly introduced SpeziScheduler #44 didn't include support for notifications (see #45). This PR adds back this feature, providing several improvements over the previous implementation. A core challenge is that Apple limits the amount of locally scheduled notifications to 64 request at a time. Therefore, we optimize scheduling by applying the overall rules: * Schedules that can be expressed using repeating calendar-based notification triggers are scheduled that way, only ever occupying one request for all its event occurrences. * Otherwise, each event is scheduled individually using an interval-based trigger. In this case we order notification request by event occurrence. Further, we never schedule more than `30` notification at a time and never earlier than 1 month in advance to ensure other modules are still able to schedule local notifications. These settings can be adjusted by manually configuring the `SchedulerNotifications` in your `SpeziAppDelegate` * Scheduled Notifications are updated using background tasks (if necessary). We schedule a background task every week (or earlier if necessary) to update the scheduled notification requests. ## ⚙️ Release Notes * More advanced notification scheduling that tries to reduce the amount of notification request by using repeating notifications triggers (when using the `daily` and `weekly` shorthand initializes of a `Schedule`) and prioritizes event notifications by their occurrence date. * Automatically schedule events as time-sensitive notification if their duration is not `allDay`. * All Task Notifications are automatically put into the same Scheduler group. * Support notification content customization by conforming your Standard to the `SchedulerNotificationsConstraint`. * Automatically present notifications while the app is running in foreground (customize this using the `notificationPresentation` option). * Automatically request provisional notification authorization to schedule notification even without explicit authorization (customize this with the `automaticallyRequestProvisionalAuthorization` option). * A lot of other fixes and improvements. ## 📚 Documentation Added a dedicated configuration section around notifications in the documentation catalog. The documentation of the `SchedulerNotifications` module highlights the necessary steps to set up notifications for your project. ## ✅ Testing Added the `XCTSpeziScheduler` target that provide UI components to visualize scheduled notification requests. We use this in the UI tests to verify that notifications are scheduled as expected. The Test App schedules a repeating daily notification that has its first occurrence 40s after app launch. Additionally we schedule a daily repeating task that starts 1 week after initial app launch to test event-level scheduling. ## 📝 Code of Conduct & Contributing Guidelines By submitting creating this pull request, you agree to follow our [Code of Conduct](https://github.com/StanfordSpezi/.github/blob/main/CODE_OF_CONDUCT.md) and [Contributing Guidelines](https://github.com/StanfordSpezi/.github/blob/main/CONTRIBUTING.md): - [x] I agree to follow the [Code of Conduct](https://github.com/StanfordSpezi/.github/blob/main/CODE_OF_CONDUCT.md) and [Contributing Guidelines](https://github.com/StanfordSpezi/.github/blob/main/CONTRIBUTING.md).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem
#44 introduced a completely new version of SpeziScheduler. This version currently didn't introduce out of the box support for notifications as it was previously supported.
Solution
We found, that the previous SpeziScheduler API exposed some generic notifications API that might have been better but in a more central Spezi package. The goal of the initial #44 PR was to introduce the new Scheduler model. A follow-up PR should be used to investigate how to best integrate notification support with the new Scheduler and evaluate if there is possibility for reuse across the Spezi framework ecosystem.
Additional context
We should investigate what support of backwards compatibility is necessary to make sure the previously scheduled notifications from previous Scheduler versions are automatically removed.
Code of Conduct
The text was updated successfully, but these errors were encountered: