Archived
ScarriffleandClaude Opus 5
f9bc1965a5
The watch receives the phone's payload over WatchConnectivity and writes it into its own App Group container through the same SnapshotStore, so there is one wire format and one reader. The agenda, the detail screen and the filter all read that; the complications read what the app last wrote, since an extension cannot run a WCSession of its own. Complication timelines land on event boundaries rather than a schedule, so the next appointment flips in the exact minute it changes without spending refresh budget. CalendarrWatchShared holds what both watch targets need, attached to each the way Shared/ is attached to the app and the widgets. recommendations() is implemented because watchOS requires it — iOS has a default, the watch does not, since the complication gallery has to be populated. Found by building, not by reading. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
20 lines
462 B
Swift
20 lines
462 B
Swift
import SwiftUI
|
|
|
|
@main
|
|
struct CalendarrWatchApp: App {
|
|
@State private var model = WatchSnapshotModel()
|
|
|
|
init() {
|
|
// The session has to be live before the first payload arrives, and a
|
|
// complication push can wake this app with no UI on screen at all.
|
|
WatchSnapshotReceiver.shared.activate()
|
|
}
|
|
|
|
var body: some Scene {
|
|
WindowGroup {
|
|
WatchAgendaView()
|
|
.environment(model)
|
|
}
|
|
}
|
|
}
|