Swift5-7 on blog.iankulin.com

ChatGPT's code writing

Sun, 11 Dec 2022 00:00:00 +0000

This week, the internet has been all about ChatGPT, the rather remarkable natural language AI with a very large model. If you’re a twitter user, you were probably amazed, but now eventually tired of seeing examples of it’s output. I’ll add to that with an example of a SwifUI CoreData based todo app it wrote for me from a single sentence prompt below. Rather than look at other people’s examples you should definitely go and play with it yourself - it is very impressive. Along with the image based AI’s it’s made 2022 into a historical year for AI.

ChatGPT will write software. I can’t see it replacing developers, but it seems likely there’ll be a bunch of interesting tools to come over the next few years. I feel like the first big effect will be the volume of mediocre internet content will increase dramatically as it is pretty great at run of the mill copy-writing. I’d like to assure my readers that all my mediocre internet content will continue to be human written - with the exception of most of the art, and the code example below :- )

write swiftui code for a todo application where the items reoccur after a certain number of days. The items are shown in a list and the user can navigate to a detail view.

me

Here is an example of SwiftUI code for a todo application where the items reoccur after a certain number of days:

ChatGPT

struct TodoItem: Identifiable {
 let id = UUID()
 let task: String
 let dueDate: Date
 let repeatInterval: Int // number of days until the task reoccurs
}

struct TodoList: View {
 @State var items = [TodoItem]()

 var body: some View {
 List(items) { item in
 NavigationLink(destination: TodoDetail(item: item)) {
 Text(item.task)
 }
 }
 }
}

struct TodoDetail: View {
 let item: TodoItem

 var body: some View {
 VStack {
 Text(item.task)
 Text("Due: \(item.dueDate, formatter: DateFormatter.mediumDate)")
 Text("Reoccurs every: \(item.repeatInterval) days")
 }
 }
}

In the TodoList view, a List is used to display the todo items. Each item in the list is wrapped in a NavigationLink that takes the user to a TodoDetail view when tapped. The TodoDetail view displays the task, the due date, and the repeat interval for the selected todo item.

You can modify this code to suit your specific needs, such as adding features to add or delete items, or changing the layout and appearance of the views.

ChatGPT

That’s pretty cool. I don’t think that DateFormatter.mediumDate is a thing, so I changed that line to:

Text("Due: \(item.dueDate, style: .date)")

It’s okay ChatGPT, I get confused about the variety of ways to change dates too.

great. show me the content view code that contains the TodoList and has a button to add items.

me

Here is an example of a ContentView that contains a TodoList and has a button to add items:

ChatGPT

struct ContentView: View {
 @State var items = [TodoItem]()

 var body: some View {
 VStack {
 TodoList(items: $items)
 Button(action: {
 // add new todo item here
 }) {
 Text("Add Item")
 }
 }
 }
}

In this code, the ContentView contains a TodoList and a Button. The TodoList is initialized with the items array, which is marked as @State so that it can be modified in response to user actions. The Button has an action closure that is executed when the button is tapped. You can add code inside this closure to create a new TodoItem and add it to the items array.

You can modify this code to suit your specific needs, such as changing the layout and appearance of the views, or adding features to delete items from the list.

ChatGPT

To let this compile, I commented out the Preview and changed the items property in the top of the TodoList view to a binding:

struct TodoList: View {
 @Binding var items: [TodoItem]

thank you. what would the code for adding an item look like

me

Here is an example of code that you can use to add a new TodoItem to the items array when the button is tapped:

ChatGPT

struct ContentView: View {
 @State var items = [TodoItem]()

 var body: some View {
 VStack {
 TodoList(items: $items)
 Button(action: {
 let newItem = TodoItem(task: "New Task", dueDate: Date(), repeatInterval: 7)
 items.append(newItem)
 }) {
 Text("Add Item")
 }
 }
 }
}

In this code, the Button has an action closure that creates a new TodoItem with the task “New Task”, a due date of the current date, and a repeat interval of 7 days. The new item is then appended to the items array.

You can modify this code to suit your specific needs, such as prompting the user for the task name and due date, or changing the default repeat interval. You can also add additional logic to handle errors or validation failures when creating the new item.

ChateGPT

This all runs and the add item works, but the NavigationLink to get to the detail view does not. Let’s wrap it in a NavigationView to fix that.

struct ContentView: View {
 @State var items = [TodoItem]()

 var body: some View {
 NavigationView {
 VStack {
 TodoList(items: $items)
 Button(action: {
 let newItem = TodoItem(task: "New Task", dueDate: Date(), repeatInterval: 7)
 items.append(newItem)
 }) {
 Text("Add Item")
 }
 }
 }
 }
}

I went on to ask it to change this to core data for persistence, but as I wanted the app to be more and more complex, it needed me to fix more and more problems, and became less fun.

Sharing is caring

Sat, 10 Dec 2022 00:00:00 +0000

Continuing on with the demo project from yesterday, in which we used the ImageRenderer class to turn a view into an image, today we want to let the user share it somehow.

Typically, apps have a button using the square.and.arrow.up SF Symbol to share something from the current screen. It’s probably not an accident that it’s literally the first symbol in the app.

Pressing it generally opens the “share sheet” which has options for opening whatever is being shared in another app, printing it, saving it to photos, or whatever.

Here’s our ticket app from a couple of days ago (the TicketView is unchanged). We’re still using ImageRenderer() to make the image version of the view in OnAppear(), but this time there’s a “sharelink”.

struct ContentView: View {
 private var ticketView = TicketView()
 @State private var image: Image?
 
 var body: some View {
 VStack {
 Spacer()
 ticketView
 Spacer()
 
 if let image = image {
 ShareLink(item: image, preview: SharePreview("View",image: image)) {
 Label("Share", systemImage: "square.and.arrow.up")
 }
 }
 
 }
 .padding()
 .onAppear {
 let renderer = ImageRenderer(content: ticketView)
 if let uiImage = renderer.uiImage {
 image = Image(uiImage: uiImage)
 }
 }
 }
}

If we click on the share link, it looks like this:

The little thumbnail and the word “View” at the top of the share sheet is from the preview parameter in our call.

ShareLink(item: image, preview: SharePreview("View",image: image)) {
 Label("Share", systemImage: "square.and.arrow.up")

Since this is an image, perhaps you were expecting a “Save image” option? That’s the most likely thing we’d want to do with an image, but it’s not there. The reason is that saving an image to the users camera roll requires a specific permission. In the app settings, choose “Info” then right click on the entries and “Add Row”. Search for / add the key “Privacy - Photo Library Additions Usage Description”.

The text you add in the description is what the app will show to the user when the dialogue pops up asking the user if it’s okay to give this app the permission to save photos.

If we go back and and try again to share the ticket, we’ve now got the options to “Save Image”. If we choose that for the first time, we’ll be asked to grant permission to this app.

If the user chooses OK, then it will be saved to photos:

Clean code

Fri, 09 Dec 2022 00:00:00 +0000

I’ve been listening to the latest episode of the Empower Apps podcast, this one with Jill Scott talking about “Humane” development - in the sense of being humane to whoever (probably you) is going to be reading this code in the future. It helped me clarify my thoughts about a couple of things.

None of these ideas are particularly new or groundbreaking, and although I think of them as my personal style, they are very common, and in Swift could be regarded as part of the culture. Some of these concepts support each other, some represent a trade off between two opposing ideas that require us to make a choice.

The Custom at the Time

If other people or bots are going to read your code, or you need to comprehend theirs, there is a lot of value in following the conventions in the language of community you work in. It helps in a couple of ways - 1) you are not expending energy deciding if equals signs should have a space each side, and 2) fluency of reading and writing will improve.

Natural Language

If it’s possible to make choices in a piece of code to make it read more like a description of what is happening, then usually do that. Swift (and probably other modern languages - I wouldn’t know) has some great language features to support this. For example:

answer = resultOf(6, plus: 7)

I also appreciate the Swift convention of using auxiliary verbs. I think isPaused or hasCompleted is clearer that paused or completed.

Decomposed

There’s probably a reason why paragraphs exist in writing, and are about the length they usually are, deep in the science of how memory works in humans and the interplay between working memory and what else goes on in comprehending something.

I start to get uncomfortable if a chunk of code I’m trying to understand or write is more than a couple of 13" laptop screens long. I thought code folding would help but haven’t really found that. I aim to have each chunk (I’m using “chunk” for function, method, computed property etc) express a single idea. If part of it is getting long, I consider if that can be removed somewhere else and replaced with a helpful function name in the piece I’m working on.

Less Magic

When I’m working with some code, I don’t want it to need too much context to understand. This principle means anything used in this code should come in through the obvious interface. Global variables, environment variables, or stuff captured from the enclosing scope are undesirable. If I use them, I try and put them near the top since that’s where people (me) look when they encounter something part way through the code and don’t know where it came from.

In an ideal world, I could grab a piece of code and paste it into a gist to share here and it would be comprehensible.

Evaporated Comments

I doubt I invented this, but I haven’t seen it mentioned anywhere else either. The way I most commonly use comments is to clarify my thoughts before I write any code, something like:

func sendFile(fileName: String, link: NetworkTube) -> SendResultCode {
 // check link is operational
 // attempt to open file
 // step through each line sending it, wait for ack 
 // close file
 // return code
}

Then as I flesh out the function, I delete the comment if the code is straight forward. Usually this results in all of the comments being deleted. In my Swift code, comments are quite rare. Where there are comments, it’s probably a sign I need to name things better.

I just went back through the code for that apps I actually use on my phone, and these are the only comments I could find outside of a header.

var fractionDue: Double {
 // when a habit is overdue, or due now, the fractionDue is 1.0
 // when it's not due at all - just been done, the fractioDue is 0.0
 if isDueNow {
 return 1.0
 } else {
 let daysSinceDone = Date().timeIntervalSince(lastDone) / 86_400
 assert(daysBetweenCompletions > 0.0)
 return daysSinceDone / daysBetweenCompletions
 }
}

This is a computed variable in a “Habit” struct. I wanted to have little ticks next to each habit when they were done, which would slowly fade to be completely gone when this habit was due again. To achieve this I needed to calculate an opacity value for the tick. I think it’s fair to say this needs re-working. I don’t recall if I wrote the comment first, or put it there later recognising the code wasn’t self explanatory - it could have been either.

I’m not sure I could fix this to the point it wouldn’t need a comment at all. There’s a couple of name changes that would help. I think daysSinceDone would be better as daysSinceLastCompleted, and instead of calling the property fractionDue, I might call it freshness. Instead of dividing the time interval by 86,400 I could have a millisecondsToDays()function.

ImageRenderer()

Thu, 08 Dec 2022 00:00:00 +0000

ImageRenderer() is a SwiftUI class that creates an image from a view. You just initialize it with the view, then extract a cgImage (Core Graphics) or uiImage that can be cast to a SwiftUI Image.

I’ll need a view to work with, so here it is; a crude version of my behaviour ticket.

struct TicketView: View {
 var body: some View {
 ZStack {
 Color(.cyan)
 .frame(width: 300, height: 350)
 VStack {
 Text("Fred Bloggs")
 .font(.largeTitle)
 Text("")
 HStack {
 Text("Putting rubbish in the bin")
 Image(systemName: "trash")
 }
 .foregroundColor(.purple)
 Text("")
 Text("Green Faction")
 Text("")
 Text("")
 Text("\(Date().formatted())")
 }
 }
 }
}

Here it is, with a couple of buttons underneath:

I’ve assigned the view to a property of my content view, then displayed it along with the buttons. The first button saves the image to an @State and the second one displays it if it exists.

struct ContentView: View {
 private var ticketView = TicketView()
 @State private var image: Image?
 @State private var showImage = false
 
 var body: some View {
 VStack {
 Spacer()
 ticketView
 Spacer()

 Button("Save Image") {
 let renderer = ImageRenderer(content: ticketView)
 
 if let uiImage = renderer.uiImage {
 image = Image(uiImage: uiImage)
 }
 }.padding()
 
 Button("Toggle image") {
 withAnimation {
 showImage.toggle()
 }
 }
 if showImage {
 if let image = image {
 image
 .resizable()
 .scaledToFit()
 }
 }
 
 }
 .padding()
 }
}

If we save the screen:

Button("Save Image") {
 let renderer = ImageRenderer(content: ticketView)
 
 if let uiImage = renderer.uiImage {
 image = Image(uiImage: uiImage)
 }
}.padding()

Then it can just be inserted in the view same as any bitmap image by hitting the Toggle Image button.

Regex to split a string with two different characters

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

I’m working on the behaviour tickets app, and wanted a visually functional version to share with stakeholders this week to get some feedback. As usual in this situation, I’m pressed for time so feeling the pressure to take some liberties with code quality that I’ll come back and fix one day.

In a salient lesson of why that’s usually a bad idea, I’ve ended up googling to try and understand regex instead of writing code.

