Xcode14 on blog.iankulin.com

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:

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
 }
}

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()

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

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.

Why?

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

Why do I have to resize this preview window every time I open Xcode?

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.

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)
 }

Where's My App?

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

The iOS apps I’ve been making, can only run in the simulator or on my tethered device (which I haven’t actually tried yet), but the MacOS app I made today, in theory could be zipped up and distributed to the world from my website. At the very least, I wanted to drop it into my Applications folder so I could use it, so I needed to find the .app “file”, and realised I had no idea where it was. If that’s your situation, then here’s the steps you need.

First of all, you are currently building debug versions of your app. We need to create a new Scheme for the release build. In Xcode use the menus to go to Product | Scheme | New Scheme…

Give it a sensible name - maybe <app name> Release or similar. Then Product | Scheme | Edit Scheme and on the Info tab, change it to a Release build.

Build the app (Product | Build ), then back in the Product menu, there’s an item “Show Build Folder in Finder”. Click on that, and there’s your different builds. In the Release folder will be the .app file that can be copied into your applications folder.

I’m not actually sure if this is a file, more likely a folder that MacOS is pretending is a file. If you right click on it and select “Show Package Contents” you can see the actual files inside it.

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

Gitting Xcode to Push

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

I’m very comfortable with doing all the routine git stuff from the command line, but it was bugging me that I hadn’t for the Xcode integration working. I was able to commit locally with no problem from Xcode, but could not push up to Github. It works fine from the command line, so the error about the change to a stronger SSH authentication didn’t really make sense to me.

ERROR: You’re using an RSA key with SHA-1, which is no longer allowed. Please use a newer client or a different key type.

This post from pasllani on the Apple Developer forums was super helpful, the only thing they missed was that you need to restart Xcode before it will work. The steps were:

Generate a new ECDSA SSH key with ssh-keygen -t ecdsa -C "IanKulin@kulin.com.au"
Copy the key to the keyboard with pbcopy < ~/.ssh/id_ecdsa.pub
On Github, add the new SSH key, and while you’re there, generate a new Token in Developer Tools
In XCode, delete your github account, then recreate it specifying SSH and choose the ECDSA key. It will need the access token at this stage.
Restart XCode

Other git/Github posts

Intro to git - Gitting Started
Common git commands - Gitting the Hang of it
Merge vs rebase
Create an Empty Folder on Github
Download a Directory from a Github repo
Download a File from Github

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.

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

Don't Use Stupid Project Names

Thu, 22 Sep 2022 00:00:00 +0000

I’m up to Day 32 of 100 Days of Swift UI, and although the tutorial is named “Project 6” it’s not really a project that becomes a simple app, it’s really just a series of tutorials on animation that I assume the techniques, but none of the code, will be used later in apps.

I do find there’s some value in typing in the code (rather than cutting and pasting, or just passively watching) so I opened up Xcode to follow along. There not being an app name offered, I used “Project 6 - Animation”. XCode seemed happy enough with that, and created the directory and placeholder, but then refused to build it saying there was seven errors involving the __PACKAGE_NAME macro and a missing }

I did a do-over with a project name of “Animation” and it works just fine. When I updated to XCode 14 I didn’t keep the previous version, so I’ve no idea if letting the user do this is an introduced bug or not. The culprit is the ‘-’. Projects with just a space in the name work fine.

Since a google of the first error does not pull up any hits, I’ll paste it in here for future travelers giving their projects names with dashes.

'___PACKAGENAME' is annotated with @main and must provide a main static function of type () -> Void, () throws -> Void, () async -> Void, or () async throws -> Void

As far as I can make out, that is part of the boilerplate creation process and should have been replaced. Likely the dash and the spaces are all replaced with underscores to make a valid app name and the triple underscore has a magic meaning of some kind.

Recording the Simulator

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

I’ve been using Quicktime to screen record the preview or simulator to document my work here and in Github ReadMe’s, but thanks to this excellent short post by Sarun W, I now know it’s possible to do that directly from the simulator, including capturing gestures, and exporting to animated gifs!

Changing Xcode Font Size

Tue, 20 Sep 2022 00:00:00 +0000

I’ve been changing the Xcode font size by going into the preferences, themes, then selecting the different content types and changing the font size.

I guess I could speed that process up by saving some themes with different text sizes, but I’ve noticed a few times in tutorial videos that there must have been an easier way. It turns out that Ctrl + “+” and Ctrl + “-” increases and decreases the code font size.

I’m not sure why I need to change the font size so often, but it was bugging me, so I’m glad to find there’s sensible shortcuts for it.

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.