Fixer of explicitly unwrapped optionals

Filtering by Tag: CoreData

SwiftUI.FetchRequest is lacking dynamic input

Added on by Paul Wood.

Given the new property Wrappers for core Data and the environment variable for managedObjectContext I would expect that the properties would be dynamic in some way to respond to @State, or @ObjectBinding changed that are related to the fetch request the view is managing. currently there is no way to pass something as simple as a NSManagedObjectID to a FetchRequest to populate a new view dynamically based on use section. Nor is it possible to change the attributes of a request (Sorting or Predicate) dynamically based on user input an extremely common use case for Core Data and NSFetchRequest in general.

For example given a List of Int I could have a state that changes them to ascending and descending order

The only way to do this at the moment is an if statement around two FetchRequest that are both built at the view’s startup. Those request would then need to be for the life of that View.

Next I can image a complex query that is built using a user interface with text fields that would build a NSPredicate built on state. Each input could be handled by a SwiftUI view, and have a binding to the output expected. As these outputs change the Fetch request also could change dynamically or only change when the user presses a button.

In short here is the possibility I wish I had:

I’m confident this work is technically possible without first party support using the FetchResults struct and new @Environment(\.managedObjectContext) API

Also my fleeting thought on Twitter and Plea to Luca for future reference :)

I think the ability to support this feature is contingent on the future direction of Property Wrappers out lined here on Swift Evolution

Below is a Gist of my research into the possibility with the current API, using a container view to update a Child view that actually have the list. Each revision compiles, looks correct from the programmers perspective but does NOT render an updated sort order using SwiftUI List view. I hope this misuse of the API (I think I must be a misuse) should be documented in some way before release of SwiftUI. The painful intellectual part is that the binding renders correctly as well as a debug statement that performs the fetchRequest. the fetched results printed from that statement ARE reordered correctly it just does not update the SwiftUI view. So I feel like I’m close but SwiftUI prevents me from displaying the new fetched results for some reason. This code is part of a research project on SwiftUI, Combine with back pressure and CoreData

Lastly I doubt I’ll be alone in trying to have dynamic results with this new API. The framework could give feedback that I am incorrectly using the FetchResults struct.

Some extra Documentation on NSPersistentCloudKitContainer is needed about simulators and devices

Added on by Paul Wood.

This page of Documentation should have a warning saying that a physical device is required to test the automatic syncing of NSPersistentCloudKitContainer

On the page, Mirroring a Core Data Store with CloudKit I can read in the section “Set Up Your Development Environment” A sentence reads “You can run and test Core Data with CloudKit apps using Simulator. You may also test with multiple physical devices logged into the same iCloud account on a good wireless internet connection.” But no explicit warning that the simulator will not have the same experience as a physical device because it does not receive push notifications.

On this page, Synchronizing a Local Store to the Cloud in the Section “Configure the Sample Code Project” a note about using physical devices should be included to see the automatic “live” syncing using push notifications

I had to learn about this via a blog post by Andrew C Bancroft.

I can’t wait to use this feature in iOS 13. Its a great addition to the frameworks and removes a lot of friction of working with CloudKit and CoreData