Here’s the problem I was trying to quickly solve. I’ve used a string for what should probably have been a struct. It looks like this:

let myString = "Some behaviour (expectation)"

Its super easy to combine values together into a string, but substantially more difficult (and dangerous) to extract them out again. I want to get "Some behaviour" and "expectation".

There is a String.split() function that takes a separator and returns an array of the strings split on that. That could work in this case, but I’d have to split a couple of times since I’m using two different separators. Swift 5.7 released in 2022 introduced a regex (regular expression) type, and this can be used as the argument for the split() method. Sounds perfect. Here’s the code that I ended up with:

let myString = "Some behaviour (expectation)"
let regex = /\ \(|\)/

let splits = myString.split(separator: regex)

print(splits)
// ["Some behaviour", "expectation"]

I think it’s fair to say that regex is powerful, but not intuitive. There are many online tools to help with this. But let me step through building this expression to give you an idea of what’s going on.

The first thing is that the expression is enclosed in two forward slashes. So if we just wanted to split on lower case ‘o’ the expression would be /o/

let myString = "Some behaviour (expectation)"
let regex = /o/

let splits = myString.split(separator: regex)

print(splits)
//["S", "me behavi", "ur (expectati", "n)"]

But we want to split on an opening bracket. You might think /)/ would work, but brackets are part of the regex syntax, so they have to be escaped. This is done with a back slash.

