Coredata on blog.iankulin.com

FriendFace 61 Feedback

Sat, 26 Nov 2022 00:00:00 +0000

As usual after a challenge, I compare my efforts to Paul’s model solution. Just to quickly recap the app, it sucks up some data (Users who have multiple friends) and displays it. The change in this challenge was to convert it to add that data to a Core Data store so that if a future network error prevented accessing new data, it could still display the old.

Merge Policy

The first difference is that Paul adds a merge policy. A Merge policy tells Core how to deal with any constraints defined in the data model. In this app, I’d defined the CachedUser.id as a constraint. The purpose of this is that under normal conditions the app would be picking up mostly the same data each time it started up. We don’t want scabs of duplicate data, so constraining users based on their unique id is smart.

The merge policy tells Core Data how to deal with these conflicts. The policy Paul uses is mergeByPropertyObjectTrump - basically the memory version of an object (in this case the one just provided by the JSON) writes over a previously stored version.

For testing, I had commented out my try? moc.save() otherwise I might have been reminded to do this one. First round to Paul, again.

Data

The data model and additions to the managed object source files were all pretty similar to mine, except that Paul left his id’s as UUID and it seemed to be happy with these being written to, so I need to look into that to understand what I was doing wrong,

As far as copying the data over, Paul did it all in a function in the ContentView - I preferred my concept of having these as methods in CachedUser and CachedFriend. He mentions this, and it sounds like he agrees with me, but it’s a tiny project so no matter.

MainActor

When outlining the challenge, Paul went to a bit of trouble to explain the way to avoid a clash between updating the view (based on the data) and updating the data using await MainActor.run. Without really knowing what I was doing, I put this call after the fetch for the JSON. In Paul’s version he has this inside the fetch when it’s complete. This actually makes more sense - with my version I might be building the Core Data copy before (or even while) it’s being fetched.

Core Data basics – Part Three

Thu, 24 Nov 2022 00:00:00 +0000

If you’re just stumbling across this, perhaps have a look at Part 1 where I layout a simple master/detail app with the data held as arrays of structs, and Part 2 where I convert that into the simplest possible Core Data version. In this post, I’m going to add the mechanics for the one:many relationship - Each Garden can be associated with multiple Plants.

I should also mention I figured out some of this with help from this video from Jonathan Rasmusson.

First step is another Paul hack. If you look in the Garden+CoreDataProperties.swift file where the Garden properties are defined, you’ll see that the plants variable has the type ?NSSet which is not straightforward to work with. We’d prefer it to be an array of Plant so we can easily turn it into a list in SwiftUI ways.

extension Garden {

 @nonobjc public class func fetchRequest() -> NSFetchRequest<Garden> {
 return NSFetchRequest<Garden>(entityName: "Garden")
 }

 @NSManaged public var address: String?
 @NSManaged public var id: UUID?
 @NSManaged public var name: String?
 @NSManaged public var plant: NSSet?
 
 var wrappedName: String {
 name ?? "Unknown"
 }
 var wrappedAddress: String {
 address ?? "Unknown"
 }
 
 var plantArray: [Plant] {
 let set = plant as? Set<Plant> ?? []
 return set.sorted {
 $0.wrappedName < $1.wrappedName
 }
 }

}

Using a computed variable (in this case plantArray), Paul likes to turn it into a Set of Plants, then convert that into an array by sorting it. We have to provide the predicate, but it’s a small price to pay to get the array back. I have concerns about this for a 100K array, but it’s no problem for this app.

Back in our Garden DetailView, it’s now a simple matter to show the plants for a garden in a list under the other garden details.

struct DetailView: View {
 var garden: Garden
 
 var body: some View {
 VStack {
 Text(garden.wrappedName)
 .font(.headline)
 Text(garden.wrappedAddress)
 List {
 ForEach(garden.plantArray, id: \.self) {plant in
 Text(plant.wrappedName)
 }
 }
 }
 }
}

Finally, in the button press to create our sample data, we need to create each of the plant instances then call a method on a garden to add them to that garden.

