100daysofswiftui on blog.iankulin.com

FriendFace 61 Feedback

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

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

Merge Policy

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

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

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

Data

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

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

MainActor

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

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

FriendFace Feedback

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

After each app, I use my HackingWithSwift+ membership to view Paul’s version of the app as a way to judge my performance. Yesterday’s app was “FriendFace” - download some JSON of a number of people (including their friends) and display it.

UUID

In my struct, I’d just specified the User.id as a string, Paul uses UUID - this makes no difference to the app as it stands, but is much better if we ever needed to add users.

Example

For my details preview, I created a fake user in the preview. Paul does something slightly nicer - with a static let example = User(…) as a property of the User struct. Again - not a biggy for this app, but handy if you need to use it for other previews.

fetchUsers()

I had a test in the .task() to prevent the double loading of data, Paul puts his here inside a guard. I think mine is simpler to read and understand, but Paul’s would be better if there was a chance we might call fetchUsers() from other places in the app. If that’s likely, this would be the third time out of three differences where Paul is anticipating a bigger app - it might just be a reflex for such an accomplished developer. However, I’m going to award this one to me.

do/catch

Paul’s JSON fetching and decoding is in a single do/catch block - as mine was in my first drafting, but then it didn’t work correctly so I changed it. I think we can assume Paul’s works - he’s a quality coder, and this code has had a lot of eyes on it by now. So this is something I need to understand better.

Apart from the two items above, the rest of fetchUsers was essentially the same.

List

Paul used little red or green circles to indicate the active status of users in his list - much nicer than my version of having the text. Apart from that, it was a NavigationView iwht a List with a NavigationLink to the detail view, so same same.

UserDetails

Instead of a form, Paul uses a List with a .listStyle of .grouped which probably follows the HIG better.

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 Feedback

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

As usual, I watch Paul’s solution video, and compare it to mine.

Task 1

This was passing in the predicate as a String. I passed the whole thing, but as I figured out along the way, Paul meant just the operator word. He also added some buttons to test it better, which I didn’t think of till Task 3 - it would have saved me some simulator runs.

Task 2

This was changing to enums. As I mentioned, I am a fan. Meanwhile, my solution was exactly the same as Paul’s, down to where he put the enum.

Task 3

Another FilteredList argument - this time the sort descriptors. I did get a bit bogged down in this. I followed the build error and was trying to use NSSortDescriptors and tying myself up in knots to get it to work. When I reread the task, I saw Paul’s hint to use SortDescriptor then it all came together - and we had the same solution.

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

You Can Take Big Steps When You Feel Safe

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

Day 58 of #100Days feels like complex topics are being dropped in pretty fast. We tackle one:many data relationships and how to set them up in CoreData, using CoreData constraints and setting a merge policy to manage conflicts, and even the underscore to access the actual property inside a wrapped property struct (needed for dynamic filtering in a view).

I’ve mentioned before that I think Paul Hudson is an excellent teacher, and an example of this is that even though this was a day with a lot of challenging material, I’m not worried. I followed the discussion and tried the code, and more importantly I’m anticipating these new skills will be practiced in the next app, and probably shortly after I’ll be writing an app using them.

When learners feel safe and supported, they are comfortable taking bigger risks. This has the effect of growing their Zone of Proximal Development and allows faster learning.

Some of the complexity around CoreData relates to it’s pre-SwiftUI age - it has a lot of power, and does a lot for the developer but is full of non-intuitive bits. The rest of the complexity is really just related to it’s job - any object graph persistence that’s going to allow us to think of, and work with, our data as native objects is going to have to expose some of the complexity of what’s happening underneath in order to provide the flexibility needed. What’s not so evident in this implementation is Swifts progressive disclosure of complexity. It’s easy to imagine a modern rewrite of a more Swift-like object persistence framework being less scary.

Since CoreData is using SQLite underneath, an interesting question is what the same code would look like if you pulled in an SQLite library and handled things manually - to approach the same functionality - ie not refetching when a view is recreated if the data hasn’t changed, lazy list building etc. My guess is: a lot more complex.

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

Top Four Reasons why @TwoStraws is a Good Teacher

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

Good Questions

At various points in the 100 Days of SwiftUI course, you get asked sets of questions to check you’ve understood the preceding material. They’re usually presented as two different statements, one of which is true, and the other false. It’s actually a really good technique - the student feels like they’ve got a couple of opportunities to figure it out, plus they are forced to read both statements and think about them. Paul does a similar thing in the Unwrapped app - there, the questions are often presented as “Is this valid Swift code” and the user needs to scan through it all looking for mistakes. It’s checking your understanding, and making you a thoughtful debugger!

Zone of Proximal Development

You know how if something is too easy, it’s not engaging? It’s why you don’t choose Snap when you sit down to play cards. It’s so far below your skill level your brain is not interested in it. There’s a similar problem at the other end - if I ask you do try something that’s so hard for you that you’ll never be able to achieve it, you want want to do it again. For good learning to take place, it’s important to pitch the difficulty of activities just ever so slightly in advance of what the student can comfortably do. This is the zone where the most learning takes place in the shortest amount of time.

Learning in Context

Logically, you could teach iOS development with a semester of pure Swift teaching before you got to your first app. Probably there are courses that do that, but if you want to engage your learners do it with as much real life context and hands-on activity as possible. #100Days is all about this.

Beginner Mind