let myString = "Some behaviour (expectation)"
let regex = /\(/

let splits = myString.split(separator: regex)

print(splits)
["Some behaviour ", "expectation)"]

I don’t want that space at the end of “Some behaviour " so I’ll add that to the regex. Spaces are not allowed at the start of a regex, so that needs to be escaped too.

let myString = "Some behaviour (expectation)"
let regex = /\ \(/

let splits = myString.split(separator: regex)

print(splits)
// ["Some behaviour", "expectation)"]

To match the end bracket, we’ll need to add an OR to our expression. In regex, this is a | (pipe), and of course we need to escape the bracket again.

let myString = "Some behaviour (expectation)"
let regex = /\ \(|\)/

let splits = myString.split(separator: regex)

print(splits)
["Some behaviour", "expectation"]

I played with this in an Xcode playground. I normally don’t use them because I love the iCloud sync that I get with the Playgrounds app to my iPad, but it seems like the app version is not on Swift 5.7 yet.

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.

61 Done

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

I think I’ve finally completed the minimum work for Day 61 of #100DaysOfSwiftUI. The task was to suck up some data in JSON, decode it. back it up into a Core Data graph then display the data from the Core Data.

I got stuck on dealing with the one:many relationship and had to revisit that from a different source to get my head around it, after that it was straightforward. Other small problem I ran into was that I created the id in the CachedUser as a UUID from (newly formed) habit. Then when I went to copy it in from the JSON version, it wouldn’t let me. When I realised my mistake and changed it in the data model, I still could not figure out why it wasn’t working - but of course I hadn’t regenerated the code for the ManagedObject. I just had to change the property type in the already generated code from UUID to string and I was back in business.

There are five ominous looking, indecipherable messages in the console log, which I assume are related to Core Data, and I think may have begun after I changed the data model and didn’t regenerate the NSManagedObjects. The app seems to work perfectly, but as usualy, this leaves me with an uneasy feeling of not understanding everything going on that I couldn’t tolerate in a production app.

I’m looking forwards to seeing Pauls solution for this one - I was out of my depth for a while, but think I’m on to it. I might even pause on the course and build a better add/delete/edit app with a one:many in Core Data just to ensure I’ve really got the basics of this topic under my belt.

Source

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

Something weird 'append

Mon, 21 Nov 2022 00:00:00 +0000

I’m noodling around making sure I understand how Core Data works. Thought I’d start with a master/detail app with an array of structs, then replicate it in a Core Data implementation. I’m using an array of this struct for my data:

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

And I thought this code to load up some sample data was pretty sweet.

Button("Sample Data") {
 var someGarden = Garden()
 someGarden.name = "White Lodge"
 someGarden.address = "72 Anderson Street, \nRothwell QLD 4022"
 gardens.append(someGarden)
 someGarden.name = "Gordon Terrace"
 someGarden.address = "95 Learmouth Street\nTahara Vic 3301"
 gardens.append(someGarden)
 someGarden.name = "Powlett Cottage"
 someGarden.address = "11 Bayfield Street\nWhite Beach Tas 7184"
 gardens.append(someGarden)
 someGarden.name = "Adams Garden"
 someGarden.address = "71 Swanston Street\nKanya Vic 3381"
 gardens.append(someGarden)
}

But, no. This is what happens:

The reason I thought this was okay was that structs are value types in Swift. When I pass a struct in a function or method, it’s actually a copy at the other end. I could prove this by mutating the array copy and checking the original.

Button("Sample Data") {
 var someGarden = Garden()
 someGarden.name = "White Lodge"
 someGarden.address = "72 Anderson Street, \nRothwell QLD 4022"
 gardens.append(someGarden)
 gardens[0].name = "Mutated"
 print("Array: \(gardens[0].name)")
 print("Local: \(someGarden.name)")
}

Prints:

Array: Mutated
Local: White Lodge

So clearly I do understand structs/reference types correctly. They are different structs. Also, if structs were somehow reference types, they should have all had the data from the last garden, not the first one.

You’d might be thinking (as I did), perhaps the error is in the view code. That’s easily checked. I forced the second one by creating a new struct, it works correctly and is in the correct position so clearly the view code is working.

The code mutating someGarden is getting run, so it’s not like the compiler’s eliminated those lines somehow. Also it is getting the number of entries correct - they are just somehow linking back to the first entry.

It seems impossible! This is always the way with good bugs.

I’m almost tempted to ask for help.

Before one does that, it’s always a good idea to boil things down to the essence of the problem. Playgrounds is an excellent tool for such an endeavor. I just need the simplest version of an array of structs. Here’s what I came up with:

import Foundation

struct Animal {
 var name: String = ""
}

var animals: [Animal] = []

var animal1 = Animal()
animal1.name = "Cat"
animals.append(animal1)
animal1.name = "Dog"
animals.append(animal1)

print(animals)

Produces the output:

[Page_Contents.Animal(name: "Cat"), Page_Contents.Animal(name: "Dog")]

Grrr. It turns out Swift works perfectly.

In the screenshot above, where I’ve broken on line 52, I couldn’t actually see how to inspect the gardens array. Perhaps I’d be better with the classic print() debugging instead.

[DataDemo.Garden(id: 0725A8FC-D410-4A2C-B925-C34340F25B05, name: "White Lodge", address: "72 Anderson Street, \nRothwell QLD 4022", plants: []), DataDemo.Garden(id: CF30FA66-A2F2-44FB-A6E0-A22E93492578, name: "Gordon Terrace", address: "95 Learmouth Street\nTahara Vic 3301", plants: []), DataDemo.Garden(id: 0725A8FC-D410-4A2C-B925-C34340F25B05, name: "Powlett Cottage", address: "11 Bayfield Street\nWhite Beach Tas 7184", plants: []), DataDemo.Garden(id: 0725A8FC-D410-4A2C-B925-C34340F25B05, name: "Adams Garden", address: "71 Swanston Street\nKanya Vic 3381", plants: [])]

Okay, so the bug I’ve been trying to fix, is not the bug at all. The array is working exactly as intended, it’s my view that’s the issue somehow.

And it’s not just a general problem with the view - it’s a problem with the view that goes away if I create a new Garden struct instead of recycling one… Simultaneously I have these two thoughts:

When I create a new struct, it gets a fresh UUID
What was that console spam message I’ve been ignoring? Oh yeah, it was ForEach, UUID, HStack>>: the ID 0725A8FC-D410-4A2C-B925-C34340F25B05 occurs multiple times within the collection, this will give undefined results!

You can guess the rest, my ForEach is using the UUID:

List {
 ForEach(gardens, id: \.id) {garden in
 HStack {
 Text(garden.name)
 Spacer()
 Text(garden.address)
 }
 }
}

If I fix the ids:

And that’s how you waste a hour fixing a bug the framework warned you about in the first five minutes.

Console spam - No wall clock alignment

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

When I was working on the Day 60 app, I noticed I kept getting a message in the console “No wall clock alignment provided at SwiftUI/ResolvableStringAttribute.swift:86” every time I went into the detail view. Via elimination by commenting bits out, I’ve narrowed it down to a date formatting call. Here is the code to reproduce it in Xcode Version 14.0.1, Swift 5.7.0.127.4

struct ContentView: View {
 var body: some View {
 Text("Date: \(Date(), style: .date)")
 }
}

It’s to do with the style - if I change it to .time or .relative the message does not appear.

I assume an Apple programmer has checked for something on line 86 of ResolvableStringAttribute.swift and unexpectedly found it missing. If I search for that file on my system, it doesn’t appear to be here, so I guess the SwiftUI source is not part of the XCode installation.

Googling the error only produces a single result - a reddit user asking for help on the message and being told not to worry about the noise coming from Apple frameworks if everything’s working okay. The question is from five months ago and has a different line number - so presumably from an earlier version of SwiftUI.

Since it can be reproduced with such a tiny code snippet, and it occurs in every simulator I tried it on, it may be easy to reproduce, and therefore fix. So without really knowing the exact guidelines, but with encouragement from Apple, I filed my first Radar.

FriendFace

Mon, 14 Nov 2022 00:00:00 +0000

The Day 60 Milestone is a demo app that vacuums up some JSON and displays it in a list in a NavigationView that links to a details page. Nothing super strenuous, the steps were something like this:

Download the JSON and have a look at the structure. Firefox has a simple JSON viewer built in, so it was straightforward to see this is an array of users, which along with some (mostly string) properties contains an array of tag strings, and another array of friends.

Build the structs for these.

import Foundation

struct User: Codable {
 var id: String
 var isActive: Bool
 var name: String
 var age: Int
 var company: String
 var email: String
 var address: String
 var about: String
 var registered: Date
 var tags: [String]
 var friends: [Friend]
}

struct Friend: Codable {
 var id: String
 var name: String
}

The date you can see in the JSON is in the ISO-8601 format - and @twostraws gives the hint about using the dateDecodingStrategy for it.

Fetch the data. I made this a .task attached to the list, I didn’t notice it loading multiple times, but Paul did caution about this, so the code checks if the array is empty before calling fetching the JSON.

.task {
 if users.isEmpty {
 await fetchUsers()
 }
}

Process the data into our structs. Since they are codable, this is a bit of a joy. I’d made an error and the JSON wasn’t loading, but I could not see what it was. I fixed this by nesting my do/catch blocks. It seems a bit unwieldy - I feel like I should be able to do several risky steps and have the catch catch all the errors, but it didn’t seem to be. This code works fine, but I feel it could be improved.

 func fetchUsers() async {
 guard let url = URL(string: "https://www.hackingwithswift.com/samples/friendface.json") else {
 print("Invalid URL")
 return
 }

 do {
 let decoder = JSONDecoder()
 decoder.dateDecodingStrategy = .iso8601

 let (data, _) = try await URLSession.shared.data(from: url)
 do {
 let decodedUsers = try decoder.decode([User].self, from: data)
 users = decodedUsers
 } catch {
 print(error)
 return
 }

 } catch {
 print(error)
 return
 }

 }

Note the square brackets for [User] - we’re decoding an array of users.

Display it in the list, with an NavigationLink to the UserDetails view.

struct ContentView: View {

 @State private var users = [User]()

 var body: some View {
 NavigationView {
 List(users, id: \.id) { user in
 NavigationLink(destination: UserDetail(user: user)) {
 VStack(alignment: .leading) {
 Text(user.name)
 .font(.headline)
 Text(user.isActive ? "Active" : "Not active")
 }
 }
 }
 .task {
 if users.isEmpty {
 await fetchUsers()
 }
 }
 .navigationBarTitle("FriendFace")
 }
 }

Show the user details. This is where I started going off script. The user is passed into the detail view. I used a Form because the layout looks a bit nice, and the Friends is a little list.

The script departure was wanting to have a profile pic. As described yesterday, I used an AsyncImage for this. I would have liked to have cached the image so it doesn’t re-fetch when you go out of a user and back in (this would have solved the problem of the random image I described yesterday as well) and fiddled around with trying to save a .snapshot of the AsyncImage view - but then decided I should be moving on instead of cracking that particular procrastination nut, especially because of this parting advice from Paul.

Tip: As always, the best way to solve this challenge is to keep it simple – write as little code as you can to solve the challenge, and for you to feel comfortable that it works well.

struct UserDetail: View {

 let user: User

 var body: some View {
 Form {
 Section {
 HStack {
 Text(user.name)
 .font(.headline)
 .frame(maxWidth: .infinity, alignment: .center)
 }
 }
 AsyncImage(
 url: URL(string: "https://randomuser.me/api/portraits/men/\(nameHash).jpg"),
 scale: 3
 ) { image in image
 .resizable()
 .scaledToFit()
 } placeholder: {
 ProgressView()
 }

 Section {
 Text("Age: \(user.age)")
 Text("Company: \(user.company)")
 Text("email: \(user.email)")
 Text("Address: \(user.address)")
 Text("Registered: \(user.registered, style: .date)")

 }
 Section(header: Text("Friends")) {
 List(user.friends, id: \.id) { friend in
 Text(friend.name)
 }
 }
 }
 }

 var nameHash: Int {
 user.name.utf8.reduce(0) { $0 + Int($1) } % 100
 }
}

Profile Photo Rabbit Hole

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

I’m on day 60 of #100Days, and have just wasted most of an evening’s coding time going down a rabit hole I didn’t need to. The app for this challenge is called “FriendFace” and is pretty straightforward: download a heap of JSON which is an array of users. Show it in a list that can be clicked through to see the details of that user.

I did that, and instead of moving onto the next project, decided I’d like to show a profile picture of each person. There’s no data for that, so I’ll use a fake photo. I use the Stable Diffusion AI for many of the pictures in this blog, so I assumed there would be an API for grabbing a fake profile pic from somewhere. It turns out there are several, but they are paid services.

Never mind, I know unsplash is a great source of free images, and they definitely have a portrait category. I’ll get them from there. Instead of using a REST api, I just wanted to grab them from a URL. After a bit of googling around, it turns out you can just use the url https://source.unsplash.com/collection/9948714?372 and change the number after the question mark to get a different portrait.

Now all I need is a way to generate a number 1-1000 such that it’s always the same for each individual user. That’s basically a hash, and Swift has a hashValue property on it’s string. I tried user.name.hashValue % 1_000, but kept getting different pictures. Pulled up a playground and tried some print() debugging, and the hashValue was different each run. It would be the same if I hashed the same string twice in a row in code, but not between runs. A few googles later, I’ve learned this is deliberate.

So I need to write my own hash. This is not cryptography - I can just sum all the ascii values of the characters in the string and modulo them. I’m a bit hazy on how to get every character in a Swift string because of the unicode thing, but rmaddy has this answer:

extension String {
 var fourBitHash: Int {
 return self.utf8.reduce(0) { $0 + Int($1) } % 16
 }
}

let colorIndex = "John R Smith".fourBitHash
print(colorIndex)

Perfect. I adapt this into my code as:

func simpleHash(_ string: String) -> Int {
 string.utf8.reduce(0) { $0 + Int($1) } % 1000
}

And we’re in business, but hang on, I’m still getting a different picture by repeatedly going into the view detail for the same user. I try pasting in the url a few times, and sure enough, unsplash are serving up random portraits for the same URL….

Okay, so I need a different source for pics. More googling, and I discover RandomUser.me They only have 100 profiles for men, and another 100 for women - but this app is only for me, and I’ll probably get bored after I’ve clicked on three or four so that will be fine. I throw that into my AsyncImage and we’re in business.

AsyncImage(
 url: URL(string: "https://randomuser.me/api/portraits/women/\(simpleHash(user.name)).jpg"),
 scale: 3
) { image in image
 .resizable()
 .scaledToFit()
} placeholder: {
 ProgressView()
}

I’d prefer to show the correct gender (I’m not being deliberately binary, I’d just like to double the number of photos) , and there is no gender field in my data. So, I guess I’ll need an API that guesses gender based on a name input based on a giant lookup table or an AI model.

More googling, and I find stomgren’s genderize api. An input of:

[https://api.genderize.io/?name=ian](https://api.genderize.io/?name=ian)

returns:

{
 "count": 306685,
 "gender": "male",
 "name": "ian",
 "probability": 1
}

https://api.genderize.io/?name=kim

{
 "count": 83361,
 "gender": "female",
 "name": "kim",
 "probability": 0.7
}

Perfect. So, I can just add this to my code to pull up the picture, or, you know what, I’m procrastinating and it’s time for bed.

Project 12 Challenges

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

Project 12 was a series of code tutorials around developing CoreData concepts rather than a real app, but the challenges are based on a very small app that uses a subview to allow dynamic (ie changeable at runtime) filtering of a list of data. The reason this would be tricky is that the @FetchRequest is a property of a view - and therefore mutable. The trick is to have a subview to build that part of the view, and to pass parameters into it which build the fetchrequest using an underscore.

The data is three recording artists - Taylor Swift, Ed Sheeran and Adel. The ContentView is a list of their names, with some buttons to filter it. Here’s the content view:

struct ContentView: View {
 
 @Environment(\.managedObjectContext) var moc
 @State private var lastNameFilter = "A"
 
 var body: some View {
 VStack {
 // list of matching singers
 FilteredList(filter: lastNameFilter)

 Button("Add Examples") {
 let taylor = Singer(context: moc)
 taylor.firstName = "Taylor"
 taylor.lastName = "Swift"

 let ed = Singer(context: moc)
 ed.firstName = "Ed"
 ed.lastName = "Sheeran"

 let adele = Singer(context: moc)
 adele.firstName = "Adele"
 adele.lastName = "Adkins"

 try? moc.save()
 }

 Button("Show A") {
 lastNameFilter = "A"
 }

 Button("Show S") {
 lastNameFilter = "S"
 }
 }
 }
}

And the subview that builds the FetchRequest and the filtered list:

struct FilteredList: View {
 @FetchRequest var fetchRequest: FetchedResults<Singer>
 
 var body: some View {
 List(fetchRequest, id: \.self) { singer in
 Text("\(singer.wrappedFirstName) \(singer.wrappedLastName)")
 }
 }
 
 init(filter: String) {
 _fetchRequest = FetchRequest<Singer>(sortDescriptors: [], predicate: NSPredicate(format: "lastName BEGINSWITH %@", filter))
 }
}

Task 1

Modify the FilteredList View we made to make it accept a string parameter that controls which predicate is applied. You can use Swift’s string interpolation to place this in the predicate.

The changes here are to the init() in the FilteredList. Just need another argument to replace the format parameter in the FetchRequest. I may have misunderstood something, because Paul hinted to use string interpolation, but I can’t see that it’s needed.

init(format: String, filter: String) {
 _fetchRequest = FetchRequest<Singer>(sortDescriptors: [], predicate: NSPredicate(format: format, filter))
}

Then when we call it, just pass in the format string.

// list of matching singers
FilteredList(format: "lastName BEGINSWITH %@", filter: lastNameFilter)

Task 2

I’m a fan of this task, because of my wariness of Hard Coded Strings.

Modify the predicate string parameter to be an enum such as .beginsWith, then make that enum get resolved to a string inside the initializer.

The enum, with attached raw values:

enum PredicateType: String {
 case beginsWith = "BEGINSWITH"
 case beginsWithIgnoreCase = "BEGINSWITH[c]"
 case contains = "CONTAINS"
 case equals = "=="
 case lessThan = "<"
 case greaterThan = ">"
}

The ContentView has a @State variable for it. The user clicks on buttons to change it, and it’s passed to the subview instead of the previous string:

struct ContentView: View {
 
 @Environment(\.managedObjectContext) var moc
 @State private var lastNameFilter = "A"
 @State private var predicateType = PredicateType.beginsWith
 
 var body: some View {
 VStack {
 // list of matching singers
 FilteredList(format: predicateType, filter: lastNameFilter)

 Button("Add Examples") {
 let taylor = Singer(context: moc)
 taylor.firstName = "Taylor"
 taylor.lastName = "Swift"

 let ed = Singer(context: moc)
 ed.firstName = "Ed"
 ed.lastName = "Sheeran"

 let adele = Singer(context: moc)
 adele.firstName = "Adele"
 adele.lastName = "Adkins"

 try? moc.save()
 }

 Button("Begins with A") {
 lastNameFilter = "A"
 predicateType = .beginsWith
 }

 Button("Begins with S") {
 lastNameFilter = "S"
 predicateType = .beginsWith
 }
 Button("Contains n") {
 lastNameFilter = "n"
 predicateType = .contains
 }
 
 }
 }
}

Then in the subview, we grab the rawValue and interpolate that into the string. I’m just now realising that for Task 1, Paul probably didn’t want the whole string passed in, just the “BEGINSWITH” operator or whatever.

struct FilteredList: View {
 
 @FetchRequest var fetchRequest: FetchedResults<Singer>
 
 var body: some View {
 List(fetchRequest, id: \.self) { singer in
 Text("\(singer.wrappedFirstName) \(singer.wrappedLastName)")
 }
 }
 
 init(format: PredicateType, filter: String) {
 _fetchRequest = FetchRequest<Singer>(sortDescriptors: [], predicate: NSPredicate(format: "lastName \(format.rawValue) %@", filter))
 }
 
}

Task 3

Make FilteredList accept an array of SortDescriptor objects to get used in its fetch request.

Yet another change to the init in our subview. It’s getting kinda messy:

init(format: PredicateType, filter: String, sortDescriptors: [SortDescriptor<Singer>]) {
 _fetchRequest = FetchRequest<Singer>(sortDescriptors: sortDescriptors, predicate: NSPredicate(format: "lastName \(format.rawValue) %@", filter))
}

Then in the subview call:

// list of matching singers
FilteredList(format: predicateType, filter: lastNameFilter, sortDescriptors: [
 SortDescriptor<Singer>(\.firstName)
])

Bookworm Feedback

Mon, 07 Nov 2022 00:00:00 +0000

I did so well on this one that it’s not going to make a very interesting post. My first two challenge solutions were pretty much character for character the same - so not much to report.

On the third challenge, there was a minor difference in the display process. I had done this:

let date = book.date ?? Date()
Text(date.formatted(.dateTime.day().month().year()))
 .foregroundColor(.secondary)
 .opacity(date == book.date ? 1 : 0)

But @twostraws went:

if let date = book.date {
 Text(date.formatted(date:.abbreviated, time:.omitted))
}

I agree the if let is neater. I was heading a warning from earlier in the series about avoiding if statements when building views as they can cause the view to have to be destroyed and recreated if it contains different elements (as opposed to a property change - which I don’t fully understand since I also believed those modifier properties where causing the views to be recreated inside other views?), but I don’t know if that’s an issue at all for list elements - I’m guessing not if Paul is doing it this way. I have noticed (when playing with print statements in init methods) that SwiftUI is very good at only recreating the views that need recreated.

I would stand by my use of the opacity to disappear the text but save the space though - this is a good trick if you want to have a piece of a view not there, but still reserve its space.

Paul has also done better with his date format. Mine does not take into account the date formats for different locales, where as iOS will manage that with Paul’s use of .abbreviated.

Bookworm Challenges

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

Another set of challenges for a #100DaysofSwiftUI tutorial app. Project 11 was a book tracking app - the big new thing was using CoreData. Here’s the challenges for it.

Right now it’s possible to select no title, author, or genre for books, which causes a problem for the detail view. Please fix this, either by forcing defaults, validating the form, or showing a default picture for unknown genres – you can choose.

The genre is already forced since it uses a picker, but I added a default (plain grey) image to deal with the situation that there’s no data for it in a record. It doesn’t make sense to provide defaults for the title or author, but some validation to ensure those fields are not empty is worthwhile.

Section {
 Button("Save") {
 let newBook = Book(context: moc)
 newBook.id = UUID()
 newBook.title = title
 newBook.author = author
 newBook.rating = Int16(rating)
 newBook.genre = genre
 newBook.review = review
 newBook.date = Date()

 try? moc.save()
 dismiss()
 }
}
.disabled(title.isEmpty || author.isEmpty || genre.isEmpty)

Modify ContentView so that books rated as 1 star are highlighted somehow, such as having their name shown in red.

Straightforward, with use of the ternary operator.

Add a new “date” attribute to the Book entity, assigning Date.now to it so it gets the current date and time, then format that nicely somewhere in DetailView.

Add the date field to the datamodel
Set it to current date in the Save of the AddView
Showing it in the Detail View was a little more interesting - adding a test to ensure it was in the database - since we’ve now got two versions of these records.

Text(book.author ?? "Unknown author")
 .font(.title)
 .foregroundColor(.secondary)

let date = book.date ?? Date()
Text(date.formatted(.dateTime.day().month().year()))
 .foregroundColor(.secondary)
 .opacity(date == book.date ? 1 : 0)
 
Text(book.review ?? "No review")
 .padding()

@Binding - data between views

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

In C world, if we want to pass a parameter down into a functional call, and allow the receiving function to change it’s value, we’d pass a pointer to the variable. Something like this:

#include <stdio.h>
#include <stdlib.h>

void increment(int* b) {
 *b=*b+1;
}

int main() {
 int a = 5;
 increment(&a);
 printf("%d", a);
 return 0;
}

// prints '6'

For youngsters, what’s happening is that we’ve set the value of a to 5, then passed the memory address of a into the increment() function. That’s what the @a means.

In the increment function we’re expecting an *int - ie the address of an int. Then we dereference it with the asterisks to operate on the value stored in the address.

The reason I mention all this ancient lore is because it’s what I imagine is happening with the @Binding in a subview - although I’m also sure the story underneath is more complex than that.

import SwiftUI

struct ContentView: View {
 @State var someInt = 5
 var body: some View {
 VStack {
 SubView(someValue: $someInt)
 Text("Content view \(someInt)")
 }
 }
}

struct SubView: View {
 @Binding var someValue: Int
 var body: some View {
 HStack {
 Text("Subview \(someValue)")
 Button("Inc") {
 someValue += 1
 }
 }.padding()
 }
}

There’s a couple of things to note here. In the SubView struct, we’ve used the @Binding property wrapper, and in the ContentView where we’ve passed the state variable from, we’ve marked it with the $ so indicate we know its a binding variable that can be mutated by whatever it’s being passed to.

If we leave the $ off, the compiler will point out our error because it knows it’s bound in the other view.

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.

Cupcake Corner Feedback

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

As usual, here’s my thoughts comparing my attempts at the challenges to Paul’s. Usually he’s better!

1) Whitespace

The task was to validate the order address properties, not just by checking they are not empty, but also that they don’t just contain spaces. I went the bruteforce route since there was no .isEmptyIncludingWhitespace method.

var hasValidAddress: Bool {
 let trimmedName = name.trimmingCharacters(in: .whitespacesAndNewlines)
 let trimmedStreetAddress = streetAddress.trimmingCharacters(in: .whitespacesAndNewlines)
 let trimmedCity = city.trimmingCharacters(in: .whitespacesAndNewlines)
 let trimmedZip = zip.trimmingCharacters(in: .whitespacesAndNewlines)

 if trimmedName.isEmpty || trimmedStreetAddress.isEmpty || trimmedCity.isEmpty || trimmedZip.isEmpty {
 return false
 }
 return true
}

As soon as Paul mentioned extending String, I facepalmed - of course, just create the method I want on string. Paul’s is a one line extension - neater, and Swiftyier.

2) Alert for POST fail

Paul’s approach exactly the same as mine, with the addition of showing the localizedDescription of error which is something that must exist in catch blocks.

3) struct Wrapper

We had the same approach. I liked Paul’s naming better. He named the wrapper class SharedOrder, then the instance order. Then the instance of the struct data. That way the name hierarchys in the code were something like order.data.street which was better than mine, although they still bug me. Another difference I noticed was that the static enum for the cupcake types he put in the wrapper class whereas I had it in the order struct.

Paul left the CodingKey enum in - no problem with that, but I can’t see that it’s needed.

Bombshell

You know how I was complaining that the class.struct.propertyname things were the main downside of the class wrapping a struct approach? Next Paul pulls a rabbit out of his hat with @dynamicMemberLookup combined with keyPaths. I’m not going to explain how these work, but the effect is that we can eliminate the struct name from our names so order.data.street is just order.street but it is still referencing our struct property wrapped in the class.

Cupcake Corner challenges

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

Day 52 of #100Days was the challenges to the Cupcake Corner app - an app that allows you to build a one-row order, encode it as JSON and submit it to an API with a URLSession. To allow the order to be passed around, it’s an @ObservedObject which meant that a few extra hoops needed to be jumped through to make it Codable.

1) Whitespace validation