Button("Sample Data") {
 let garden1 = Garden(context: moc)
 garden1.id = UUID()
 garden1.name = "White Lodge"
 garden1.address = "72 Anderson Street \nRothwell QLD 4022"
 
 let plant1 = Plant(context: moc)
 plant1.name = "Rose"
 garden1.addToPlant(plant1)
 let plant2 = Plant(context: moc)
 plant2.name = "Palm Tree"
 plant2.garden? = garden1
 garden1.addToPlant(plant2)
 let plant3 = Plant(context: moc)
 plant3.name = "Lawn"
 plant3.garden? = garden1
 garden1.addToPlant(plant3)

The .addToPlant() accessor method is a Swift wrapper for some internal Objective C that was generated for us in the same file as the Garden properties. The bad name ‘AddToPlant’ rather than ‘AddToPlants’ is my bad. When I defined the relationship in Garden (in the data model) I should have called it ‘plants’.

Part 1, Part 2

Core Data basics - Part Two

Wed, 23 Nov 2022 00:00:00 +0000

Yesterday I roughed out a master/detail app with a list of gardens, and for each garden a detail screen including some plants. It used arrays of structs for the data. Today I’m going to convert that app to use Core Data, and explain my understanding of each step. This won’t be the entire app - I’m going to include the plants in my data structure, but not actually use them in this version. I’ll save that 1:many relationship stuff for another post.

Once again I need to acknowledge Paul Hudson’s 100 Days of SwiftUI for most of my knowledge of Core Data - much of the code below is lifted directly from his examples. The explanations of what is going on, and any errors, are mine.

Just to remind you, here’s what our working app should look like by the end of this post.

The “Sample Data” button creates the gardens to display. The list above displays them.

The first thing we need to do is to create the data model. This is the description of our data structures - Garden and Plant which in the previous version were structs. In this version they will become classes, but we don’t just write the classes, we define them in an XCode data model.

There’s slightly different language. Instead of structs we have Entities for Garden and Plant, and instead of properties they have Attributes.

While we’re editing the data model, there’s another couple of little jobs to do here. We define the relationship between Gardens and Plants (each Garden can have many Plants, each Plant only belongs to a single garden). We also need to turn Codegen to Manual/None. To see this setting, you need to View|Inspectors|Data Model. If it’s left on “Class Generation” XCode creates a secret file in the build folder that contains the class definitions for Garden and Plant. In this app, I want to change them so we need to have them as part of our project source, which is the next step.

We are going to get XCode to explicitly generate the Managed Object code for our entities, and add it to our project so we can edit it - Editor | Create NSManagedObject. Select both entities and XCode will generate four files and add them to the project navigator. – Each entity has a file with an empty class definition, and a file with an extension containing the @NSManaged property definitions and the fetchRequest method.

Since the properties are (a slightly different to Swift version of) optionals, this file is a good place to make any computed properties to return safely unwrapped versions.

extension Garden {

 @nonobjc public class func fetchRequest() -> NSFetchRequest<Garden> {
 return NSFetchRequest<Garden>(entityName: "Garden")
 }

 @NSManaged public var address: String?
 @NSManaged public var id: UUID?
 @NSManaged public var name: String?
 @NSManaged public var plant: NSSet?
 
 var wrappedName: String {
 name ?? "Unknown"
 }
 var wrappedAddress: String {
 address ?? "Unknown"
 }

}

That’s our classes for the individual bits of data - analogous to the structs - taken care of. But what about the analog for the array? What’s our container?

For this, we need an NSPersistentContainer. The way Paul does things, this is a property of a data controller obect. It links to the data model we defined before.

class DataController: ObservableObject {
 let container = NSPersistentContainer(name: "DataDemo")

 init() {
 container.loadPersistentStores { _, error in
 if let error = error {
 print("Core Data failed to load: \(error.localizedDescription)")
 }
 }
 }

 deinit {
 }

}

In the app definition, instantiate the dataController as an @StateObject, then insert its viewcontext into the Environment. The view context is what we’ll use elsewhere in the app to manipulate the data.

@main
struct DataDemoApp: App {
 @StateObject private var dataController = DataController()
 var body: some Scene {
 WindowGroup {
 ContentView()
 .environment(\.managedObjectContext, dataController.container.viewContext)
 }
 }
}

In the view where we want to access our data, extract the managed object context from the environment and express it as a property of the view. Also in the view, we need a property to access our collection of Gardens. This is another property, with the @FetchRequest property wrapper.

struct ContentView: View {
 @Environment(\.managedObjectContext) var moc
 @FetchRequest(sortDescriptors: [
 SortDescriptor(\.name)
 ]) var gardens: FetchedResults<Garden>

To add data - new gardens, instantiate a new garden with the “context:” initialiser and pass in our managed object context – this is the link to all the persistence code – the data model and so on. When you’re ready for these to be committed to “disk” (so far they are in the collection, but only in memory) call the managed object context’s save() method.

Button("Sample Data") {
 let garden1 = Garden(context: moc)
 garden1.name = "White Lodge"
 garden1.address = "72 Anderson Street \nRothwell QLD 4022"
 let garden2 = Garden(context: moc)
 garden2.id = UUID()
 garden2.name = "Gordon Terrace"
 garden2.address = "95 Learmouth St\nTahara Vic 3301"
 
 try? moc.save()
}

Note that we are dealing with objects now – reference types – so we have to keep creating new objects to add them to the collection. This is contrasted with when I was loading up the sample data with the struct, I could keep recycling it and when I added it to the array each time it was value copied.

To access our data, it’s identical to accessing any collection, except that I’ll use the unwrapped computed properties from earlier.

 @FetchRequest(sortDescriptors: [
 SortDescriptor(\.name)
 ]) var gardens: FetchedResults<Garden>
 
 var body: some View {
 NavigationView {
 VStack {
 List {
 ForEach(gardens, id: \.id) {garden in
 {
 HStack {
 Text(garden.wrappedName)
 Spacer()
 Text(garden.wrappedAddress)
 }
 }
 }
 }

That’s covered the very basics. Here’s the source for this version. The next step will be to deal with the one-to-many relationship between the gardens and plants.

Part 1, Part 3

Core Data basics - Part One

Tue, 22 Nov 2022 00:00:00 +0000

To help me get clear on the Core Data basics (so I can master one of the #100Days challenges), I’ll write a simple master/detail app with arrays of structs, then convert it to Core Data listing out of the steps. Almost everything I know about Core Data, I learned from Paul Hudson’s 100 Days of SwiftUI course - of which I’m up to day 61. So shout out to him. I highly recommend that course, and most of the code you’ll see in this post is either inspired by, or directly copied from 100 Days, except of course the errors - those are mine. This post - Part One - just describes the app and shows the struct/array version.

App Overview

The opening screen is a navigation view of the list of gardens, and a button. There’s a navigation link from each garden item to a detail view which shows the garden details, including a list of plants.

Struct version

First the data. Two structs, Plant, and Garden. Garden contains a list of plants. The gardens state variable lives in the main contentview and is an array of Gardens.

struct Plant {
 var id = UUID()
 var name: String
}

struct Garden {
 var id = UUID()
 var name = ""
 var address = ""
 var plants: [Plant] = []
}

struct ContentView: View {
 @State private var gardens: [Garden] = []

To create the sample data, a button creates the struct instances and adds them to the array.

Button("Sample Data") {
 var someGarden = Garden()
 someGarden.name = "White Lodge"
 someGarden.address = "72 Anderson Street \nRothwell QLD 4022"
 someGarden.plants.append(Plant(name:"Rose"))
 someGarden.plants.append(Plant(name:"Palm Tree"))
 someGarden.plants.append(Plant(name:"Lawn"))
 gardens.append(someGarden)
 someGarden.id = UUID()
 someGarden.name = "Gordon Terrace"
 someGarden.address = "95 Learmouth St\nTahara Vic 3301"
 someGarden.plants = []
 gardens.append(someGarden)
}

The main display of the data is a list in a navigation view. With a link to a detail page.

struct ContentView: View {
 
 @State private var gardens: [Garden] = []
 
 var body: some View {
 NavigationView {
 VStack {
 List {
 ForEach(gardens, id: \.id) {garden in
 NavigationLink {
 DetailView(garden: garden)
 } label: {
 HStack {
 Text(garden.name)
 Spacer()
 Text(garden.address)
 }
 }
 }
 }
 Button("Sample Data") {
 var someGarden = Garden()
 someGarden.name = "White Lodge"
 someGarden.address = "72 Anderson Street \nRothwell QLD 4022"
 someGarden.plants.append(Plant(name:"Rose"))
 someGarden.plants.append(Plant(name:"Palm Tree"))
 someGarden.plants.append(Plant(name:"Lawn"))
 gardens.append(someGarden)
 someGarden.id = UUID()
 someGarden.name = "Gordon Terrace"
 someGarden.address = "95 Learmouth St\nTahara Vic 3301"
 someGarden.plants =[]
 gardens.append(someGarden)
 someGarden.id = UUID()
 someGarden.name = "Powlett Cottage"
 someGarden.address = "11 Bayfield Street\nWhite Beach 7184"
 gardens.append(someGarden)
 someGarden.id = UUID()
 someGarden.name = "Adams Garden"
 someGarden.address = "71 Swanston St\nKanya Vic 3381"
 gardens.append(someGarden)
 }
 }
 .navigationTitle("Data Demo")
 }
 }
}

The DetailView is passed the selected garden. It shows a couple of details from the garden, and a list of plants if there are any.

struct DetailView: View {
 var garden: Garden
 
 var body: some View {
 VStack {
 Text(garden.name)
 .font(.headline)
 Text(garden.address)
 List {
 ForEach(garden.plants, id: \.id) {plant in
 Text(plant.name)
 }
 }
 }
 }
}

So that’s our app. Source is on github here. Really, I could/should have done add/delete/edit but I just wanted something basic as a starting point for the Core Data stuff tomorrow.

Part 2, Part 3

Tough Day

Sun, 20 Nov 2022 00:00:00 +0000

Bad Day at Sea - reddit u/SpaceKen

Day 61 of #100DaysOfSwiftUI is a tough day. It’s the first real big test of Core Data understanding, and I’m finding I didn’t actually understand how the code for Core Data works. For the first time, I’m thinking of going back and redoing the days leading up to it.

To try and get it straight in my mind, here’s how I think Core Data works:

1. it’s a way of persisting instances of objects - not a relational database (even though that’s what’s lying underneath it). I’m sure this is part of what is obstructing my thinking. Relational databases were my bread and butter for many years.

2. Core Data won’t just persist any old objects, you need to define these objects in the Data Model. They will be “NSManagedObjects”

3. In the Data Model you can specify the “CodeGen”. If it’s left on the default “Class Definition” a hidden source file you can’t access is generated deep in the build file so the objects exist - and therefore you can use them.

4. If you set CodeGen to “Manual/None”, it is now your responsibility to create that file. You usually select this, then tell XCode to generate them for you and add them to your project navigator by going in to Editor | Create NSManagedObject subclass. This then allows you to edit those files.

5. To do anything these objects, you need a managaged object context. I’m not real clear on what this is. You create it in the App file, from a data controller that contains an NSPersistantObject. Then you save it to some super global called the environment.

6. To add objects to the collection, you instantiate them using an initialiser that accepts the managed object context as an argument. Then to really persist them (as opposed to just the memory version) you call save() on the object context.

7. To access the objects, you build a fetch request access a collection of them.

8. It gets tricky when there are relationships between the objects.

My plan is to work through my own example of arrays of items vs a Core Data version of the same thing to ensure I’ve got it all straight in my head before coming back to the Day 61 challenge. I don’t feel too bad about this - Paul makes a point that its a tough challenge, and I don’t want to just “get it working” and move on with that uneasy feeling I might have code with errors I just haven’t discovered yet.

CoreData and the Preview

Fri, 04 Nov 2022 00:00:00 +0000

I’ve noticed Paul is inclined to ignore the preview and run his code in the simulator to check its operation. That’s valid, but it seems quicker, and reassuring, to see it in the preview as I type.

This led to a small problem with Day 53 that uses CoreData. When I added a student in the preview, it looked like this, and was immediately followed with a crash report.

It ran fine in the simulator, and in the text for Day 53 there was a comment about adding the managed object context to the preview, but without a hint about how.

I tried a few things - it felt like I should be able to get it from the @Environment somehow, but ended up using this solution from fellow HWS student @Fly0strich.