And additionally, in the case without selPriv, I end up getting this warning on device when the selection doesn't work:
2023-09-14 10:44:45.305377-0700 NavSplitView[20843:16029318] [Assert] Collection view focus state got out of sync. Expected <SwiftUI.ListCollectionViewCell: 0x13d050a00; baseClass = UICollectionViewListCell; frame = (116 44; 288 44); layer = <CALayer: 0x600002305540>> to be the current managed subview but found <SwiftUI.ListCollectionViewCell: 0x14d01a000; baseClass = UICollectionViewListCell; frame = (116 44; 288 44); alpha = 0; layer = <CALayer: 0x6000023fa520>>.
It doesn't happen when I use the private selection case (but the selection still doesn't highlight).
Post
Replies
Boosts
Views
Activity
As an experiment I tried a private state variable for the selection. Selections are highlighted (but the detail is broken), but as soon as I hook up the onChange, the detail works but the selections fail
struct ContentStringX: View {
let content = [StringItem(item: "Here"), StringItem(item: "There"), StringItem(item: "Everywhere") ]
@Binding var selection : StringItem?
@State private var selPriv : StringItem?
var body: some View {
List(content, selection: $selPriv) { c in
NavigationLink(value: c) {
Text(c.item)
}
}
.onChange(of: selPriv) { new in
selection = selPriv
}
}
}
OK, so I have figured out what was going on in SampleTrip. It turns out that TripListItem includes a NavigationLink so copying that pattern
var body: some View {
NavigationSplitView {
List(players, selection: $selectedPlayer) { player in
NavigationLink(value: player) {
Text(player.shortName ?? "")
}
}
.navigationTitle("Players")
} detail: {
if let p = selectedPlayer {
Text("detail \(p.shortName ?? "")")
} else {
Text("detail empty")
}
}
Now works. So in this case, I don't need to pass in id. Any thoughts on whether using the NavigationLink here is the preferred approach? At least part of the mystery is resolved!
Switching over to another entity that doesn't have an explicit uuid : UUID attribute didn't make a difference. And from what I can tell, by default CoreData entries conform to Identifiable so that doesn't make sense to me.
The code:
@FetchRequest(sortDescriptors: []) private var players: FetchedResults<PlayerEntity>
@State private var selectedPlayer : PlayerEntity?
var body: some View {
NavigationSplitView {
List(players, selection: $selectedPlayer) { player in
Text(player.shortName ?? "")
}
.navigationTitle("Players")
} detail: {
if let player = selectedPlayer {
Text("Do Something")
}
}
}
The list appears, but is not selectable, and the detail view doesn't get presented. I also tried using the same List/ForEach style of the sample code.
How is your post "asked 35 minutes ago" but there are already replies from 6 days ago?
FB9126666
I can confirm the same issue with a catalyst app (running on macOS). Xcode 12.4 macOS 11.1. Same code is working fine on the iOS simulator targets.
I'm surprised because I thought I would have already tested this but at present the receipt is never delivered.
I've updated FB8724409 but can't tell if it has been assigned back to Apple. Testing this against Xcode 12B45b running Simulator Version 12.2 (940.16)
SimulatorKit 597.13.0.1
CoreSimulator 732.18.0.2
And iOS 14.2 in the simulator, the string in section 12 (creation date) is still formatted with the -0700 format, section 1704 (purchase date) is using the Z format, but the expiration date is still incorrect as well. The purchase date, however, is returning the local time but appending Z, rather than correctly converting the local time to UTC.
Replacing with
for case let post as Post in posts {
post.removeFromTags(tag)
post.addToTags(winner)
}
seems to work, although I don't know if that is proper.
same issue here.
FB8724409
FB8711432
It looks like
dateFormatter.dateFormat = "yyyy-MM-dd'T'HH:mm:ssZZZZZ"
works on both string types. Thoughts?
Really happy with my WWDC20 lab "visit". In the test plan, It turns out that if you don't set the Application Region from System Region to a specific region for the different variants, the files generated end up missing information. Then a quick deletion of the app's folder in DerivedData fixed the issue.