The tutorial app validates the order address by checking that each field is not empty, but it can be fooled by just entering some spaces. The first challenge was to fix that.

The tutorial version of the app accomplished the checking with a computed property in the Order struct - which is a good place for it. Here it is:

var hasValidAddress: Bool {
 if name.isEmpty || streetAddress.isEmpty || city.isEmpty || zip.isEmpty {
 return false
 }
 return true
}

There’s no .isEmptyIfYouIgnoreWhiteSpace method, so I did this:

var hasValidAddress: Bool {
 let trimmedName = name.trimmingCharacters(in: .whitespacesAndNewlines)
 let trimmedStreetAddress = streetAddress.trimmingCharacters(in: .whitespacesAndNewlines)
 let trimmedCity = city.trimmingCharacters(in: .whitespacesAndNewlines)
 let trimmedZip = zip.trimmingCharacters(in: .whitespacesAndNewlines)

 if trimmedName.isEmpty || trimmedStreetAddress.isEmpty || trimmedCity.isEmpty || trimmedZip.isEmpty {
 return false
 }

 return true
}

source

2) Show an alert if the POST fails

In the tute version, this is just a print statement. This challenge just involves adding a second alert to the checkout view. Source

3) Change order to struct

This is a bit more complicated. A reason for preferring a struct is that all of the extra work we did to make the class Codable is eliminated. We need the thing being passed around to be an object because we want a reference type that can be mutated inside the view hierarchy, and because we want it to be an @Observed Object. The change proposed here is sort of the best of both worlds - have the object, but it’s sole property is the struct.

I created a wrapper class, with the struct as an @Published var.

class Wrapper: ObservableObject {
 @Published var order = Order()

 deinit {
 }
}

Then I changed the Order class to a struct, removed @Published from all the properties and deleted the encode/decode code. Then in all the views, I had to go through and fix the names. I did not love the less readable names I was creating; for example wrapped.order.streetAddress instead of just order.streetAddress. But that all worked.

source

Codable when the keys don't match

Mon, 31 Oct 2022 00:00:00 +0000

A common issue when working with JSON that you vacuum up from internet APIs will be that the key names in the JSON don’t match your property names. The JSON de facto standard of using snake_case in key names could be one cause, or perhaps you just take variable naming more seriously than the person who wrote the API.

We saw yesterday how using codable and the JSONEncoder in Swift makes moving between an object/struct in the code and a stringish representation of it simple. With a couple of small changes, we can also deal with the mismatched key/property name issue.

Let’s try yesterday’s decode approach with some different JSON:

import Foundation

struct Person: Codable {
 var id: Int
 var firstName: String
 var lastName: String
 var email: String
}

let jsonString = """
{
"id": 1,
"what_I_call_them": "Jeanette",
"surname": "Penddreth",
"email": "jpenddreth0@census.gov",
}
"""

let data = Data(jsonString.utf8)

let decoder = JSONDecoder()
let newPerson = try decoder.decode(Person.self, from: data)

// never gets here
print(newPerson.lastName)

This will fail at line 22. If you look at the JSON you’ll notice that the key names don’t match our property names. i.e. what_I_call_them is not the same as firstName. We could solve that in this example just by changing our property names, but Swift has a better way to help us - CodingKey.

CodingKey is an enum that maps our property names to the key names used in the JSON. Here’s something that would work for the example above:

enum CodingKeys: String, CodingKey {
 case id
 case firstName = "what_I_call_them"
 case lastName = "surname"
 case email
}

Just adding this to our struct will make the decode process work perfectly:

import Foundation

struct Person: Codable {
 var id: Int
 var firstName: String
 var lastName: String
 var email: String
 
 enum CodingKeys: String, CodingKey {
 case id
 case firstName = "what_I_call_them"
 case lastName = "surname"
 case email
 }
}

let jsonString = """
{
"id": 1,
"what_I_call_them": "Jeanette",
"surname": "Penddreth",
"email": "jpenddreth0@census.gov",
}
"""

let data = Data(jsonString.utf8)

let decoder = JSONDecoder()
let newPerson = try decoder.decode(Person.self, from: data)

print(newPerson.lastName)
// Pendreth

This is an elegant solution, but for the more common situation - where the JSON returned by an API uses the JavaScript convention of snake_case instead of camelCase, there is an even easier approach. The JSONDecoder has a .keyDecodingStrategy property. To deal with snake case, we just set that to .convertFromSnakeCase. Note line 23.


import Foundation

struct Person: Codable {
 var id: Int
 var firstName: String
 var lastName: String
 var email: String
}

let jsonString = """
{
"id": 1,
"first_name": "Jeanette",
"last_name": "Penddreth",
"email": "jpenddreth0@census.gov",
}
"""

let data = Data(jsonString.utf8)

let decoder = JSONDecoder()
decoder.keyDecodingStrategy = .convertFromSnakeCase
let newPerson = try decoder.decode(Person.self, from: data)

print(newPerson.lastName)
// Pendreth

Codable & JSON

Sun, 30 Oct 2022 00:00:00 +0000

If we mark a type with the protocol Codable, we’re specifying that this type has the capability of having it’s properties encoded to some format, and decoded back again.

So far in the #100Days this has been used to write and read data in UserDefaults, and to encode an object to send it as a URLRequest, then receive data back and create a new object from it. It’s a handy, powerful feature baked into Swift that just requires the developer to ensure any types that need this functionality comply with the Encodable and Decodable protocols that make up the Codable.

I assume there’s some magic (by magic I guess I mean code created during the compile/build process - or perhaps a language feature that lets us enumerate the property names of a type? ) that allows Swift to step through each property in a composite type in order to encode or decode via the encoder/decoder

Making a type Codable

For simple situations, you just add the Codable protocol to your type. If all the properties inside that type are Codable, then your struct/class will be to. All the straightforward built in types are.

struct Chair: Codable {
 var name: String = ""
 var legs: Int = 4
}

Since String and Int are codable, the Chair struct will be as well. I’ll deal with how you fix a type that’s not codable another day.

Encoding

To encode our data we need an encoder. We’ll use the Foundation JSONEncoder, but there are others such as XML and so on.

struct Chair: Codable {
 var name: String = ""
 var legs: Int = 4
}

let stool = Chair(name: "Stool", legs: 3)
let encoder = JSONEncoder()

do {
 let jsonData = try encoder.encode(stool)
 print(String(data: jsonData, encoding: .utf8)!)
} catch {
 print("Encoding Error")
}

This prints out:

{"name":"Stool","legs":3}

So the property names are used to build our data. The “data” returned by the JSONDecoder is a UTF8 string - this is specified by the JSON standard, and that’s why the print above is not just print(jsonData).

Decoding

// use # to delimit a string that contains double quotes
let jsonString = #"{"name":"Kitchen chair","legs":4}"#

// convert our Swift string into the UTF-8 data type expected
let data = Data(jsonString.utf8)

let decoder = JSONDecoder()
let newChair = try decoder.decode(Chair.self, from: data)

print(newChair.name)
// Kitchen chair

Wrap up

I’ve used the simplest cases here to show how the basics work, but there’s a couple of common situations that require a bit more work. The most common is that the JSON you are trying to decode has non-swifty keys. It’s common for JSON keys to be snake_case rather than camelCase. Another issue is if our type needs a bit of work to make it codable. There’s some overlap in these situations that well look at another time.

Day 50 - @State vs @Observed again

Fri, 28 Oct 2022 00:00:00 +0000

Way back when, I was unclear about @StateObject and @ObservedObject (here, and here). I still am.

But in today’s tutorial video, Paul clearly says that the @StateObject is for the single place in your app where the object is created, then everywhere else, use @ObservedObject. Trouble is, I just know from the Simple MVVM app I made if you wrap the single instance of the data model with the @ObservedObject, it still works.

Half way through my #100Days and this mystery is still not solved for me. I imagine now it never will be until I can figure out how the property wrappers differ. When you hold down command, and click over a keyword, you get a list of options. One of these options is “Jump to definition”.

So I should be able to do that with @StateObject and @ObservedObject then just diff the code and see right?

Obviously, I’m not comprehending all of this, but it looks like the main difference is this extra Wrapper struct in the ObservedObject:

@dynamicMemberLookup @frozen public struct Wrapper {
 public subscript<Subject>(dynamicMember keyPath: ReferenceWritableKeyPath<ObjectType, Subject>) -> Binding<Subject> { get }
 }

Yeah. I’m not going to be able to unpack that bad boy. I’ll just file it in “probably something to do with reference counting, and come back to it when I’m smarter.

Day 47 - Habits App

Thu, 27 Oct 2022 00:00:00 +0000

I’ve been mucking around with the Habits app too long - it’s started to look like procrastination. It already meets the specification, so I’m calling it an MVP and moving on.

This is the first app of mine I’ve loaded onto my phone and started using, and there are a couple of things I’d like to do with it. It currently just lets you specify how many days between an activity repeating - so if you say you should go to the gym every second day, and you complete that activity on Monday, “Gym” will make it’s way to the top of the list on Wednesday. While it’s waiting in the list for Wednesday to come around, it will show the “Due” time as being exactly 48 hours after you last pressed “done” on it. But if the habit you want is to go to the gym after work at 6:00pm that’s when you want it to be due. I’d like that.

This does overlap a bit with the idea of a “ToDo” list, so maybe it’s a feature creep it shouldn’t have. Espeically since the reason I wanted it was because in the process of adding test activities I added “Take out the bins” and that has to be done on Wednesday nights.

Paul’ has moved away from all the data being in an @State in the View to having a data model object in a separate file. It feels like only a few steps until he jumps out from behind a bush and says “You’ve been writting MVVM already!” although currently its a bit more like just MV.

