Figured it out, I think. This seems to work:
ZStack {
Rectangle()
.foregroundStyle(.image(image, scale: mapImage.scale * mapZoom))
.offset(mapImage.offset)
.frame(width: scaledImageSize.width, height: scaledImageSize.height)
}
.frame(width: mapSize.width, height: mapSize.height)
.clipped()
Post
Replies
Boosts
Views
Activity
I've been diverted on another project for a bit, so I'm coming back to this after a bit: This answer put me on the right track, I think, but there's something I'm still missing:
If I have a DocumentGroup that drives the main document interface, and I want to use WindowGroup to display auxiliary information about a particular model, those two root-level objects need to share the same SwiftData ModelContext, no?
But DocumentGroup auto-injects the ModelContext through the (editing: .encounterList, migrationPlan: EncounterListMigrationPlan.self) initializer.
How can I then share that context with the WindowGroup? I can get the binding to the id just fine, but I can't figure out how to load the model from that point.
In that example, are you able to affect changes to the NavigationBar of the enclosing NavigationView? That's the root of the problem I'm having. I can get the theme to propagate to most views in the app, but can't seem to make the existing NavigationBars update. If a given modal is dismissed and reopened, it picks up the new theme, but that doesn't help the ones that are on the screen at the time of change, and nothing short of killing and restarting the app seems to cause the MainView's NavigationBar to invalidate.
It's worth noting that I'm using UINavigationBar's appearance proxy to set the nav bar styling. I'm guessing this isn't playing nicely with the SwiftUI view lifecycle, but I can't figure out any other way to style the nav bars.
I should have been clearer. Storage of the theme preference isn't an issue (user data, including the theme choice, is stored in a separate persistent storage container). It's how to trigger the invalidation and redrawing of the entire App UI (all views) on the change.
That doesn't really answer my specific question, but I'm inclined to give you the checkmark because it eventually led me to catch the real problem, which was that I was attaching my fullScreenCover to the NavigationView, not the contents of the NavigationView.
However, for anyone else trying to do this, it's critical to note that simply putting a fullScreenCover over the app contents isn't enough. Because the fullScreenCover is animated. This means that all someone has to do to see the main screen of the app for a moment (long enough to read some content!) is kill the app and restart it.
Anyone know of a way to tell fullScreenCover to not animate?