In the videos/lessons, Paul often anticipates how the learner might expect something to work, or how they might tackle a problem, before explaining the problem with that thinking or showing a better way of doing things. This is a great trait of a teacher. Often it’s difficult for experts (which Paul undoubtedly is) to recall how things looked to them as they were learning. Anticipating the state of mind of the learner, and moving them from that point is both comforting for the learner, and avoids confusion.

Currency

As soon as you start googling problems and reading blog posts or StackOverflow answers, it becomes apparent that the rapid development of Swift and SwiftUI has a downside - a lot of the helpful information put out there is out of date. Like everyone, I’m amazed at the work Paul puts in to producing his massive amount of content, and then keeping it up to date. If there’s a Hacking With Swift result in a search you’ve made, that’s the one to click on.

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.

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.

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!

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

Animation Feedback

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

I had a look at Paul’s version of the challenge to animate the Guess The Flags app, and like me he’d hit on altering the amount of each animation depending on if it was the clicked on flag, but he’d done it with a lot less code - using the ternary operator in each of the modifiers - versus my approach of filling in an Int array for each of the effects and altering them depending on the user selection.

Another round to Paul!

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.

Project 4 Challenges

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

I’ve completed the Project 4 challenges (source) of the 100 Days of SwiftUI, no biggie - the increase in difficulty between each step of Paul’s bootcamp is small enough that it’s never too stressful, but large enough you feel like you’re progressing all the time.

Since I’ve paid to be a member of Hacking with Swift, one of the perks is to see Paul’s video solutions. I’ve not worries about it before, but I should - looking at them and comparing to my efforts is probably good feedback. So here’s the differences in our answers to the challenges.

Sections

When I changed the VStacks to Sections, I put the section title text at the top:

Section(header: Text("When do you want to wake up?")) {
 HStack {
 DatePicker("Please enter a time", selection: $wakeUp, 
 displayedComponents: .hourAndMinute).labelsHidden()
 }
}

Paul had his in a trailing closure at the bottom:

Section {
 DatePicker("Please enter a time", selection: $wakeUp, 
 displayedComponents: .hourAndMinute).labelsHidden()
}
header: {
 Text("When do you want to wake up?")
}

I thought mine was nicer, but then the very next thing he shows in the video is:

Section("When do you want to wake up?") {
 DatePicker("Please enter a time", selection: $wakeUp, 
 displayedComponents: .hourAndMinute).labelsHidden()
}

So there - I have learned something for an expert…

The next job was to change the stepper to a picker for the number of cups of coffee. I had something like this:

Section(header: Text("Daily coffee intake?") {
 Picker(coffeeAmount == 1 ? "1 cup" : "\(coffeeAmount) cups", 
 selection: $coffeeAmount) {
 ForEach(1...20, id: \.self) { i in
 if i == 1 {
 Text("1 cup")
 } else {
 Text("\(i) cups")
 }
 }
 }
}

And Paul:

Section("Daily coffee intake?") {
 Picker("Number of cups", selection: $coffeeAmount) {
 ForEach(1..<21) {
 Text(String($0))
 }
 }
}

so yeah, then when I looked at my output properly (see simulator image above) I noticed mine didn’t make sense anyway. My bad - that’s a horrid careless error.

I’m not sure about the difference in the ranges 1…20 and 1..<21 the ..< is a great habit for avoiding off by one errors with collections, perhaps that’s the reason for Paul’s choice there.

The third thing to do was to get rid of the alert, and show the result live as changes were made. I did mine by by adding a text field whose contents were a call to a slightly modified calculateBedtime() function. Paul moved that code up to a new computed property. I’m not sure I see any difference there except style.

So, that’s a worthwhile thing to do - to look at Paul’s solution and compare it to mine, so I’ll go on and do that in future.

Machine Learning

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

A few years ago when I still used a Tom-Tom for car navigation, I was a little freaked out when it started offering suggestions on where to go to when I started the car - guessing, usually correctly, where I wanted to go. Like - how did it know I was leaving school for band practice two towns over?

Clearly, is must have been collecting data on times/days and departure locations to learn some of my habits. It felt quite invasive, but I thought it must have been on-device since I had the wifi turned off in the unit.

In Day 27 of 100 Days of Swift UI we CoreML and use a dataset to train a model, then incorporate it in an App. The most shocking thing about it was how straightforward it was. In the example, the model was trained in CreateML from XCode and only used on the device, rather than trained on it, but current iPhones have the power to do that.

Obviously there’s some amazing things that can be done with machine learning, but I’m actually more excited about the small things - perhaps just offering better defaults for user inputs.

There’s a great intro to machine learning for Apple developers here.

Rock, Paper Scissors (2)

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

When I was forced by a deadline into delivering this project, I noted in its post that there was a number of improvements to make:

The rock paper scissors could be some better data structure than an array and some ints.

I don’t love the try to win, try to lose aspect, but the client specified it

Having the didUserWin and didComputerWin funcs is a cop out – that should probably be a single function returning a win/lose/draw type

I also am unhappy with nesting them in the view namespace to use my #consts

duplicating the last part of the view but making the elements .hidden() to keep the same spacing seems like a kludge

when I added the link to the Hacking With SwiftUI page with the app brief just now, I noticed I haven’t done the scoring the way it was asked for

Here’s the progress

The rock paper scissors could be some better data structure than an array and some ints

Done. Made a sweet swifty enum. Read about it here. That also solved #4

I don’t love the try to win, try to lose aspect, but the client specified it

We can’t always help what a client wants. Deal with it.

_Having the didUserWin and didComputerWin funcs is a cop out – that should probably be a single function returning a win/lose/dra_w

enum GameResult {
 case win
 case loss
 case draw
}

func gameResult(user: FingerShape, computer: FingerShape) -> GameResult {
 switch user {
 case .rock:
 switch computer {
 case .rock: return .draw
 case .paper: return .loss
 case .scissors: return .win
 }
 case .paper:
 switch computer {
 case .rock: return .win
 case .paper: return .draw
 case .scissors: return .loss
 }
 case .scissors:
 switch computer {
 case .rock: return .loss
 case .paper: return .win
 case .scissors: return .draw
 }
 }
}

duplicating the last part of the view but making the elements .hidden() to keep the same spacing seems like a kludge

This was an issue - not just because of the mess of code, but because (according to Paul) it’s a workload issue - the view managing part of SwiftUI has to keep creating and destroying parts of our view instead of recycling them. In an earlier lesson, he encouraged the use of the ternary operator in modifiers to avoid this - but .hidden() doesn’t have any arguments. Here’s the sort of code I’m talking about - I’ve got this sort of thing several places.

if revealResult {
 Text(computerSelection.rawValue)
 .font(.system(size: 200))
 Text(winText).font(.title)
 Spacer()
 Button("Play again") {
 goalIsWinThisTurn = Bool.random()
 revealResult = false
 if showScores {
 score = 0
 numberOfPlays = 0
 showScores.toggle()
 }
 }
 .buttonStyle(CustomButtonStyle())
}
else {
 Text(computerSelection.rawValue)
 .font(.system(size: 200))
 .hidden()
 Text(winText)
 .font(.title)
 .hidden()
 Spacer()
 Button("Play again") {}
 .buttonStyle(CustomButtonStyle())
 .hidden()
}

I was surprised when googling something like “swiftui view visibility not hidden()” I found, instead of a stack overflow question, a nice Apple tutorial at the top of the links.

Within was my answer - most views have an .opacity() modifier. With that, the code above becomes:

Group {
 Text(computerSelection.rawValue)
 .font(.system(size: 200))
 Text(winText).font(.title)
 Spacer()
 Button("Play again") {
 goalIsWinThisTurn = Bool.random()
 revealResult = false
 if showScores {
 score = 0
 numberOfPlays = 0
 showScores.toggle()
 }
 }
 .buttonStyle(CustomButtonStyle())
}
.opacity(revealResult ? 1 : 0)

Noice. I then when on a ternary insertion spree that dropped my view body down from 74 lines of code to 52 and improved readability substantially.

Current source

Rock, Paper, Scissors (1)

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

As I mentioned yesterday, I needed to make some progress to blog about, and I had a half working version of a Rock, Paper, Scissors for Day 25 so I pushed myself to get that working.

There’s lots in the code below I don’t love.

The rock paper scissors could be some better data structure than an array and some ints.
I don’t love the try to win, try to lose aspect, but the client specified it
Having the didUserWin and didComputerWin funcs is a cop out - that should probably be a single function returning a win/lose/draw type
I also am unhappy with nesting them in the view namespace to use my #consts
duplicating the last part of the view but making the elements .hidden() to keep the same spacing seems like a kludge
when I added the link to the Hacking With SwiftUI page with the app brief just now, I noticed I haven’t done the scoring the way it was asked for

source on github

struct ContentView: View { @State var score = 0 @State var goalIsWinThisTurn = Bool.random() @State var userSelection = 0 @State var computerSelection = 0 @State var winText = ""

// game has two modes - revealResult - buttons don't work, and we can see the computer result
// or not readyToPlay - user can chose their play
@State var revealResult = false

let rock = 0
let paper = 1
let scissors = 2
let rpsEmoji = \["🪨", "📃", "✂️"\]

 
var body: some View {
 ZStack{
 LinearGradient(colors: \[.white, .gray\], startPoint: .top, endPoint: .bottom)
 VStack{
 Button("Score: \\(score)"){
 score = 0
 }
 .font(.title)
 .foregroundColor(.primary)
 
 Spacer()
 if goalIsWinThisTurn {
 Text("Try to win")
 .font(.title)
 }
 else {
 Text("Try to lose")
 .font(.title)
 }
 
 Spacer()
 HStack{
 Spacer()
 Button(rpsEmoji\[rock\]) {
 processButton(selection: rock)
 }
 Spacer()
 Button(rpsEmoji\[paper\]) {
 processButton(selection: paper)
 }
 Spacer()
 Button(rpsEmoji\[scissors\]){
 processButton(selection: scissors)
 }
 Spacer()
 }.font(.system(size: 60))
 
 Spacer()
 if revealResult {
 Text(rpsEmoji\[computerSelection\])
 .font(.system(size: 200))
 Text(winText).font(.title)
 Spacer()
 Button("Play again") {
 goalIsWinThisTurn = Bool.random()
 revealResult = false
 }
 .buttonStyle(CustomButtonStyle())
 }
 else {
 Text(rpsEmoji\[computerSelection\])
 .font(.system(size: 200))
 .hidden()
 Text(winText)
 .font(.title)
 .hidden()
 Spacer()
 Button("Play again") {
 goalIsWinThisTurn = Bool.random()
 revealResult = false
 }
 .buttonStyle(CustomButtonStyle())
 .hidden()
 }
 Spacer()
 }
 }
}

func didUserWin(user: Int, computer: Int) -> Bool {
 switch(user) {
 case rock:
 switch(computer) {
 case scissors: return true
 default: return false
 }
 case paper:
 switch(computer) {
 case rock: return true
 default: return false
 }
 case scissors:
 switch(computer) {
 case paper: return true
 default: return false
 }
 default:
 assert(false)
 return false
 }
}

func didComputerWin(user: Int, computer: Int) -> Bool {
 switch(computer) {
 case rock:
 switch(user) {
 case scissors: return true
 default: return false
 }
 case paper:
 switch(user) {
 case rock: return true
 default: return false
 }
 case scissors:
 switch(user) {
 case paper: return true
 default: return false
 }
 default:
 assert(false)
 return false
 }
}

func processButton(selection: Int) {
 if !revealResult {
 computerSelection = Int.random(in: 0...2)
 userSelection = selection
 if didUserWin(user: userSelection, computer: computerSelection) {
 winText = "You win"
 if goalIsWinThisTurn {
 score += 1
 winText = "You win"
 } else {
 score -= 1
 winText = "You win, sorry"
 }
 } else if didComputerWin(user: userSelection, computer: computerSelection) {
 if goalIsWinThisTurn {
 score -= 1
 winText = "You lose, sorry"
 } else {
 score += 1
 winText = "You lose!"
 }
 } else {
 winText = "Draw"
 }
 revealResult = true
 }
}

}

struct CustomButtonStyle : ButtonStyle { func makeBody(configuration: Configuration) -> some View { configuration.label .font(.title) .padding(10) .foregroundColor(.white) .background(Color.blue) .cornerRadius(5) } }

.self in ForEach

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

I’m on Day 25 of Hacking With SwiftUI, and Paul is making a point about how SwiftUI can loop over an array to build a view. He starts with this:

let agents = ["Cyril", "Lana", "Pam", "Sterling"]
VStack {
 ForEach(0..<agents.count) {
 Text(agents[$0])
 }
}

But then proposes an alternative:

let agents = ["Cyril", "Lana", "Pam", "Sterling"]
VStack {
 ForEach(agents, id: \.self) {
 Text($0)
 }
}

He explains the use of \.self here by saying

So, we come back to how Swift can identify values in our array. When we were using a range such as 0..<5 or 0..<agents.count, Swift knew for sure that each item was unique because it would use the numbers from the range – each number was used only once in the loop, so it would definitely be unique.

In our array of strings that’s no longer possible, but we can clearly see that each value is unique: the values in ["Cyril", "Lana", "Pam", "Sterling"] don’t repeat. So, what we can do is tell SwiftUI that the strings themselves – “Cyril”, “Lana”, etc – are what can be used to identify each view in the loop uniquely.

I’m having a couple of problems with this.

Grumble One

The first is that Swift can’t really use the “strings themselves”. So this doesn’t work:

ForEach(agents, String($0)) {
 Text($0)
}

It complains that there’s no initialiser to take those arguments. So \.self must be something fancier. This is something I can presumably investigate by looking at the initialisers for ForEach.

Grumble Two

And the second grumble is that the first formulation ForEach(0..<agents.count) throws a compiler warning “Non-constant range: argument must be an integer literal”

Which is true, if I swap it for the number ‘4’ it stops complaining. I guess in the initialiser for ForEach there’s something specifying this although it’s not clear to me why. Again it’s an initialiser mystery because I can make the warning go away by adding the id reference to self.

Googling for the warning finds a page on the Hacking with Swift forums that throws a little bit of light on the issue by looking at the inits.

The difference between these two that we’re interested in is that in the first, the type is Range, and the second Data. @RoosterBoy’s explanation for why we should use literal ints for the range is that it’s to be safe from the array changing size during the loop - which is slightly unsatisfying because that could still happen with the literal int range.

Grumble One again

These initialisers also shed some light on my first problem, the references used by SwiftUI should be KeyPaths. Sarun’s explanation of them makes them sound like actual references - ie memory addresses for the properties. That would make sense since SwiftUi wants them to keep track of things.

So I tried this:

ForEach(agents, id: \String.$0) {
 Text($0)
}

but the compiler is still unhappy - so clearly I am not knowledgeable enough yet to solve this one.

Project 3

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

This one’s not really a project, just a couple of little updates to earlier work, and a code snippet.

Challenge 1

Go back to project 1 and use a conditional modifier to change the total amount text view to red if the user selects a 0% tip.

The first one is pretty simple - a ternary condition to make the total red if the tip is set to zero.

Text(grandTotal, format: currencyCode) .foregroundColor(tipPercentage == 0 ? .red : .primary)

The ternary operator is like a little inline if then else statement. It has the format:

(w ? t : f)

where w is the condition, t is the code if the condition is true and f is the code if the condition is false. So the code above checks if the tipPercentage is zero, if it is, the grandTotal text is red, otherwise it’s coloured .primary - one of the semantic colors. The semantic colours are colours set by the system and referred to by their purpose. In this case it will be black (the “primary” text colour), unless I change the theme to dark mode, in which case it will be white.

Source

Challenge 2

Go back to project 2 and replace the Image view used for flags with a new FlagImage() view that renders one flag image using the specific set of modifiers we had.

Again, pretty straightforward. I just made a new view struct in the main view.

struct FlagView: View { var flagOf: String

 var body: some View {
 Image(flagOf)
 .renderingMode(.original)
 .shadow(radius: 5)
 }

}

Then called it with our flag name.

ForEach(0..<3) { number in Button { // flag was tapped flagTapped(number) } label: { FlagView(flagOf: countries[number]) } }

Source

Challenge 3

Create a custom ViewModifier (and accompanying View extension) that makes a view have a large, blue font suitable for prominent titles in a view.

struct ContentView: View { var body: some View { VStack{ Text(“Hello World”) .titleStyle() Spacer() } } }

struct ProminentTitle: ViewModifier { func body(content: Content) -> some View { content .font(.largeTitle) .foregroundColor(.blue) .padding() } }

extension View { func titleStyle() -> some View { modifier(ProminentTitle()) } }

Day 23 - Views and Modifiers - Part 4

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

Then the last trick for for decomposing the views, is to remember we can pass values when we init a struct. So something like this:

struct ContentView: View {

var body: some View {
 VStack{
 GreenPaddedText(text: "Hello")
 GreenPaddedText(text: "world")
 }
}


struct GreenPaddedText: View {
 var text: String

 var body: some View {
 Text(text)
 .foregroundColor(.green)
 .padding()
 }
}

}

This is probably my favourite - because although in this example I’ve created the mini-view struct in the body, if it’s a building block I can use elsewhere in a different view, it’s super portable.

Day 23 - Views and Modifiers - Part 3

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

The next part of day 23 started to make my brain hurt a bit. It’s easy to imagine that when presenting a complex screen - perhaps some data from a source as a mixture of images and text loaded from a database into a scroll-able view, that the view may start to get complex. Then it becomes good practice to decompose the views to make the code clearer, less error prone, and to avoid any unnecessary repetition.

Paul’s first suggestion is to pull some parts of the view as properties of the same view.

struct ContentView: View {

let greenText = Text("Hello").foregroundColor(.green)

var body: some View {
 VStack{
 greenText
 greenText
 }
}

}

This works fine, and exactly how you expect, except that if you don’t enclose it in the VStack, you just get one Text, but two ContentPreviews. I do not understand why yet, but its probably something to do with the @ViewBuilder property wrapper.

But… a property can’t refer to another property, so this isn’t compilable Swift:

To get around this, we can use a computed property. So this works:

struct ContentView: View {

@State private var greeting = "Hello"

var greenText: some View {
 Text(greeting).foregroundColor(.green)
}

var body: some View {
 VStack{
 greenText
 greenText
 }
}

}

In fact, this is what I’ve been doing so far to decompose views, although I’ve been dropping the segments underneath the main body to make things subjectively neater.

Paul cautions about returning multiple views in this computed property manner. So this does not work:

That makes sense - we were relying on the implied return. Putting them in a VStack would work - because we’re just returning a single view (the VStack) which happens to contain multiple views.

struct ContentView: View {

@State private var greeting = "Hello"

var body: some View {
 VStack{
 greenText
 greenText
 }
}

var greenText: some View {
 VStack{
 Text(greeting).foregroundColor(.green)
 Text(greeting).foregroundColor(.green)
 }
}

}

There’s another view container type called Group which is like a stack, but just contains, rather than arranging, a collection of views, that can be used in the same way.

Alternatively, and I assume this is related to the problem I had above, we can just wrap the property with the @ViewBuilder attribute.

struct ContentView: View {

@State private var greeting = "Hello"

var body: some View {
 VStack{
 greenText
 greenText
 }
}

@ViewBuilder var greenText: some View {
 Text(greeting).foregroundColor(.green)
 Text(greeting).foregroundColor(.green)
}

}

Day 23 - Views and Modifiers - Part 2

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

Although “immutable” the view structs can contain some control statements such as if/then and for loops. So this is quite legal, and useful.

struct ContentView: View { @State private var likesGreen = true

var body: some View {
 if likesGreen {
 Text("Hello World")
 .background(.green)
 }
 else
 {
 Text("Hello World")
 .background(.blue)
 }
}

}

But Paul cautions against this, saying:

You can often use regular if conditions to return different views based on some state, but this actually creates more work for SwiftUI – rather than seeing one Button being used with different colors, it now sees two different Button views, and when we flip the Boolean condition it will destroy one to create the other rather than just recolor what it has.

Instead, he encourages the use of the ternary operator in modifiers for these situations. The ternary operator is like an if/then/else statement packaged up neatly. So the code above becomes:

struct ContentView: View { @State private var likesGreen = true

var body: some View {
 Text("Hello World")
 .background(likesGreen ? .green : .blue)
}

}

He’s not arguing that it’s neater, but also that it’s more efficient - that the first version has to destroy and create a Text when the value of the flag changes, whereas the second one just changes the colour. I assume he’s correct, but it’s not obvious why that would be so. It must be in the magic of how SwiftUI optimises how and when it renders each part of a view.

Day 23 - Views and Modifiers - Part 1

Wed, 31 Aug 2022 00:00:00 +0000

I found this one of the trickier days, so I’ll write it out to clear up my thinking.

To draw to to screen in SwiftUI, we don’t call a command to draw on a canvas or window. Rather, a view is defined as an immutable struct of type some View. Here’s the simple one from the default Xcode project.

struct ContentView: View { var body: some View { Text(“Hello, world!”) .padding() } }

The body var must be present, and can contain up to ten views. This simple example only contains one view - a text box. There are container view types that can, well, contain other views - for example a HStack which arranges its content horizontally.

struct ContentView: View { var body: some View { HStack { Text(“Hello, world!”) .padding() Rectangle() .frame(width: 100, height: 100, alignment: .center) }

}

produces:

Having defined our view struct, we don’t call for it to be rendered on the screen, SwiftUI is just going to do that for us whenever it thinks it needs to. This seems bizarre at first, but you get used to it. It will happen when it needs to - usually because the information that makes up the view has changed. We help that to happen by binding the views to their data in various ways. More on that another day.

If you look back at the code above, you’ll see that views often have modifiers attached to them. In our example the padding() on the text and the .frame() on the rectangle. There’s many different modifiers for all of the different view primitives. Many of them are common to different primitives, some are different. It’s possible to attach them to container views - in which case they are applied to all the views in the container. For example, if we move the .frame() to the HStack, like this:

struct ContentView: View { var body: some View { HStack { Text(“Hello, world!”) .padding() Rectangle() } .frame(width: 100, height: 100, alignment: .center) } }

We get

The order of the modifiers is important. You can think of each modifier that’s added as wrapping around the view and any previous modifiers. In this example, we’ve got the same text field with the .padding() and .background(.blue) modifiers. The left one has the padding first, then is wrapped in the blue background. The right one has the blue background applied first, then the padding.

Project 2 - Guess the Flag

Wed, 31 Aug 2022 00:00:00 +0000

Another 100 Days project - the second tutorial one. This was once again a “V” design pattern (put everything in the view) and as I kept growing it, especially in the challenges, I had a growing sense of unease.

New things for me was how image assets work - identifying them with strings is convenient, but I’m hoping there’s safer system later using enums or something to avoid runtime surprises. Also the alert dialog box system. I was wondering how this was going to work in a declarative framework. I do not really approve of modal dialogs in mobile UI’s but I guess they have their place. I appreciated the gradients and frosted glass effects -super simple to implement, and if done thoughtfully, pretty.

Source/Github

Challenge 1

Mon, 29 Aug 2022 00:00:00 +0000

I’m up to Challenge 1 of 100 Days of SwiftUI (Day 19) which is to make your own simple (no MVVM) version of the app built in the previous three days. It’s about as simple as can be whilst still feeling like a real app. Something I hadn’t done before was limiting the keyboard to numbers or adding a toolbar to close it, so that was nice.

Something that’s not nice, is that when you touch into the text field to change the number, it’s not selected ready to type over (the way they always are in browser url fields) so you need to backspace over the previous entry. That’s the sort of anoying behaviour I don’t like. It seems (after some googling) there’s no straightforward way of addressing this in SwiftUI, with the best solution involving importing a package. I will come back to that because it is bugging me.

struct ContentView: View { @State private var fromDistance = 0.0 @State private var fromUnits = “meters” @State private var toUnits = “kilometers” @FocusState private var distanceIsFocused: Bool

let distanceUnits = \["meters", "kilometers", "yards", "miles"\]

var toDistance: Double {
 var meters = 0.0
 // convert the from distance to meters
 switch fromUnits {
 case "meters": meters = fromDistance
 case "kilometers": meters = fromDistance\*1000
 case "yards": meters = fromDistance\*0.9144
 case "miles": meters = fromDistance\*1609.34
 default: assert(false)
 }
 // convert the meters to the from distance
 switch toUnits {
 case "meters": return meters
 case "kilometers": return meters/1000
 case "yards": return meters/0.9144
 case "miles": return meters/1609.34
 default : assert(false)
 }
 return 0.0
}


var body: some View {
 NavigationView {
 Form {
 
 Section {
 TextField("Distance", value: $fromDistance, format: .number)
 .keyboardType(.decimalPad)
 .focused($distanceIsFocused)
 Picker("Units", selection: $fromUnits) {
 ForEach(distanceUnits, id: \\.self) {
 Text($0)
 }
 }
 .pickerStyle(.segmented)
 }
 header: {
 Text("Distance")
 }
 
 Section {
 if toDistance < 9.9 {
 Text("\\(toDistance, specifier: "%.4f")")
 } else if toDistance > 999 {
 Text("\\(toDistance, specifier: "%.0f")")
 } else {
 Text("\\(toDistance, specifier: "%.2f")")
 }

 Picker("Units", selection: $toUnits) {
 ForEach(distanceUnits, id: \\.self) {
 Text($0)
 }
 }
 .pickerStyle(.segmented)
 }
 header: {
 Text("Converted Distance")
 }
 
 }
 .navigationTitle("Distance Conversion")
 .toolbar {
 ToolbarItemGroup(placement: .keyboard) {
 Spacer()
 Button("Done") {
 distanceIsFocused = false
 }
 }
 }
 }
}

}

Source on Github

$==Commitment

Sun, 28 Aug 2022 00:00:00 +0000

Paul Hudson’s 100 Days of Swift UI course is free - the videos are on YouTube, all the reading and tasks are available on his website for free. Although I assumed he made his living from the prodigious number of Swift books he’s written, he doesn’t push them in the course (except for his free book Swift UI by Example).

He’s so unpushy, I didn’t realise till a few days ago that you could pay to become a “subscriber” to Hacking with Swift. Really, he’s too nice.

There are some goodies that come with the + subscription (one I’m likely to use later is the book discount) , but really I was very happy to sign up for a year for a couple of reasons:

Paul is a major contributor to the Swift community, and especially to beginners like me. The world is a better place if he can afford to keep doing that.
This extra commitment, which is a tiny fraction of what I could spend on a bootcamp, makes it more likely I’ll complete the course, and puts a time limit on it - if I don’t complete it in the year, I’ll feel compelled to pay again.

Checkpoint 9

Sat, 20 Aug 2022 00:00:00 +0000

/* Your challenge is this: write a function that accepts an optional array of integers, and returns one randomly. If the array is missing or empty, return a random number in the range 1 through 100.

If that sounds easy, it’s because I haven’t explained the catch yet: I want you to write your function in a single line of code. No, that doesn’t mean you should just write lots of code then remove all the line breaks – you should be able to write this whole thing in one line of code.

https://www.hackingwithswift.com/quick-start/beginners/checkpoint-9

func randomInt(_ numbers:[Int]?) -> Int { numbers?.randomElement() ?? Int.random(in:1…100) }

print(randomInt(nil)) print(randomInt([2,5]))

Checkpoint 8

Wed, 17 Aug 2022 00:00:00 +0000

/* Your challenge is this: make a protocol that describes a building, adding various properties and methods, then create two structs, House and Office, that conform to it.

Your protocol should require the following: A property storing how many rooms it has. A property storing the cost as an integer (e.g. 500,000 for a building costing $500,000.) A property storing the name of the estate agent responsible for selling the building. A method for printing the sales summary of the building, describing what it is along with its other properties.

https://www.hackingwithswift.com/quick-start/beginners/checkpoint-8

protocol Building { var rooms: Int {get set} var cost: Int {get set} var realEstateAgent: String {get set} }

extension Building { func printSalesSummary(){ print(“Rooms: \(rooms) Cost: £\(cost) Agent: \(realEstateAgent)”) } }

struct House: Building { var rooms: Int var cost: Int var realEstateAgent: String var occupants: Int }

struct Office: Building { var rooms: Int var cost: Int var realEstateAgent: String var floorArea: Int }

var myOffice = Office(rooms: 5, cost:500_000, realEstateAgent: “Bloggs”, floorArea: 500) var myHouse = House(rooms: 2, cost:200_000, realEstateAgent: “Fletchers”, occupants: 1)

myOffice.printSalesSummary() myHouse.printSalesSummary()

Checkpoint 7

Mon, 15 Aug 2022 00:00:00 +0000

/* Your challenge is this: make a class hierarchy for animals, starting with Animal at the top, then Dog and Cat as subclasses, then Corgi and Poodle as subclasses of Dog, and Persian and Lion as subclasses of Cat.

But there’s more: The Animal class should have a legs integer property that tracks how many legs the animal has. The Dog class should have a speak() method that prints a generic dog barking string, but each of the subclasses should print something slightly different. The Cat class should have a matching speak() method, again with each subclass printing something different. The Cat class should have an isTame Boolean property, provided using an initializer.

https://www.hackingwithswift.com/quick-start/beginners/checkpoint-7

class Animal { var legs = 4 init(legs: Int) { self.legs = legs } }

class Dog: Animal { func speak() { print(“woof”) } }

class Corgi: Dog { override func speak() { print(“Your Majesty?”) } }

class Poodle: Dog { override func speak() { print(“yip”) } }

class Cat: Animal { var isTame: Bool

init (isTame: Bool, legs: Int) {
 self.isTame = isTame
 super.init(legs: legs)
}

func speak() { print("meow") }

}

class Persian: Cat { override func speak() { print(“hiss”) }

init() { super.init (isTame: true, legs: 4 ) }

}

class Lion: Cat { override func speak() { print(“rawr”) }

init() { super.init (isTame: false, legs: 4 ) }

}

let lion = Lion() print(lion.legs)

Checkpoint 6

Sat, 23 Jul 2022 00:00:00 +0000

/*
create a struct to store information about a car, including its model, number of seats, and current gear, then add a method to change gears up or down. Have a think about variables and access control: what data should be a variable rather than a constant, and what data should be exposed publicly? Should the gear-changing method validate its input somehow?
*/

struct Car {
 static let maxGear = 10
 static let minGear = 1
 var model = "no model"
 var seats = 4
 private (set) var currentGear = Car.minGear
 
 init (model: String, seats: Int) {
 self.model = model
 self.seats = seats
 }
 
 mutating func gearUp() {
 if currentGear < Car.maxGear{
 currentGear += 1
 }
 }
 
 mutating func gearDown() {
 if currentGear > Car.minGear{
 currentGear -= 1
 }
 }
 
}

var myUte = Car(model: "Rodeo", seats:2)
print("My \(myUte.model) has \(myUte.seats) seats and is in gear: \(myUte.currentGear)")
myUte.gearDown()
print("My \(myUte.model) has \(myUte.seats) seats and is in gear: \(myUte.currentGear)")
myUte.gearUp()
print("My \(myUte.model) has \(myUte.seats) seats and is in gear: \(myUte.currentGear)")

struct

Mon, 18 Jul 2022 00:00:00 +0000

Started on Day 10 of 100 days of etc etc today which is about structs. It was immediately clear when I first started looking at Swift and Swift UI that structs were going to be a big deal. I am used to structs being able to contain a collection of other types, but not methods. So I was confused at why tuples existed; that is now cleared up.

If structs can have methods as well as properties, it answers the question of why tuples exist, but immediately asks the question, why have classes since structs have all this power? I already know (from my podcast consumption) one of the answers for this is that structs are value types rather than references. When you:

let someConstant = someClass

someConstant now contains a copy of the pointer to someClass, as opposed to making a copy as similar code would do for a struct. So this code:

struct SomeStruct {
 var counter: Int = 0
}

var structInstance = SomeStruct()
var someOtherStruct = structInstance

print("structInstance:\(structInstance.counter)")
print("someOtherStruct:\(someOtherStruct.counter)")

someOtherStruct.counter += 1

print("structInstance:\(structInstance.counter)")
print("someOtherStruct:\(someOtherStruct.counter)")

print("")

class SomeClass {
 var counter: Int = 0
}

var classInstance = SomeClass()
var someOtherClass = classInstance

print("classInstance:\(classInstance.counter)")
print("someOtherClass:\(someOtherClass.counter)")

someOtherClass.counter += 1

print("classInstance:\(classInstance.counter)")
print("someOtherClass:\(someOtherClass.counter)")

Produces the output:

structInstance:0
someOtherStruct:0
structInstance:0
someOtherStruct:1

classInstance:0
someOtherClass:0
classInstance:1
someOtherClass:1

The sample code for the Hello World app in playgrounds ONLY contains structs. The app is a struct, containing a view which is a struct. That’s basically all there is, so clearly structs are going to be a big deal.

Checkpoint 5

Sat, 16 Jul 2022 00:00:00 +0000

/*
 Your input is this:
 
 let luckyNumbers = [7, 4, 38, 21, 16, 15, 12, 33, 31, 49]
 
 Your job is to:
 
 Filter out any numbers that are even
 Sort the array in ascending order
 Map them to strings in the format “7 is a lucky number”
 Print the resulting array, one item per line
 
 So, your output should be as follows:
 
 7 is a lucky number
 15 is a lucky number
 21 is a lucky number
 31 is a lucky number
 33 is a lucky number
 49 is a lucky number
 */

let luckyNumbers = [7, 4, 38, 21, 16, 15, 12, 33, 31, 49]

func isNumberOdd(number:Int) -> Bool {
 return number%2 == 1
}

let filteredNumbers = luckyNumbers.filter(isNumberOdd)

// this closure effectively does nothing
let sortedNumbers = filteredNumbers.sorted(by: {$0<$1}) 

let mappedNumbers = sortedNumbers.map({ String($0)+" is a lucky number" })

for i in 0..<mappedNumbers.count {
 print(mappedNumbers[i])
}

Checkpoint 4

Wed, 13 Jul 2022 00:00:00 +0000

/*
 The challenge is this: write a function that accepts an integer from 1 through 10,000, and returns the integer square root of that number. That sounds easy, but there are some catches:
 
 You can’t use Swift’s built-in sqrt() function or similar – you need to find the square root yourself.
 If the number is less than 1 or greater than 10,000 you should throw an “out of bounds” error.
 You should only consider integer square roots – don’t worry about the square root of 3 being 1.732, for example.
 If you can’t find the square root, throw a “no root” error.
 */

enum IntSqrtError: Error {
 case low, high, noIntRoot
}

func calculateIntSqrt(_ number:Int) throws -> Int {
 let lowerBound = 1
 let upperBound = 10_000
 if number < lowerBound {throw IntSqrtError.low}
 if number > upperBound {throw IntSqrtError.high}
 // brute force sqrt finder
 for i in lowerBound...number {
 if i*i == number {
 return i
 }
 }
 // none found or we would have returned by now
 throw IntSqrtError.noIntRoot
}

do {
 try print(calculateIntSqrt(5929))
} catch IntSqrtError.low {
 print("Lower bound error")
} catch IntSqrtError.high {
 print("Upper bound error")
} catch IntSqrtError.noIntRoot {
 print("No integer root")
} catch {
 assert(false)
 print("Unknown error")
}

Tuple Pronunciation

Tue, 12 Jul 2022 00:00:00 +0000

Another advantage of the videos, that hadn’t occurred to me when I mentioned it the other day, is learning the correct pronunciation of things you’ve only ever read in books.

Apparently, tuple is pronounced two-pull, and not with the tup to rhyme with cup as I’d always imagined. Google has confirmed, so it’s not just a UK thing.

Watch or Read

Sun, 10 Jul 2022 00:00:00 +0000

I’m appreciating, in the 100 Days of Swift UI, that Paul Hudson has provided a video and a text description for each of the topics. Usually, I’ll read the text - a lot of these early topics cover ground well-trodden from my previous experience, so I can skim forwards to find the Swift specific bits I need. However, if I’m making up my hour per day of Swift by multitasking it with a meal, then the video is handy.

The content in the videos and the text is not identical either (in the couple I’ve watched), so if a concept is not clear, having some slightly different explanations is handy.

Checkpoint 3

Fri, 08 Jul 2022 00:00:00 +0000

 /*
 If it’s a multiple of 3, print “Fizz”
 If it’s a multiple of 5, print “Buzz”
 If it’s a multiple of 3 and 5, print “FizzBuzz”
 Otherwise, just print the number.
 */

for i in 1...100 {

 let isMultOfThree = (i % 3 == 0)
 let isMultOfFive = (i % 5 == 0)

 if (isMultOfFive && isMultOfThree) {
 print("FizzBuzz")
 } else if isMultOfThree {
 print("Fizz")
 } else if isMultOfFive {
 print("Buzz")
 } else {
 print(i)
 }
}

100 days of SwiftUI

Tue, 05 Jul 2022 00:00:00 +0000

Paul Hudson’s intro to his IOS development course asks participants to post on social media each day as part of an effort to keep them motivated. The Insta tag #100daysofswiftui is full of curated photos of MacBook Pros showing Xcode 14. This also seems like handy marketing for Paul.

It’s not a crazy idea, so I’ll add this to the long list of excitedly started and eventually abandoned blogs of the world. Perhaps a post will even help a forlorn google searcher out on day. I’ll aim to keep them short, so it does not become a large enough task to trigger it’s own procrastination.

Other things I’ve found in the past to help conserve a sustained effort in new learning is to find some good weekly podcasts, and to have a clear short term goal. This will be to get a simple, but minimally useful app up published on the App Store.