The list of things I’m going to come back to is growing - I also have still not finished writing the custom picker so I can match the design work I paid for on the times table app. Nevertheless, I’ve so far spent 120 days on the #100DaysOfSwiftUI and I’m only up to day 47, so time to get moving.

JSON encode/decode

Mon, 24 Oct 2022 00:00:00 +0000

As usual, I’m spending way more time on the apps written from scratch in the 100Days series. The Habit tracking app I’m working on has been good practice, especially of the architecture of the simple list based app.

My version has a couple of refinements I quite like. I’m using a checkmark in a rectangle as the button to mark that activity as done, and I’ve added a nice fade to the checkmark as time goes on to represent the percentage of time from when it is done until it becomes due again.

Until this app I’ve purely been using the preview and simulator for looking and and checking the operation of the app. But now I’ve started using my own iPhone for testing and actually trying to use the app from day to day. There’s a noticeable difference between thinking up use-cases in your head or dogfooding it. This has led to several improvements, but now I’m at a crossroads with one to do with the data persistence.

I’m using the Swift built in JSON encode/decode which has been quite painless. It uses the struct property names (so not really in line with the JSON snakecase convention) and just magics everthing up for you. Here’s the structs, and the JSON produced after a week of using the app.

struct HabitItem: Identifiable, Codable, Equatable {
 var id = UUID()
 let name: String
 var started = Date()
 var timesDone = 0
 var lastDone: Date
 var daysBetweenCompletions = 1.0
}

class Habits: ObservableObject {

 @Published var items = [HabitItem]() {
 didSet {
 if let encoded = try? JSONEncoder().encode(items) {
 UserDefaults.standard.set(encoded, forKey: "Habits")
 }
 }
 }

 init() {
 if let savedItems = UserDefaults.standard.data(forKey: "Habits") {
 if let decodedItems = try? JSONDecoder().decode([HabitItem].self, from: savedItems) {
 items = decodedItems
 return
 }
 }

 items = []
 }
}

[
 {
 "id":"5D52B636-030A-4571-8B6E-2117AFD69304",
 "timesDone":2,
 "daysBetweenCompletions":1,
 "name":"Dishes",
 "lastDone":687916240.08548605,
 "started":687741044.36479199
 },
 {
 "id":"26D89BA0-D3FA-49CF-BB01-249A19E90871",
 "timesDone":4,
 "daysBetweenCompletions":1,
 "name":"Bed",
 "lastDone":688060851.81663799,
 "started":687702031.59694302
 },
 {
 "id":"C73234ED-3FA9-4B91-AC24-42E7391E3BE1",
 "timesDone":10,
 "daysBetweenCompletions":0.5,
 "name":"Eating ",
 "lastDone":688108866.69676399,
 "started":687702494.12051105
 },
 {
 "id":"0940450A-2A5E-4B11-B049-9B33F9C01F7D",
 "timesDone":6,
 "daysBetweenCompletions":0.5,
 "name":"Brush teeth",
 "lastDone":688110048.34211302,
 "started":687702045.01338601
 },
 {
 "id":"FA6556A8-17A8-4556-8690-9522A5B22856",
 "timesDone":4,
 "daysBetweenCompletions":1,
 "name":"Write code",
 "lastDone":688108275.33836806,
 "started":687702594.956689
 },
 {
 "id":"DA2A1F85-1274-4C58-B411-D6FF9B2A2AAF",
 "timesDone":0,
 "daysBetweenCompletions":7,
 "name":"Walk exercise",
 "lastDone":687702620.82404804,
 "started":687702620.82411301
 },
 {
 "id":"155D50A7-1403-47C6-AFCA-12DB13270A55",
 "timesDone":1,
 "daysBetweenCompletions":7,
 "name":"Bins out",
 "lastDone":687879744.60854602,
 "started":687702107.33206701
 },
 {
 "id":"86FE01B9-4716-4C2C-B768-1AC8E3B03DDB",
 "timesDone":1,
 "daysBetweenCompletions":7,
 "name":"Roomba kitchen",
 "lastDone":687916244.61723006,
 "started":687702077.16412401
 },
 {
 "id":"EEA3D2CD-3717-49DD-B5E2-924956F41189",
 "timesDone":2,
 "daysBetweenCompletions":7,
 "name":"Washing",
 "lastDone":688115581.30661595,
 "started":687702096.33233297
 }
]

The problem I’ve got now I’d like to change the struct to add some different functionality. As soon as I change the struct, on the next run the JSON decode will fail and my data model will be empty. This can be caught, and I could use a renamed old version of my struct to load the existing data, and convert it across to the new model. What I’d really like is an option in the JSON decoder that if a property is missing, and I’ve provided a default in the struct, that it just uses that.

I’m not the first developer to have this wish, and there’s a number of solid solutions, but they all seem to require a bit more work than my simple dream above.

Refreshing SwiftUI Views

Sun, 23 Oct 2022 00:00:00 +0000

SwiftUI does some property wrapper magic to (very efficiently) refresh your views, but what if you want to force a refresh for some reason? Here’s the techniques I’m currently using to do that.

The tricks are below, but just so you can see them in context, here’s the sample app we’re working on. It’s a list of cars so you can keep track of how many of each kind you own. Here’s our data:

struct Car: Identifiable, Codable, Equatable {
 var id = UUID()
 let model: String
 var number = 0
}

class Cars: ObservableObject {

 @Published var items = [Car]()

 init() {
 let car1 = Car(model: "Station wagon")
 let car2 = Car(model: "Sedan")
 let car3 = Car(model: "Hatchback")
 items = [car1, car2, car3]
 }

 func increment(_ car: Car) -> Bool {
 let index = items.firstIndex(of: car)
 if let index = index {
 items[index].number += 1
 return true
 } else {
 return false
 }
 }

 deinit {
 }

}

The app is a list inside a navigation stack. The view for each car is split out into a subview:

struct ContentView: View {
 @StateObject var cars = Cars()
 
 var body: some View {
 NavigationView {
 List {
 ForEach(cars.items) { car in
 CarView(car: car, cars: cars)
 }
 }
 .navigationTitle("Cars")
 }
 }
}

struct CarView: View {
 var car: Car
 var cars: Cars
 
 var body: some View {
 HStack {
 Text("\(Int.random(in: 10...99)) ")
 VStack(alignment: .leading) {
 Text(car.model)
 .font(.headline)
 }
 Spacer()
 Text(" \(car.number) ")
 Button {
 if !cars.increment(car) {
 print("Unexpected error - car not found:\(car.model)")
 }
 } label: {
 Image(systemName: "plus")
 }
 }
 }
}

The random Int is just so we can get a visual indication that our view has refreshed.

Trick 1 - change a value

All the other tricks rely on this trick. SwiftUI reacts to any @State property changing, so to force a change, there just needs to be a @State property we change. I add a:

@State var refresh = false

to my ContentView. Whenever this changes, ie refresh.toggle() the view will be redrawn. Of course we don’t want just the ContentView redrawn, but the subview as well, so it needs to be passed into the subview. We don’t do anything with it there, just pass it in.

struct ContentView: View {
 @StateObject var cars = Cars()
 @State private var refresh = false

 var body: some View {
 NavigationView {
 List {
 ForEach(cars.items) { intItem in
 CarView(car: intItem, cars: cars, refresh: refresh)
 }
 }
 .navigationTitle("Cars")
 }
 }
}

struct CarView: View {
 var car: Car
 var cars: Cars
 var refresh: Bool
 
 var body: some View {
 HStack {
 Text("\(Int.random(in: 10...99)) ")
 VStack(alignment: .leading) {
 Text(car.model)
 .font(.headline)
 }
 Spacer()
 Text(" \(car.number) ")
 Button {
 if !cars.increment(car) {
 print("Unexpected error - car not found:\(car.model)")
 }
 } label: {
 Image(systemName: "plus")
 }
 }
 }
}

Trick 2 - .refreshable()

That’s the infrastructure in place, so now we can use it. We could add a button that the user could click to refresh, but 2022 users have been trained to pull down on views to make them refresh, so let’s do that. Just add a .refreshable() modifier to our list, then toggle refresh in the closure.

struct ContentView: View {
 @StateObject var cars = Cars()
 @State private var refresh = false

 var body: some View {
 NavigationView {
 List {
 ForEach(cars.items) { intItem in
 CarView(car: intItem, cars: cars, refresh: refresh)
 }
 }
 .navigationTitle("Cars")
 .refreshable {
 refresh.toggle()
 }
 }
 }
}

Now when the user pulls the list down, the familiar wait wheel appears, the view, and the car subviews, all redraw.

Trick 3 - OnChange(of: scene)

In my Habit app, the activities are going to appear with a temporal description of when they should be done, like “next week”, “in a few minutes”, or “tomorrow”. Those will be created from the date/time the activity was last done, how often the activity should be done, and the current date/time. So if our app has been in the background and we open it up, we want fresh calculations. We can do that by detecting a scenePhase change to .active.

We have to declare a variable for it, and then add the .onChange to the view:

struct ContentView: View {
 @StateObject var cars = Cars()
 @State private var refresh = false
 @Environment(\.scenePhase) var scenePhase

 var body: some View {
 NavigationView {
 List {
 ForEach(cars.items) { intItem in
 CarView(car: intItem, cars: cars, refresh: refresh)
 }
 }
 .navigationTitle("Cars")
 }
 .onChange(of: scenePhase) { newPhase in
 if newPhase == .active {
 refresh.toggle()
 }
 }
 }
}

Trick 4 - a timer

Even if our user leaves the app open and foregrounded, eventually the descriptions will be out of date, so another thing we could do is use a timer. We have to add a timer property, and add an .onReceive() to the view. The timer interval in seconds is set when the timer is created. The example below is going to trigger every second.

struct ContentView: View {
 @StateObject var cars = Cars()
 @State private var refresh = false
 
 let timer = Timer.publish(every: 1, on: .main, in: .common).autoconnect()

 var body: some View {
 NavigationView {
 List {
 ForEach(cars.items) { intItem in
 CarView(car: intItem, cars: cars, refresh: refresh)
 }
 }
 .navigationTitle("Cars")
 }
 .onReceive(timer, perform: { _ in
 refresh.toggle()
 })
 }
}

You need to enjoy puzzles

Sat, 22 Oct 2022 00:00:00 +0000

I’m writing the Habits list based app from #100Days and had a working MVP, then for some reason, decided to refactor by changing the subview I’d written as a function, into a struct. Some time later, I discovered that my list items were not updating correctly, so detective time.

I talked a little bit about the architecture yesterday - the item is a struct, and there’s a class containing an array of the items. Something like this:

struct Car: Identifiable, Codable, Equatable {
 var id = UUID()
 let model: String
 var number = 0
}

class Cars: ObservableObject {

 @Published var items = [Car]()

 init() {
 let car1 = Car(model: "Station wagon")
 let car2 = Car(model: "Sedan")
 let car3 = Car(model: "Hatchback")
 items = [car1, car2, car3]
 }

 func increment(_ car: Car) -> Bool {
 let index = items.firstIndex(of: car)
 if let index = index {
 items[index].number += 1
 return true
 } else {
 return false
 }
 }

 deinit {
 }

}

Then the ContentView is a NavigationView with a List. To build the list, I ForEach on the array inside the object, calling a subview on each one:

struct ContentView: View {
 @StateObject var cars = Cars()

 var body: some View {
 NavigationView {
 List {
 ForEach(cars.items) { intItem in
 CarView(car: intItem, cars: cars)
 }
 }
 .navigationTitle("Cars")
 }
 }
}

struct CarView: View {
 var car: Car
 var cars: Cars
 
 var body: some View {
 HStack {
 VStack(alignment: .leading) {
 Text(car.model)
 .font(.headline)
 }
 Spacer()
 Text(" \(car.number) ")
 Button {
 if !cars.increment(car) {
 print("Unexpected error - car not found:\(car.model)")
 }
 } label: {
 Image(systemName: "plus")
 }
 }
 }
}

When the user clicks on the button in a list item, the underlying data is amended somehow - in this pared down example the number of that type of car is incremented. Since my “car” is a value type there’s no point incrementing its number, so instead I call the .increment method on the cars object that is holding my array.

Then, in that method, I have to search for the car the user intends to change, then change it.

func increment(_ car: Car) -> Bool {
 let index = items.firstIndex(of: car)
 if let index = index {
 items[index].number += 1
 return true
 } else {
 return false
 }
}

The situation of not being able to find the car should never occur, but out of longstanding habit I check for it and log an error to the console. This then happens repeatedly…

After some print statement debugging, I got it into my head that I’d caused this by changing the subview from a function (which had worked) to a struct (which was not). I decided it was a value type / reference type problem cause between the difference between these two subview approaches. Since that seems like an interesting blog post topic, I spent a long time distilling the code down to a simple looking example of this phenomena.

Then tried it, it worked correctly.

