Post not yet marked as solved
I'm having the same problem as everyone else, but I want to raise an additional concern.
It is my understanding that the iPhone 8+ image will only be shown to users with a device that has that aspect ratio. So that means that only users of iPhone 8+ or earlier will see those screenshots. BUT, since the app required iOS 17+, they can't run the app.
So providing the screenshots is essentially a case of BAIT AND SWITCH. By supplying the screenshots, the App Store is implying that the app is available when it is not. I don't want to speculate on Apple's motivation for doing this, but it makes ME look like the bad guy here. I don't think I should take the flack for this.
What do you think?
Post not yet marked as solved
You're absolutely right. I was trying to click-and-drag, which wasn't working. Definitely a case of pilot error on my part.
Post not yet marked as solved
Unless the situation has changed recently, it is my understanding that cascade does not work in iCloud+CoreData. Since SwiftData seems to be a layer on top of CoreData, one would suspect that cascade shouldn't work for it either.
This is, I agree, a real pain. In CoreData, there were enough hook functions in NSManagedObject that one could manually handle the cascade operation, but I've been unable to find any suitable hooks that could be used.
Thank you, Quinn. I was sort of afraid of that, because the security-scoped URL includes device-specific information (a UUID-based directory name).
And it gets even worse, because it appears at openURL only works with external (https ??) URLs, not file URLs. (I'm going to file that as a bug report next...) So it looks like I'm going to have to re-evaluate the requirements of my app (and offer a less-capable product as a result).
Post not yet marked as solved
Does
let nilClub: Club? = nil
let noClubPred = #Predicate<Member> { member in
member.club == nilClub
}
work?
Post not yet marked as solved
Hi, DMG,
You're right - that is the obvious way to deal with the issue. I'm an old UIKit guy new to SwiftUI (and SwiftData and Observation Framework) so I was looking for a way to leverage the Observation framework, but a more traditional callback approach will certainly work.
Very helpful. Thanks,
Rick
Post not yet marked as solved
I'm sorry, but this isn't right. localizedStandardContains(_:) provides CONTAINS semantics, not EQUALS semantics. The original poster (and I) want a case-insensitive test for equality. Using localizedStandardCompare(_:) == .orderedSame is not supported by the current (Xcode 15.0 beta 7) version of SwiftData, and the alternative suggested by Xcode's error messages (localizedCompare(_:)) is case-sensitive.
The only thing I can think of at this point (not tested, by the way) is
$0. attribute.localizedStandardContains(str) && str.localizedStandardContains($0.attribute)
which is ridiculous. FB13051739
Post not yet marked as solved
I put together a writeup of the technique I'm using. (Yes, it's kludgy and I would be delighted for someone to offer an improvement or a replacement.)
If the writeup seems long (or insultingly detailed), please forgive me. I find writing this sort of thing helps me clarify my thinking.
Be that as it may, since I can't attach either a Pages file or a PDF to this reply, I moved the writeup to my Dropbox.
https://www.dropbox.com/s/nf2diu6haayn147/Pseudo-Transient%20Attributes.pdf?dl=0
Post not yet marked as solved
I finally worked out a solution to this problem, but it is a real hack. If you're interested in details, I can write it all up.
However, in a nutshell, what I do is as follows:
in any entity which contains an attribute that is used in the computation for the computed property, I use the validateForXXX methods to register changes. (The registration process is part of my CoreDataStack.)
The entity which has the "computed" properties maintains real attributes with the computed values. The entity registers for notification for changes and performs the computations necessary to update the real (stored) values as appropriate.
In this way, I am able to use a stored attribute (which can be the target of the find or sort operation) which is kept up to date. It's definitely kludgy (and requires more infrastructure that needs to be implemented correctly and consistently that I'd like), but I am finding it to be reliable.
Again, I'll prepare a writeup if you're interested.
Post not yet marked as solved
Ah, but if your Mac isn't equipped with a trackpad, a two-fingered swipe isn't possible. I think I'm going to need to implement a contextual menu or something like that.
Another possibility:
Since we need to add (for compatibility with common expectations of Mac UI) click-to-select + delete (or forward-delete) to delete a row, maybe a click-to-select + "something-else" to edit it. For cases where "edit" and "show detail" are similar, "something-else" might be return-key.
Here is my solution:
(1) Using Xcode 12 beta 5, in IB, I set the properties of the split-view controller to be:
Display Mode: Two Columns Beside
Behavior: Tiled (<== this is important)
Then I use the following code for the view controller:
SplitViewController - https://developer.apple.com/forums/content/attachment/957df126-8068-465f-9c00-fe20df3bcd13
It seems like the key to making this work was to change the behavior from "Automatic" to "Tiled".
Post not yet marked as solved
I've been reading some other posts and have the following idea. I'd appreciate any comments about whether you think this is workable:When performing the once-only initial seeding of the Core Data store, explicitly turn off History Tracking. Once the initial records have been saved, turn it back on.Then, the seeded values will never be synched to the cloud, but all new records and all modifications of the seeded records will. And this should occur on all devices sharing the data. Does this sound like it will solve my problem?