Then changed the function to the struct, it worked correctly.

Went back to the original app, changed the subview function to a struct, it worked correctly.

So I don’t know what caused my original problem, or what changed to fix it. In theory I could go back through the commits (they have helpful names like “general progress” and “progress save”) and find it.

But I’ve already spent way longer on this app than I should have, and all I have to show for it is this post about what a doofus I am.

Purple warning - "Publishing changes"

Fri, 21 Oct 2022 00:00:00 +0000

It’s a pretty safe bet that if Xcode is saying there’s an error in my code, that it’s correct, and I am in error - not Xcode. Today I came across a situation where that might not be true.

I think the purple warnings are problems detected at runtime - I’ve heard of thread problems causing purple warnings. The error I was getting was “Publishing changes from within view updates is not allowed, this will cause undefined behavior.”

The error was on two lines in my model where I’d called a method to update the model from a button press in a sub-view function.

After poking around to try and work it out, I found this clear blog post from Donny Wals and it turns out it’s possibly a bug in XCode 14. My situation fitted the description - calling the method from a button in a list, and the temporary workaround of adding a modifier to the button eliminated the warning.

I’m on Xcode 14.0, and I gather from Donny’s post that the problem might have been fixed in newer versions.

Here’s the calling code - a button in a list, with the “fix” on line 25.

 func habitView(habitItem: HabitItem, habitsCollection: Habits) -> some View {
 HStack {
 VStack(alignment: .leading) {
 Text(habitItem.name)
 .font(.headline)
 Text(habitItem.lastDone.formatted(date: .abbreviated, time: .omitted))
 }
 Text(" (\(habitItem.timesDone))")
 .font(.largeTitle)
 Spacer()
 Button {
 if !habitsCollection.markAsDone(habit: habitItem) {
 print("Unexpected error - habit not found in collection:\(habitItem.name)")
 }
 } label: {
 if habitItem.due {
 Image(systemName: "rectangle")
 .font(.system(size: 40))
 } else {
 Image(systemName: "checkmark.rectangle")
 .font(.system(size: 40))
 }

 }
 .buttonStyle(.bordered)
 }
 }

Drawing Feedback

Wed, 19 Oct 2022 00:00:00 +0000

Here’s the summary of my learning from comparing my efforts with Paul’s solutions to the Project Nine challenges from Day 46 of his 100 Days of SwiftUI course.

Create an Arrow shape – having it point straight up is fine. This could be a rectangle/triangle-style arrow, or perhaps three lines, or maybe something else depending on what kind of arrow you want to draw.

Very similar solutions - Shape returning a Path, expect he finished off his with path.closeSubPath() rather than adding in the last line. That’s a bit neater, so that point to Paul.

Make the line thickness of your Arrow shape animatable.

I did say in my solution that it seemed too simple, and I was expecting to have to use AnimatableData, and that was correct. Paul does not mean animating the line thickness, he means the shaft width of the arrow - though I can see how they’re sort of the same thing. I wish he had his website code on GitHub and I would have fixed it for him, along with an error I’d spotted in one of the earlier lessons.

In any case, Paul’s fix was as per the earlier lesson.

Create a ColorCyclingRectangle shape that is the rectangular cousin of ColorCyclingCircle, allowing us to control the position of the gradient using one or more properties.

This was just a matter of a couple of edits to the ColorCyclingCircle() struct Paul had created in one of the lessons to change the shape and to pass in values so the gradient could be manipulated. Although our solutions where similar, Paul’s was a bit more thorough - controlling the start and end points of the gradient.

I’m interested that Paul uses the US spelling for colour. I’ve wondered about that in my code - of course Apple spell it that way in all the Swift source, so it does look odd if you stick to the UK spelling, and I guess the majority of people who learn English as a second language probably learn American spellings.

Project 9 - Drawing

Tue, 18 Oct 2022 00:00:00 +0000

These few days of #100DaysOfSwiftUI we made some pretty shapes by playing around with some of the SwiftUI systems for drawing on the screen, including paths, shapes, transformations, ImagePaint, drawingGroup() to use Metal rendering, blurs, blend modes and using animatableData for animating - which I think is the solution to an animation problem in my TimesTable app I hadn’t been able to solve yet.

The challenges were:

Create an Arrow shape – having it point straight up is fine. This could be a rectangle/triangle-style arrow, or perhaps three lines, or maybe something else depending on what kind of arrow you want to draw.

Make the line thickness of your Arrow shape animatable.

Create a ColorCyclingRectangle shape that is the rectangular cousin of ColorCyclingCircle, allowing us to control the position of the gradient using one or more properties.

Arrow shape

Nothing too tricky here - define the Arrow as a Shape, then build the part for it. The rect in path has yZero at the top.

Animate line thickness

I was expecting to have to use animatableData in the challenges, so perhaps I’ve misunderstood the brief here

ColorCycling Rectangle

I locked in the start point for the gradient, then let the user manipulate the end point with two sliders. I wanted a vertical slider, but it wasn’t as simple as rotating a slider so I abandoned that as not worth the time investment for the present.

struct ContentView: View {
 @State private var lineWidth = 10.0
 @State private var xAmount = 0.5
 @State private var yAmount = 0.5
 
 var body: some View {
 VStack {
 let endPoint = UnitPoint(x: xAmount, y: yAmount)
 ColorCyclingRectangle(startPoint: .top, endPoint: endPoint)
 .padding()
 Slider(value: $xAmount)
 .padding(.horizontal)
 Slider(value: $yAmount)
 .padding(.horizontal)
 Divider()
 Arrow()
 .stroke(.red, style: StrokeStyle(lineWidth: lineWidth, lineCap: .round, lineJoin: .round))
 .frame(width: 200, height: 400)
 .animation(.linear(duration: 1), value: lineWidth)
 .padding(.vertical)
 HStack{
 Text("Line width: ")
 Button("5") {lineWidth = 5}
 Button("10") {lineWidth = 10}
 Button("25") {lineWidth = 25}
 Button("50") {lineWidth = 50}
 }
 .padding(.vertical)
 }
 }
}
 

struct ColorCyclingRectangle: View {
 var startPoint: UnitPoint
 var endPoint: UnitPoint
 
 var body: some View {
 ZStack {
 ForEach(0..<100) { value in
 Rectangle()
 .inset(by: Double(value))
 .strokeBorder(
 LinearGradient(
 gradient: Gradient(colors: [
 color(for: value, brightness: 1),
 color(for: value, brightness: 0.5)
 ]),
 startPoint: startPoint,
 endPoint: endPoint
 ),
 lineWidth: 2
 )
 }
 }
 .drawingGroup()
 }

 func color(for value: Int, brightness: Double) -> Color {
 var targetHue = Double(value) / Double(100) + 1

 if targetHue > 1 {
 targetHue -= 1
 }

 return Color(hue: targetHue, saturation: 1, brightness: brightness)
 }
}

struct Arrow: Shape {
 func path(in rect: CGRect) -> Path {
 var path = Path()
 // follow the points from the tip around clockwise
 path.move(to: CGPoint(x: rect.midX, y: rect.minY))
 path.addLine(to: CGPoint(x: rect.maxX, y: rect.maxY/3))
 path.addLine(to: CGPoint(x: rect.maxX/3*2, y: rect.maxY/3))
 path.addLine(to: CGPoint(x: rect.maxX/3*2, y: rect.maxY))
 path.addLine(to: CGPoint(x: rect.maxX/3, y: rect.maxY))
 path.addLine(to: CGPoint(x: rect.maxX/3, y: rect.maxY/3))
 path.addLine(to: CGPoint(x: rect.minX, y: rect.maxY/3))
 path.addLine(to: CGPoint(x: rect.midX, y: rect.minY))
 return path
 }
}

As this wasn’t a real project - just scratch code of various techniques - I hadn’t worried about a git repo for it, but twice that came back to bite me when I wanted to go abandon an approach and pick up at an earlier point. That’s a lesson for me.

When it Works

Mon, 17 Oct 2022 00:00:00 +0000

The little joy of something working. It’s one of the things that makes coding enjoyable. Like a good video game you have an overarching goal, but on the way you need to solve a large number of problems of variable complexity, and you get a little bit of dopamine for each one.

I think in every language I’ve ever learned, as soon as I know how to draw something on the screen, I start to get the urge to create a simple drawing application. When I was starting on Visual C++ and the MFC (Microsoft Foundation Classes) the book I used to get started built a drawing application as an example. It hooks into the benefit of being able to quickly see the evidence you’ve achieved something.

Moonshot Feedback

Sat, 15 Oct 2022 00:00:00 +0000

I’ve watched Paul’s solution to the Moonshot challenges (the solutions are one of the perks of being a Hacking With Swift subscriber). When I’m solo learning like this its one of the few ways I can get any feedback on my coding, so I highly value it, and usually write one of these posts as a way to ensure I reflect on it.

The second challenge was to pull out a couple of sub-views, Paul had used a struct as I had, but put them in their own files. I think that’s good practice if those sections are going to be used from other views, otherwise I like them in the the file with the view they’re a part of. I guess if you make it a habit pull them out into files, you’d look there for them so it would not be a drama, but XCode is pretty handy for finding what you want in a reasonable size file, so that’s not a big consideration.

The challenge I was really interested to see was his use of a List for the “list” version of the main view. Although his list looked a bit nicer when he’d finished, that’s more of a comment on the effort I put into the design (minimal - I just made a list version of the grid style). The List does detect that it’s inside a NavigationView and has those > signs at the end of each row - so there’s a visual prompt to the user that these are tappable for more. In my version, I’d just kept the existing scroll view, deleted the grid and used HStacks to build out the view for each mission.

Lists do have a heap of features - checkboxes, multiple selection, pull down for refresh, left slide for delete and all sorts of other goodies. However, none of those are needed for this app, so in that respect my solution is fine.

There is however, a generally important reason for using the standard iOS controls in the way they are intended - accessibility. There’s a good example of that a few minutes later when Paul adds his toolbar to the NavigationView. Here’s mine - succinct, nice use of the ternary operator:

.toolbar {
 Image(systemName: showingList ? "square.grid.2x2" : "list.bullet")
 .onTapGesture {
 showingList.toggle()
 }

Here’s Paul’s:

. toolbar { 
 Button {
 showingGrid.toggle()
} label: {
 if showingGrid
 {
 Label("Show as table", systemImage: "list.dash")
 } else {
 Label("Show as grid", systemImage: "square.grid.2x2")
 }
}

Essentially the same, except he’s used a Button rather than an Image with an .onTapGesture. You may ask why that matters - the answer is that if you were blind and using the iOS screen reader it would matter a lot. With Paul’s version the reader would know it was a button - something for collecting user input, AND it would read out the purpose contained in the label.

Apple deserve credit for the effort and thought put into their accessibility features, and as developers we get a lot of that functionality for free, or at least very cheaply - but only if we do things the Apple way with standard controls.

Moonshot Challenges

Fri, 14 Oct 2022 00:00:00 +0000

Another few coding challenges at the end of a tutorial app in the 100 Days of SwiftUI course. The app is a sort of information app - composed of navigation views going down into more detail about the Apollo space missions. The most exciting revelation for me was how straightforward it is to pull JSON into your apps data structures.

Challenge 1

Add the launch date to MissionView, below the mission badge. You might choose to format this differently given that more space is available, but it’s down to you.

Adding a text view, but also another computed property to the Mission type to retrieve a longer version of the date string.

Challenge 2

Extract one or two pieces of view code into their own new SwiftUI views – the horizontal scroll view in MissionView is a great candidate, but if you followed my styling then you could also move the Rectangle dividers out too.

One of the SwiftLint rules is about the length of views, and I recall Paul Hegarty saying something in the first couple of CS193p lectures about views needing to be kept short. I never know the pros and cons of extracting parts of them as a function or as another struct. And if I do extract them as a struct, it always seems odd to me to just be able to “call” a struct exactly as a function - although since this is declarative programing and we’re just describing a view I guess it’s fine.

For this change, I pulled it out the crew view and a custom divider as structs. I had to move a baby data struct out of the MissionView namespace to make it available to the new view. An alternative have been keeping the new struct also in the main view, but I don’t love doing that too much. The trade off here was the potential advantages of reusing the new sub-view somewhere else, ease of testing and shorter views, vs polluting the namespace and putting things in the global app scope that do not need to be there. Deciding factor for me in this case was just ease of understanding the code.

source

Challenge 3

For a tough challenge, add a toolbar item to ContentView that toggles between showing missions as a grid and as a list.

It’s some combination of unsettling and pleasing if Paul thinks something should be hard and I knock it out quickly. I never know if I’ve missed some crucial point or I’m just getting the hang of things.

For this one I pulled out all the code that showed the grid inside a ScrollView(), duplicated it and edited the new one into a “list” by deleting the enclosing GridView(), changing a couple of VStacks to HStacks and tweaking some sizes. I added a @State variable for showing the grid, and a SF Symbol to the toolbar to swap between the views.

We’ve previously been advised to avoid an if statement to chose between two views as a state changes since it causes the new view to be created (rather than a ternary operator on a modifier or similar), but there’s no real way of avoiding it here - the user is literally asking us for a new view - so that goes into the main view where I extracted the other code from.

source

When I read down into the hints after completing this, Paul talks about some gotchas with List() - which I hadn’t used, so I’ll be interested to see his wrap up to see if a List would have been better than my solution.

Using Swift's map

Thu, 13 Oct 2022 00:00:00 +0000

In Day 39’s Moonshot tutorial app, Paul uses .map on an array without much comment about what’s going on. I assume this might be a common concept in modern languages, but it was new to me.

First, here’s Paul’s code

 init(mission: Mission, astronauts: [String: Astronaut]) {
 self.mission = mission

 self.crew = mission.crew.map { member in
 if let astronaut = astronauts[member.name] {
 return CrewMember(role: member.role, astronaut: astronaut)
 } else {
 fatalError("Missing \(member.name)")
 }
 }
 }

Mission here contains an array of crew which is a struct with two strings, one of them being name, but self.crew (which belongs to the view we’re in) is an array of CrewMember which is a struct with a role: String and another struct astronaut. That sounds confusing, but essentially, an array of one type is being processed to return an array of another type where there’s a 1:1 relationship between the elements of each array.

That’s what map does - it works through a collection, and uses the code in a closure to act on each element to transform it, then adds it to the array to be returned.

Let me try to make it clearer with a simpler example. Time to open a Playground. Let’s map an array of integers into an array of strings:

let intArray = [0, 55, 21, 13]
var stringArray = [String]()

stringArray = intArray.map{ "\($0)"}

print(stringArray)
// ["0", "55", "21", "13"]

$0 is a stand in for each element. This is a common Swift feature but this variable can be named for clarity if desired:

let intArray = [0, 55, 21, 13]
var stringArray = [String]()

stringArray = intArray.map{ number in "\(number)"}

print(stringArray)
// ["0", "55", "21", "13"]

If we didn’t have map, we could do it the long way, something like this.

let intArray = [0, 55, 21, 13]
var stringArray = [String]()

intArray.forEach {
 stringArray.append("\($0)")
}

print(stringArray)
// ["0", "55", "21", "13"]

or, going back even further in time:

let intArray = [0, 55, 21, 13]
var stringArray = [String]()

for number in intArray {
 stringArray.append("\(number)")
}

print(stringArray)
// ["0", "55", "21", "13"]

So the .map method on a sequence returns an array of values built by applying to the passed closure to each element of the sequence.

Paul’s code at the top steps through the mission.crew array which contains the crews names as strings, then attempts to look them up in the astronauts dictionary. If it finds them, it adds them (as a struct) to the crew array.

iExpense Feedback

Wed, 12 Oct 2022 00:00:00 +0000

I finally got around to looking at Paul’s solutions for the iExpense challenges.

Use the user’s preferred currency, rather than always using US dollars.

Same approach as me,

.currency(code: Locale.current.currency?.identifier ?? "USD")

except that he does the work in a local variable which is a bit neater. Since it appears in two places - the display view and the view for adding an expense, this would mean duplicating it, making it global (not rare for user default type settings) or passing it down through the view hierarchy. I feel either of the first two options are fine for this project, but Paul is thorough and extends the FormatStyle protocol, only for currency, to have a new computed property .localcurrency - which is a great solution.

Modify the expense amounts in ContentView to contain some styling depending on their value – expenses under $10 should have one style, expenses under $100 another, and expenses over $100 a third style. What those styles are depend on you.

I’d done this with ternary operator modifiers:

 Text(item.amount, format: .currency(code: Locale.current.currency?.identifier ?? "USD"))
 }.foregroundColor((item.amount < 10) ? .purple : (item.amount < 100) ? .green : .blue)

But Paul, again, goes one better with another extension, this time of View, to create a style(for: Item) - this is a better approach, especially if (as would be likely in a real app) it was going to need to be reused.

I also note that Paul added new files for both these extensions. I think that’s wise for the currency one, but perhaps this one could probably have lived wherever the ExpenceItem was defined.

For a bigger challenge, try splitting the expenses list into two sections: one for personal expenses, and one for business expenses. This is tricky for a few reasons, not least because it means being careful about how items are deleted!

This is where things get weird. I split the types up by running to ForEach in their own groups. Paul had warned that deleting would be tricky because the offset into the array would not necessarily match the offset being passed to the remove method - so the wrong one might be deleted. I implemented my solution without worrying about that and it seemed to work, so I assumed I’d just come up with a better solution and moved on. But it does bear thinking about. Say (starting from no records) I create two business expenses names Bus1 & Bus 2, and then two personal expenses names Per 1 and Per 2. My array of expense objects is going to look a bit like this:

Bus 1 [0]
Bus 2 [1]
Per 1 [2]
Per 2 [3]

But my code is going to list the personal expenses first, then the business ones:

List {
 Section(header: Text("Personal")) {
 ForEach(expenses.items) { item in
 Group {
 if item.type == "Personal" {
 itemView(item: item)
 }
 }
 
 }
 .onDelete(perform: removeItems)
 }
 Section(header: Text("Business")) {
 ForEach(expenses.items) { item in
 Group {
 if item.type == "Business" {
 itemView(item: item)
 }
 }
 
 }
 .onDelete(perform: removeItems)
 }
}

The numbers in the brackets are what I think their array indexes should be. If what I understand Paul to be saying, if I now try to delete Per 2, its offset in the list would be 1 (the second item in the list), but the remove call to the array is going to delete the expense at index 1, which is actually Bus 2. But actually, it just deletes the correct one:

Perplexed, now that I’m thinking carefully about it. I did some print statement debugging:

 func removeItems(at offsets: IndexSet) {
 for i in offsets {
 print("Offset:\(i)")
 }
 print("Before remove")
 for item in expenses.items {
 print(item.name)
 }
 expenses.items.remove(atOffsets: offsets)
 print("After remove")
 for item in expenses.items {
 print(item.name)
 }
 }

Which outputs this:

Offset:3
Before remove
Bus 1 [0]
Bus 2 [1]
Per 1 [2]
Per 2 [3]
After remove
Bus 1 [0]
Bus 2 [1]
Per 1 [2]

So actually, the IndexSet that SwiftUI passes to .onDelete() has already correctly identified the correct array index (shown as “Offset: 3” above). I assume as it’s built the List for me. That’s lovely, but I was perplexed about what Paul is talking about then.

In Paul’s solution, he adds computed properties to the Expenses class to return arrays of either personal or business expenses. he does this with the arrays filter() method. This is a cool method (which I didn’t know about) but it returns a new array with elements meeting the filter condition. So it makes sense that when you create the index set from this, it’s indexed into the new smaller (filtered) array, so of course you need to account for this.

In that case, this might be the first occasion when I think my solution is better than Paul’s!

SwiftLint

Mon, 10 Oct 2022 00:00:00 +0000

I was watching a Tim Ruscica video about the things that highly effective developers do, and it called to mind a book I read years ago called Code Complete. It is the only book I ever owned that I immediately purchased the new edition when it came out. It was about the meta stuff around programming that is the difference between coding and developing. In particular, it got me invested in source control and testing.

If you’ve been reading along, you’ll know I am keen to leverage the great tools available to support quality software development, and one I haven’t tackled till this week is a linter.

Linters are tools to enforce (or at least suggest) rules to improve your code that are not strictly necessary (the compiler hasn’t enforced them) but they make your code better, or at least prettier, in other ways. I gather the most popular linter for Swift is SwiftLint.

I installed it by downloading and running the .pkg. Then in any Xcode projects you want to use it in, you go into Build Phases for the current Scheme in your project and add a new script that runs SwiftLint on the files in the project’s folder. There’s a good step by step here by Vineet Choudhary. You should end up with something like this:

Now when you Command-B to build your project, the linter will run and (especially the first time) add some extra warnings and errors.

SwiftLint has many rules. Some are default rules (these are the most widely accepted ones) and some are optional. Turning rules off or on, or altering their parameters is done using a swiftlint.yml config file in the top level folder of your project.

Here’s an example from mine, where I want to alter a rule:

vertical_whitespace:
 max_empty_lines: 2

There’s a rule called vertical_whitespace. It throws a warning if there is more than one consecutive empty line in a file. I use two line gaps all over my code to signify a separate method or function, so that does not work for me. The config change above changes it to allow two empty lines. This same config file can also be used to disable any of the default rules, or enable any of the optional rules.

Rules can also be disabled and enabled in your code with special comments. For example, in my tests, I have enormous multi-line strings which don’t follow proper indentation for a deliberate reason, so at the top of this file I have:

// swiftlint:disable line_length
// swiftlint:disable indentation_width

You can turn rules back on as well. For example in this code snippet I have code that the linter wants me to write as a trailing closure, but I’m not sure how to do that in this situation yet - so I turn the rule off before it, then back on.

func stripSpaces(_ codeLines: String ) -> String {
 // break into lines
 var lines = codeLines.components(separatedBy: "\n")
 var minCount = Int.max
 // step though the lines and count how many spaces, save the minimum amount
 for line in lines {
 // swiftlint:disable trailing_closure
 let leadingSpaces = line.prefix(while: { $0 == " " }).count
 // swiftlint:enable trailing_closure
 minCount = leadingSpaces < minCount ? leadingSpaces : minCount
 }
 // step though the lines again, and trim the min amount from each line
 for index in 0..<lines.count {
 lines[index] = String(lines[index].dropFirst(minCount))
 }
 // stitch it back up
 return lines.joined(separator: "\n")
}

My strategy with the linter was to turn all the optional rules on, then run it and go through to consider each of the optional rules I’ve transgressed to decide if it makes more sense to me to change the code or eliminate the rule.

Testing, testing

Sun, 09 Oct 2022 00:00:00 +0000

I have unit testing in my goals, and if I’m going to throw this space trimming macOS utility up on the web, now might be a good time to figure out how to add unit tests to a project, how to write them, and how to run them. XCode is well set up for this, so it’s really no drama to do.

Although I haven’t worried with any unit testing up to this point in my iOS/Swift learning, in my previous programming work I did a lot of work with the large calculations involved in translating GPS coordinates and robotic positioning models where errors would be bad - so I’ve written a lot of tests over the years. I’ve also definitely felt the confidence you can dramatically refactor code with when you know the code has a robust test suite. I’m a big fan.

Adding Tests to Existing Project

In Xcode, with your project open, you need to add the testing target. File | New | Target... then scroll down to find the Unit Testing Bundle. When you add that, you’ll see a new folder in the Project Navigator, and a new source file - both with the name <app name>Tests.

If you click into the <app name>Test.swift file, you’ll see a couple of methods for setting up the testing environment and cleaning up after it. They are called before and after each test - you’d use them if you needed to set something up like some files in a directory or similar and wanted to ensure it was not affected by the tests run before the current test. Don’t worry about them for the time being.

Writing Tests

Before we can write any tests, we need to import any modules with the code we want to test. In my case, I want to test the function stripSpaces() which is in the ContentView of my app called CodeTrimmer. So in the top of the CodeTrimmerTests.swift file, under the other import, I add the import:

import XCTest
@testable import CodeTrimmer

Then we can write our tests. The test functions must start with the magic prefix test so that Xcode treats them as such. The usual approach in the test is to call a function with some specific input, then test the output is what is expected with a special test version of assert():

Here’s a couple. My function stripSpaces() deletes a number of spaces from each line of a block of code such that the block becomes left aligned. if the XCTAsserts() pass, the test passes and I get a green tick. To run the tests I just click in the breakpoint gutter next to the function declaration.

 func testStripSpaces01() throws {
 let testString =
 """
 single line string no spaces
 """
 let resultString = stripSpaces(testString)
 XCTAssertTrue(resultString == testString, testString)
 }

 func testStripSpaces02() throws {
 let testString =
 """
 single line 4 spaces
 """
 let resultString = stripSpaces(testString)
 XCTAssertFalse(resultString == testString, testString)
 XCTAssertTrue(testString.dropFirst(4) == resultString, testString)
 }

Customizing the default About dialog for MacOS apps

Fri, 07 Oct 2022 00:00:00 +0000

The default Xcode MacOS targeted app has a built in “About” dialog called up from the “About ” menu item in the Mac menu bar. It wasn’t immediately clear to me how to customise this, but after digging through some MacOS apps on GitHub, here’s the answer.

When you app is being built, it looks for the file “Credits.rtf” in the app bundle. If that is found (or “Credits.html” or “Credits.rtfd”) it’s used to build out the About dialog along with your app icon.

After you’ve created the “Credits.rtf” file, you need to drop it into the folder for your project where the source files go. Then in Xcode, add it to your project in that inner folder:

Then when you rebuild the app, it will show in your about dialog.

CodeTrimmer - First MacOS App

Thu, 06 Oct 2022 00:00:00 +0000

I was listening to the StackTrace app this morning (episode 169 - “Choosing What Bugs to Ship”) and one of the ideas discussed was taking the time to automate some of your development processes, partially to save time, but also because if you make a process simple and quick, you’ll be more likely to do it multiple times to improve quality.

Coincidentally, I’d been thinking about how often I paste some code from Xcode in order to display it in one of these blog posts. If it’s from the middle of a method, it will generally be indented a long way in, and there’s no point in displaying it like that (especially for a mobile reader) so I usually manually delete a heap of spaces from each line to left align it whilst keeping the needed indentation.

Sounds like a job for a tiny MacOS app - my first! Here it is in action. You copy your code from Xcode, and paste it into the app:

Then press the “Strip Spaces” button to get:

I’ve got a few little niceties to add/tidy up, but it was a breeze converting my SwiftUI iOS development skills to MacOS - literally ticking a box.

Source

Design Challenge

Wed, 05 Oct 2022 00:00:00 +0000

So, I’ve been working on translating the UI design created by the external designer into SwiftUI, and have done all of the easy bits:

The rounded rectangles for things like the question display/number input are just ZStacks of roundedrects filled, then stroked:

ZStack {
 RoundedRectangle(cornerRadius: 10)
 .fill(.white)
 .padding(.horizontal)
 RoundedRectangle(cornerRadius: 10)
 .stroke(.black, lineWidth: 2)
 .padding(.horizontal)
 HStack {
 Text(questionText)
 .font(.title)
 .fontWeight(.heavy)
 Text(calculatorDisplay)
 .font(.title)
 .fontWeight(.heavy)
 .foregroundColor(.blue)
 }
}
.frame(maxWidth: 350)
.offset(y: 15)

Something I have learned in the process is the .offset modifer. This is what’s used to move a view from where SwiftUI would have placed it, and is what I’ve done to create that overlapped style where the question display/number input is sitting halfway over the bottom of the blue rounded rectangle. This is in the last line of the code above: .offset(y: 15) This is moving the whole ZStack down by 15. A trick to watch with this is that since you’ve messed with SwiftUI’s arrangement, it doesn’t then shuffle everything else around this - you need to manually deal with making some space below it.

The jobs still to do on this view is the customisation of the picker, which I think is going to have to be writing a picker from scratch (or finding the source for the library picker and altering it), and the even more custom combined picker/progress indicator.

iExpense Challenges

Sun, 02 Oct 2022 00:00:00 +0000

Day 38 is three challenges on the iExpense app - a simple expense tracking app that uses UseDefaults for storing it’s data.

Locale

Use the user’s preferred currency, rather than always using US dollars.

One of the joys of modern programming (as opposed to mid-1990’s programming) is the ability of the internet to give you answers. I knew the answer to this would be lurking in the locale environment variable, but instead of looking it up, just googled, and found a viable looking solution on Reddit.

Text(amount, format: .currency(code: Locale.current.currencyCode ?? "USD"))

When I paste it into Xcode, another modern miracle occurs - Xcode warns me know currencyCode is out of date:

'currencyCode' was deprecated in iOS 16: renamed to 'currency.identifier'

and offers to fix it for me:

Use 'currency.identifier' instead

So I’m like “sure, fix that for me”. Then there’s an error because the chaining is needs touched up now:

Value of optional type 'Locale.Currency?' must be unwrapped to refer to member 'identifier' of wrapped base type 'Locale.Currency'

and again offers to fix the chaining for me, so okay it, and end up with this:

 fileprivate func itemView(item: ExpenseItem) -> some View {
 HStack {
 VStack(alignment: .leading) {
 Text(item.name)
 .font(.headline)
 Text(item.type)
 }

 Spacer()
 Text(item.amount, format: .currency(code: Locale.current.currency?.identifier ?? "USD"))
 }.foregroundColor((item.amount < 10) ? .purple : (item.amount < 100) ? .green : .blue)
 }

Conditional formatting

Modify the expense amounts in ContentView to contain some styling depending on their value – expenses under $10 should have one style, expenses under $100 another, and expenses over $100 a third style. What those styles are depend on you.

Easy - ternary operator on HStack - see above

Conditional list building

For a bigger challenge, try splitting the expenses list into two sections: one for personal expenses, and one for business expenses. This is tricky for a few reasons, not least because it means being careful about how items are deleted!

This was tricky, but I didn’t run into deletion problems. I thought I’d just run the ForEach twice and use an if inside it to build two different list sections. The compiler was very upset with this, saying something about not being able to determine the type in the view, but not being able to identify the view.

The solution for this turned out to be to put them inside a Group{}. I guess this means it’s something related to the ways Views are built and the magic inside the @ViewBuilder property wrapper.

 List {
 Section(header: Text("Personal")) {
 ForEach(expenses.items) { item in
 Group {
 if item.type == "Personal" {
 itemView(item: item)
 }
 }
 
 }
 .onDelete(perform: removeItems)
 }
 Section(header: Text("Business")) {
 ForEach(expenses.items) { item in
 Group {
 if item.type == "Business" {
 itemView(item: item)
 }
 }
 
 }
 .onDelete(perform: removeItems)
 }
 }
 .navigationTitle("iExpense")
 .toolbar{
 Button {
 showingAddExpense = true
 } label: {
 Image(systemName: "plus")
 }
 }

Times Tables -Day 35 Challenge

Sat, 01 Oct 2022 00:00:00 +0000

The challenge for Day 35 of 100 Days of Swift UI was to create a simple times tables drilling app. I’ve met all the requirements, so I’ll move on, but I am struck by how ugly it is. Making better looking apps needs to be added to my goals. Especially since this app is intended to appeal to children, and is at the end of a few lessons on animation, this is definitely a weakness of mine at the moment.

I enjoyed this challenge, it had a few interesting aspects. One was the number keypad for the user to enter, and the other one was creating the dialogue shown to the user at the end of a round with the statistics. I really don’t love the iOS modal dialogue boxes, so I ZStacked a rounded rectangle with some views on top of it, and controlled the visibility with .opacity. I wasn’t sure what would happen to the user OnTap events - would they go through? The answer is that if you make it very see through they go through to the elements underneath, but if it’s reasonably solid, they stay there.

Source

User Defaults & Horizontal Pickers

Wed, 28 Sep 2022 00:00:00 +0000

I’m on the challenges for Day 35 of 100 Days of SwiftUI, and despite Paul’s very clear warning:

Important: It’s really easy to get sucked into these challenges and spend hours…

I have spent ages fiddling around, but of course still learning. My issue is not so much getting stuck on bugs, rather I keep wanting to do things I don’t know how to do.

One issue was solved for my by the wonderful Fireside Swift podcast. I’m working through the old (Steve & Zac) episodes, and they did one on the UserDefaults just when I wanted to be able to persist the multiplication table selection the user had made (this challenge app is a multiplication tables drill app for kids).

First, because I hate hard coded strings, and they seem to be a thing in SwiftUI, and there’s no #const system, I’ve got an enum:

enum HCS: String {
 case operand = "Operand"
 case markerFeltWide = "Marker Felt Wide"
}

Then in the OnChange for the picker where I want to save/set the value into the default store:

.onChange(of: tablesSelection) { _ in 
 UserDefaults.standard.set(self.tablesSelection, 
 forKey: HCS.operand.rawValue)
 generateTable()
}

So basically, there’s a UserDefaults class that we can call the set method of, passing it the value we want to store, and a string value for the key.

Getting it back is no harder:

@State private var tablesSelection =
 UserDefaults.standard.integer(forKey: HCS.operand.rawValue)

Super simple!

If the key doesn’t exist, it returns a zero, so the slightly more complicated production version is:

@State private var tablesSelection =
 (UserDefaults.standard.integer(forKey: HCS.operand.rawValue) != 0) ? 
 UserDefaults.standard.integer(forKey: HCS.operand.rawValue) : 5

Now to my horizontal wheel picker that the user manipulates to chose which times-table they want to practice:

I love this little hack stolen from James on Stack Overflow. The first trick is that a .rotationEffect is applied to the picker, and the opposite .rotationEffect is applied to the selections. The second is to chop it off using the frame to make it a bit more compact.

Ranges

Sun, 25 Sep 2022 00:00:00 +0000

I wondered aloud, in a previous post, about the differences in writing a range as

 ForEach(1..<21) {
 Text(String($0))
 }

versus

 ForEach(1...20) {
 Text(String($0))
 }

And that’s been answered in in one of the Day 34 articles. It sounds like older versions of Swift might not have allowed the second version.

Animating Guess The Flag

Sat, 24 Sep 2022 00:00:00 +0000

The challenges for Project 6 of 100 Days of SwiftUI was to add some animations to the Guess the Flag app from a little while ago. The animations themselves were not particularly tricky, my main issue was that I was creating the views for the three flags in a ForEach, so the animations were applied to all three flags, but we wanted different animations for the flag the user had clicked versus those they had not.

I got around this by having the magnitude of the changes stored separately for each of the flag views - so they were all being animated, but some by a zero amount.

https://videopress.com/v/QjnVovjB?resizeToParent=true&cover=true&playsinline=true&preloadContent=metadata&useAverageColor=true

There’s three animations going on here, so three @State properties in the view:

Then attached to the code to create the buttons are all the modifiers for the animation.

In the FlagTapped() method you can see attached to the button there, we just change the ones we need:

Then, to be a little bit fancy, I re-animated the flagScales after the user closes the alert. I really do not love that alert - it was part of the tutorial project, but it is not a good UI - and it covers up some of the lovely animation.

Source

Animations in Views

Fri, 23 Sep 2022 00:00:00 +0000

It’s a very Apple-thinking thing to be learning about making beautiful and intuitive user experiences this early in a programing tutorial as I am with the 100 Days of Swift UI series. Here’s a quick look at three different ways of doing animation in SwiftUI Views.

Implicit animation

An implicit animation in SwiftUI is when you add a .animation() modifier to a view. It needs to be bound to the value that’s changing so the framework knows to animate when that value changes, and the nature of the change.

https://videopress.com/v/ItGiKMzz?resizeToParent=true&cover=true&preloadContent=metadata&useAverageColor=true

In the example above, the value that’s changing is rounded. We declare this as an @State variable, then in the .animation() modifier, we tell the framework to watch it. When it does change (because the user presses the bottom) SwiftUI considers the difference between the view rendered in rounded state, and in the non-rounded state, then generates and outputs the frames between them.

Binding animation

The .animation() modifier can be attached when a variable is bound to a control.

I’ve slightly complicated things here by adding the .timingCurve() inside the .animation() - otherwise the animation wasn’t obvious visually - the effect of this is just to slow down the animation so it keeps happening for a bit after you’ve adjusted the slider.

https://videopress.com/v/3caKJJkZ?resizeToParent=true&cover=true&autoPlay=true&controls=false&loop=true&preloadContent=metadata&useAverageColor=true

Explicit animation

Explicit animation is used when we want to control when the animation occurs, a common reason for this would be when we want to combine a couple of changes to take place simultaneously) .

https://videopress.com/v/6dE3XCSP?resizeToParent=true&cover=true&autoPlay=true&controls=false&loop=true&preloadContent=metadata&useAverageColor=true

Project 5 - Word Scramble

Mon, 19 Sep 2022 00:00:00 +0000

Another 100 Days of Swift UI project wrapped up - this time a scrabble like word game. New techniques included saving a large text file in the app bundle and loading it (via a string) into an array on launch of the view. Also a short adventure into UIKit to use a UITextChecker.

Source.

Word Scramble Feedback

Mon, 19 Sep 2022 00:00:00 +0000

As is my practice now, after completing the challenges for Project 5, I reviewed Paul’s solution (which is only available to subscribers) to see what he’d done better so I could learn from it.

Most of the differences where not of much significance, but there was a couple of things I picked up:

When the user had pressed the reset button, to empty the array of word guesses from the previous turn, I had

usedWords = [String]()

Whereas Paul had:

I have no idea if that’s better performing or safer, but to me, it’s a lot clearer, so I prefer Paul’s solution.

The second difference is a user experience one. I had chosen to put the score and reset button both in a bottom toolbar. It’s a good solution in the sense that it keeps the score and the reset buttons visible regardless of the size of the (scrollable) list. My code for this was appended to the bottom of the list:

.toolbar {
 ToolbarItem(placement: .bottomBar) {
 HStack {
 Text("Score: \(score)")
 Spacer()
 Button("New Word") { startGame() }
 }
 }
}

Paul used a SafeAreaInset appended to the bottom of the list, and as he was entering it I was thinking it was overly complex:

•safeAreaInset(edge:.bottom) {
 Text("Score: \(score)")
 .frame (maxWidth: .infinitv)
 .padding()
 .background( .blue)
 .foregroundColor(.white)
 .font(.title)

until I saw the result and loved it.