Code on blog.iankulin.com

Using LLMs for coding

Mon, 01 Jul 2024 00:00:00 +0000

This post looks at the context for some of my thinking about AI for supporting software development, and where I’ve landed on it for the time being.

The landscape

I briefly wrote about ChatGPT’s coding ability at the end of 2022. The wide availability of this tool marked the beginning of what I think can fairly be described as a revolution. The controversies that have crystalised since have not dampened my amazement of this step forward in what compute can do, especially around natural language processing.

The next big news in this story was Microsoft’s launch of Github Copilot. In business terms this was a brilliant move - owning the most popular code editor, and leveraging the world’s biggest collection of public code to create a product that millions of people are prepared to pay $10 a month for can only be regarded as a success.

At the same time as Microsoft established a new revenue stream, LLMs have been an exciting area of open source growth, especially the excellent Python libraries and the tools in the LangChain ecosystem.

It’s not all rainbows and unicorns though - there’s a few valid points that AI skeptics have coalesced around.

Training data - although this is a bigger issue for general models (where masses of web content has been vacuumed up) than it is for code, it is still an issue. If a model is trained on some non-permissively licensed code, and the generative AI I’m using includes that code in a commit, then a license, or at least some ethics have been breached.
Quality (1) - You can see from the feature images in many of the posts in this blog during my MidJourney enthusiasm that generative AI is not perfect. Before I abandoned them I started to prefer the mangled writing and fingers of the engines, but no one wants the software equivalent of mangled fingers in their codebases. I suspect this particular aspect of the quality of the code will probably have a technological solution - we’re in the very early days after all.
Quality (2) - A trickier quality problem is people writing code using AI where they do not fully understand the code they are committing. I imagine this is going to be a growing issue for projects, especially anything with a profit motive such as bug bonuses. Projects have mechanisms like code reviews and pull requests, but if submissions can be low-effort and checking them is high-effort, that asymmetry is going to be painful.
Poisoned well - As the amount of AI code in codebases increases, then AI is trained on those codebases this will quickly become a snake eating it’s tail as AI is training itself on it’s own code. If allowed, this would tend to slowly evolve future codebases to use techniques favoured by early coding LLMs. The current amount of machine influenced code on GitHub is definitely not 41% but it must be some, and is likely to increase, so this is a factor that will need some thought.
Exfiltrating code - if you use an external LLM, such as GitHub Copilot to write commercial code, who can see your code? Since it’s being transmitted to the AI in order to make autocomplete suggestions, the answer is Microsoft, or some other company. How does that intersect with your company’s policies? I assume, based on the questions I’ve asked Copilot over the last year, that I’d never be considered for a coding job at Microsoft :-)

I, for one, welcome our new robot overlords

In an industry particularly known for excessive hype-cycles, it’s important to critically examine what we’re doing, but for the moment, I’ve landed on the position that these are good tools for me to use. Here’s my thinking.

My situation is that I’m a very experienced developer, with solid expertise in several languages and programing paradigms, and with a degree that was strong in looking at the meta level of languages and software development processes, but, I’ve got no professional experience in modern languages. Because of this, a lot of my process has been knowing what I wanted to do, using google or stack overflow to figure out the mechanics of that in whatever language I’m using, then translating that into the context of the code I’m working on. Generative AI fits extremely well into that need - instead of jumping into a browser window to look something up, I’m just writing a descriptive comment of my intentions, then tabbing through the suggestions to chose an approach.

My particular style is also well suited to these tools - I like clear, simple to reason about code. If I can write a pure function for something, I do. I like to break my code up into separated concerns with clear interfaces, I don’t prematurely optimise. I use descriptive variable, function and object names. I like to work with established, well documented languages and popular libraries, and I prefer to reduce external dependencies. All of these habits make it easier for an AI assistant to access the context of what I’m doing, and therefore to make better quality suggestions.

My journey

I started out using ChatGPT 3 then 3.5 as a sort of super-google/stack-overflow eliminator.

Then with the public launch of GitHub Copilot, I trialed that in VSCode and it was a great experience. I guess they didn’t invent the idea for the greyed out auto-complete suggestion you can tab to accept, but it feels like a natural way to work with this stuff.

I paid for Copilot for a couple of months. But then heard about Codium, probably on Syntax, which is free for individual developers (for now - thank you VC funding). I haven’t done any careful comparisons, but its definitely of the same order. I suspect Copilot is doing something better with the local context. For example I use a plain text accounting system called Bean Count in VSCode. Copilot is able to understand these transactions and make much useful suggestions than Codium. I assume this is just inferred from my local files since there would not be much training data for them, and it suggests the correct accounts based on the payees which must be from local context.

I’ve probably done more work with Codium, 80% of it on Javascript, than with Copilot. It’s definitely a workable solution and a great choice if you want a Copilot type experience without paying for it, or have questions about Microsoft’s training data.

More recently I’ve started playing with local models to avoid the problem of exfiltrating my code - I strongly feel I can’t use AI assisted coding with client code if I don’t know what’s happening it. If I can run a local model, that problem is avoided.

I code on an early M1 MacBook, so Ollama is an easy to use choice. I’ve tried llama3 and codeqwen1.5 in the terminal for a bit, but missed the ChatGPT web experience. To get that back, I’ve been running Open WebUI in a docker container.

More recently, I’ve installed the Continue VSCode extension that allows those Ollama managed models to work in VSCode, including the auto-suggestions (following Dave Gray’s blog post). I’ve got a few long flights coming up over the next week, so it will be good to be able to work offline with that help.

I haven’t really done more than play with CodeQwen in VSCode via Continue so far, but my initial impression is that it’s comparable to Copilot, although the extra second of waiting for auto-suggestions did make me look up M3max MacBook pricing. Logic tells you that a 4GB model on a MacBook is going to be less capable than the giant GPT4 powered Copilot, but this comparison suggests the difference is not an order of magnitude (although the model size is). From limited playing around in small JavaScript codebases, they seem similar, with the local model just being a bit slower.

If this is a revolution, it’s one we’re at the start of, and I certainly reserve the right to change my mind about AI assistance in coding, but I suspect it’s our future and I’m excited at the productivity boost it currently gives me working in languages I’m new to.

Copying Objects in JS

Mon, 15 Jan 2024 00:00:00 +0000

I’ve paid for a month of Mosh to do his React 18 course, and one of the things he makes a big deal about is not to go too deep with nested objects for your state. As soon as you start to update them it becomes apparent why.

Because of the way state works in React, if we need to update part of an object it has to be deep copied, the changes applied to this copy, then that new copy passed back to React to replace the previous version. So, how we copy objects becomes a matter of particular interest.

Spread operator

JavaScript has some good tools to help us here, the primary one being the spread operator. Imagine we want to create a value copy of this object:

const originalObject = { name: 'John', age: 25, hometown: 'Birmingham' };

We can’t just assign this:

const newObject = originalObject;

Since now both ’newObject’ and ‘originalObject’ both point to the same in-memory object. So if we changed newObject.name = 'Ian', then originalObject.name would also become 'Ian'.

What we really want is something like this:

const newObject = {name: originalObject.name, age: originalObject.age, hometown: originalObject.hometown};

This conveys our intent really clearly, but is very quickly going to be come tedious, especially as the objects grow. Luckily, JS has a cool solution for this - the spread operator. We can replace the code above with:

const newObject = { ...originalObject }

What’s even nicer (especially in the context of making changes to React state) is that we can selectively replace parts during the copy. If we needed an object for John’s twin we could do this:

const newObject = { ...originalObject, name: 'Jill');

Nested

So the above works great for flat objects, but what about when there’s some nesting. Let’s consider this object:

{ name: 'John', age: 25, subjects: [ 'engineering', 'anatomy' ], hometown: 'Birmingham'}

Now there’s an array inside the object, if we do a shallow copy with a spread:

const newObject = { ...originalObject }

The the array will only have been copied by value, to copy the whole thing properly (which we’ll need to do before we alter it and give it back to React) we’ll need to manually spread the array as well.

const updatedObject = { ...originalObject, subjects: [...originalObject.subjects]};

If we want to enroll John in maths, we can just add that in when creating the array:

const updatedObject = { ...originalObject, subjects: [...originalObject.subjects, 'maths']};

For removing a subject we can use JS’s array.filter() method:

const updatedObject = { ...originalObject, subjects: originalObject.subjects.filter(subject => subject !== 'anatomy')};

You can see how this is quickly going to get messy if this was an array of objects inside out object, and we had to go down another level. Hence the advice to avoid that.

Concurrency and channels in Go

Tue, 12 Dec 2023 00:00:00 +0000

In the long ago times, I’d done several years of commercial programming before I ever had to worry about dealing with multiple things happening at the same time. Perhaps because of the rarity of this problem, doing it in traditional languages was not always elegant.

In the modern world of everything happening on the network, and systems being build out of micro-services and APIs, the beginning programmer probably has to deal with this stuff in Programming 102. Luckily, modern languages have these considerations built in, and one language with a particular reputation for that is Go.

In Go, we have Goroutines. This is basically a way of calling a function in such a way that the function goes away and does it’s thing and the rest of the program doesn’t wait for it. To do this, you just pop a go directive in front of the function call. Consider this little program:

package main

import (
	"fmt"
	"math/rand"
	"time"
)

func waitAndReportWorker() {
	for {
		sleepTime := time.Duration(rand.Intn(5)) * time.Second
		time.Sleep(sleepTime)
		fmt.Printf("Worker slept for %s", sleepTime)
	}
}

func main() {
	waitAndReportWorker()
}

If we run this, main hands control over to the worker, which sleeps for a bit, prints a message then repeats (normally the worker would some, like, actual work; but for our demo purposes, having a little nap then reporting it it fine).

We can convert it to a Goroutine, just by putting a go in front of the function call,

func main() {
	go waitAndReportWorker()
}

Yay! Our first baby Goroutine. Sadly, this program will exit before the worker ever reports, so let’s add an infinite loop after we’ve launched the Goroutine. And we’ll do something in the loop so you can see that there things are happening concurrently in our program.

Collisions

In my confected example, it’s extremely unlikely that the message from the worker would collide with the message being printed in the main loop, but it’s possible. But if we scaled up to a worldwide networked system processing millions of something a minute, it becomes almost guaranteed. Maybe a couple of sentences being mangled in output to the terminal is no big drama, but if we were writing something to a memory location, a file, a heart surgery robot interface, a database etc it could be bad. So we need to avoid that.

The way Go deals with this is with channels. A channel is like a portal between the main program in sequential procedural program land, to the worker function. When the worker needs to interact in some way with the main program it passes something back through the portal, and Go deals with it to avoid the dreaded collision. The portal/channel works the other way as well - the main program can pass information through the portal to the worker function.

Let’s have a look at the changes for this, then tease them out a little:

func waitAndReportWorker(resultChan chan<- string) {
	for {
		sleepTime := time.Duration(rand.Intn(5)) * time.Second
		time.Sleep(sleepTime)
		resultChan <- fmt.Sprintf("\nWorker slept for %s\n", sleepTime)
	}
}

func main() {

	resultChan := make(chan string)

	go waitAndReportWorker(resultChan)
	for {
		time.Sleep(250 * time.Millisecond)
		fmt.Print("Nothing happening here ")
		result := <-resultChan
		fmt.Println(result)
	}
}

We create the channel with the make function. The type for the channel is the type that we’re going to be passing through it. We pass the channel to our worker, where the function signature is:

func waitAndReportWorker(resultChan chan<- string)

I like this little arrow, it’s showing which way the portal works. In this case its a portal (channel) for passing a string out of the worker back to the main program. Channels can go the other way, ie. to pass things into the worker, or they can be bi-directional, which I don’t really think I’d do - I’d just add another channel.

In our worker, we stuff something into the channel with that same arrow:

resultChan <- fmt.Sprintf("\nWorker slept for %s\n", sleepTime)

On the other end of our portal/channel (I wish they’d just called them portals - it’s no quirkier than the date formatting) in the main program we use another arrow to pull the value out:

result := <-resultChan

If we run this code, it works, sort of.

If you look at the output at the bottom, you can see that extracting the string out of our channel is a blocking operation. The program is waiting there until it gets a value. That’s no use - we could have done that without mucking about with channels.

Of course, there is a way around this. What we really want to to is check if there’s a value in the channel. If there is, process it, or if not, travel around our loop again. What we do is put the retrieval of the channel value as a case in a select block.

func main() {

	resultChan := make(chan string)
	go waitAndReportWorker(resultChan)

	for {
		select {
		case result := <-resultChan:
			fmt.Println(result)
		default:
			time.Sleep(250 * time.Millisecond)
			fmt.Print("Nothing happening here ")
		}
	}
}

This version of the program will work exactly how we want. The worker goroutine will execute independently of the main loop which runs permanently, but then when the worker goroutine has something to say, it uses the channel to pass it back to the main routine which deals with it at the first opportunity.

Even though this is all working how we’d like, there is bit of programming craftsmanship needed. You may already know make() from using it for slices. When we’re using it we’re allocating some resources - so now we have the responsibility to release them.

To release the channel we made above, we close it:

close(resultChan)

Let’s add that for completeness. I’ll the time to exit my infinite loop. In practice You’ll have some other condition.

package main

import (
	"fmt"
	"math/rand"
	"time"
)

func waitAndReportWorker(resultChan chan<- string) {
	for {
		sleepTime := time.Duration(rand.Intn(5)) * time.Second
		time.Sleep(sleepTime)
		resultChan <- fmt.Sprintf("\nWorker slept for %s\n", sleepTime)
	}
}

func main() {

	resultChan := make(chan string)
	go waitAndReportWorker(resultChan)

	startTime := time.Now()

	for {
		select {
		case result := <-resultChan:
			fmt.Println(result)
		default:
			time.Sleep(250 * time.Millisecond)
			fmt.Print("Nothing happening here ")
		}
		if time.Since(startTime).Seconds() >= 10 {
			break
		}
	}

	close(resultChan)
}

This is pretty much the minimal set up you need to get going with concurrency with Go:

the channel
a goroutine
a select in a loop
some cleanup by closing the channel

code on github

Clean code

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

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

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

The Custom at the Time

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

Natural Language

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

answer = resultOf(6, plus: 7)

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

Decomposed

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

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

Less Magic

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

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

Evaporated Comments

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

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

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

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

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

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

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

ImageRenderer()

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

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

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

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

Here it is, with a couple of buttons underneath:

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

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

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

If we save the screen:

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

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

Ticket to ride

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

A couple of days ago I was lauding the learning benefits of writing your own projects over completing tutorial projects - since your own projects push your boundaries further. Of course, its also the case that the project requirements might so completely exceed your current ability that it grinds to a halt. That’s the case with my behaviour ticket app.

The part of the app for collecting the data is pretty much done and how I imagined it, but the output needs to be pretty tickets that can be printed on paper. I managed to write the ticket data to a CSV file and export that to the files app with a .fileExporter, but really what I wanted is to have one of those share screens where you can chose to AirDrop, Print etc, and for the tickets to have been rendered to a PDF or series of images to be shared. That will have to wait. I’m just up to a bit in the #100Days about writing images so I’ll push on with that for a bit and come back to my app.

In the meantime, it’s worth going over how to create and export the text file briefly.

First of all, I stole this TextFile code from Paul Hudson (here) that wraps some complexity neatly into a struct.

//
// TextFile.swift
// Stolen from Paul Hudson @twostraws
// https://www.hackingwithswift.com/quick-start/swiftui/how-to-create-a-document-based-app-using-filedocument-and-documentgroup
//

import SwiftUI
import UniformTypeIdentifiers

struct TextFile: FileDocument {
 // tell the system we support only plain text
 static var readableContentTypes = [UTType.plainText]

 // by default our document is empty
 var text = ""

 // a simple initializer that creates new, empty documents
 init(initialText: String = "") {
 text = initialText
 }

 // this initializer loads data that has been saved previously
 init(configuration: ReadConfiguration) throws {
 if let data = configuration.file.regularFileContents {
 text = String(decoding: data, as: UTF8.self)
 } else {
 throw CocoaError(.fileReadCorruptFile)
 }
 }

 // this will be called when the system wants to write our data to disk
 func fileWrapper(configuration: WriteConfiguration) throws -> FileWrapper {
 let data = Data(text.utf8)
 return FileWrapper(regularFileWithContents: data)
 }
}

Now here’s all the modifiers I’ve got attached to the list of tickets.

The toolbar button just assigns a string to the instance of Paul’s TextFile(). The string is built by just stepping through the tickets in a for loop and appending csv strings for each ticket to the big string that becomes the file.

The .fileExporter then does the heavy lifting. It slides up a view of the files in the “On My Phone” folder, lets the user name the file and saves it.

 .navigationTitle("Tickets")
 .fileExporter(isPresented: $showingExporter, document: exportFile, contentType: .plainText) { result in
 switch result {
 case .success(let url):
 print("Saved to \(url)")
 case .failure(let error):
 print(error.localizedDescription)
 }
 }
 .toolbar {
 Button {
 exportFile.text = ticketsExportText()
 showingExporter = true
 } label: {
 Image(systemName: "square.and.arrow.up")
 .padding(.horizontal)
 }
 }

FriendFace 61 Feedback

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

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

Merge Policy

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

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

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

Data

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

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

MainActor

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

61 Done

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

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

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

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

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

Source

Core Data basics - Part Two

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

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

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

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

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

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

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

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

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

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

extension Garden {

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

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

}

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

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

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

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

 deinit {
 }

}

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

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

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

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

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

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

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

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

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

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

Part 1, Part 3

Core Data basics - Part One

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

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

App Overview

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

Struct version

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

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

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

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

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

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

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

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

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

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

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

Part 2, Part 3

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 Challenges

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

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

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

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

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

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

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

 try? moc.save()
 }

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

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

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

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

Task 1

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

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

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

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

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

Task 2

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

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

The enum, with attached raw values:

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

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

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

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

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

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

 try? moc.save()
 }

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

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

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

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

Task 3

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

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

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

Then in the subview call:

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

Bookworm Challenges

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

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

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

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

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

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

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

Straightforward, with use of the ternary operator.

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

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

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

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

@Binding - data between views

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

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

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

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

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

// prints '6'

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

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

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

import SwiftUI

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

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

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

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

Codable & JSON

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

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

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

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

Making a type Codable

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

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

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

Encoding

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

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

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

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

This prints out:

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

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

Decoding

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

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

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

print(newChair.name)
// Kitchen chair

Wrap up

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

Day 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.

Updating stored JSON due to a struct change

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

I mentioned yesterday “I could use a renamed old version of my struct to load the existing data, and convert it across to the new model.”. Since I’ve been testing the app on my phone, and using plausible data, it was going to be painful enough to lose it that I thought I should go through those steps.

First, I make a copy of the old struct, and renamed it with the app version number that used it. No need to bring all the computed properties into this struct, just the bits that get encoded into the JSON.

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

Then I could go ahead and change the official struct to add the new properties it needs. Now when the JSON is attempted to be decoded into the new struct, it will fail, so we need to detect that and try with the old version of the struct.

class Habits: ObservableObject {

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

 init() {
 if let savedItems = UserDefaults.standard.data(forKey: "Habits") {
 if let decodedItems = try? JSONDecoder().decode([HabitItem].self, from: savedItems) {
 items = decodedItems
 return
 } else {
 print("JSON decoding fail - trying v0.1")
 var v01Items = [V01HabitItem]()
 if let decodedItems = try? JSONDecoder().decode([V01HabitItem].self, from: savedItems) {
 v01Items = decodedItems
 v01Items.forEach { oldHabit in
 items.append(HabitItem(
 id: oldHabit.id,
 name: oldHabit.name,
 started: oldHabit.started,
 timesDone: oldHabit.timesDone,
 lastDone: oldHabit.lastDone,
 daysBetweenCompletions: oldHabit.daysBetweenCompletions
 ))
 }
 return
 } else {
 print("JSON decoding fail")
 }
 }
 }
 items = []
 }

Once it’s decoded, we need to ForEach through and create instances of the new struct from the old ones.

It’s made my init() a bit messy, normally I’d move that out - maybe have a separate file with the old struct and a function for decoding it and copying into the new struct, but this is not a production app, it’s only on my phone and on two simulations on my macBook, so this code won’t stay in once I’ve updated each instance by running it once.

If it works correctly, I should get the debug message and the data will still be there on the first run, then on a second run the message should not appear (since the new struct version will have been written to the file.

JSON encode/decode

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

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

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

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

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

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

class Habits: ObservableObject {

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

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

 items = []
 }
}

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

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

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

Refreshing SwiftUI Views

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

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

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

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

class Cars: ObservableObject {

 @Published var items = [Car]()

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

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

 deinit {
 }

}

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

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

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

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

Trick 1 - change a value

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

@State var refresh = false

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

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

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

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

Trick 2 - .refreshable()

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

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

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

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

Trick 3 - OnChange(of: scene)

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

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

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

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

Trick 4 - a timer

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

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

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

You need to enjoy puzzles

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

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

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

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

class Cars: ObservableObject {

 @Published var items = [Car]()

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

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

 deinit {
 }

}

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

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

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

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

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

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

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

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

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

Then tried it, it worked correctly.

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

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

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

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

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.

Using Swift's map

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

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

First, here’s Paul’s code

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

or, going back even further in time:

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

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

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

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

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

iExpense Feedback

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

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

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

Same approach as me,

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

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

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

I’d done this with ternary operator modifiers:

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

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

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

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

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

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

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

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

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

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

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

Which outputs this:

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

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

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

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

CodeTrimmer - First MacOS App

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

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

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

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

Then press the “Strip Spaces” button to get:

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

Source

Design Challenge

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

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

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

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

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

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

iExpense Challenges

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

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

Locale

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

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

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

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

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

and offers to fix it for me:

Use 'currency.identifier' instead

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

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

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

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

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

Conditional formatting

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

Easy - ternary operator on HStack - see above

Conditional list building

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

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

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

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

Animating Guess The Flag

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

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

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

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

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

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

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

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

Source

Animations in Views

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

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

Implicit animation

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

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

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

Binding animation

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

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

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

Explicit animation

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

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

Project 5 - Word Scramble

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

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

Source.

Word Scramble Feedback

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

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

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

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

usedWords = [String]()

Whereas Paul had:

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

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

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

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

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

until I saw the result and loved it.

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.

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.

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

Codewars / reduce

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

codewars.com is a “coding practice” website. You chose a language and a skill level, then it offers up a task (or kata) for you to write a suitable function. The first one it gave me was seemed too hard, so I changed my level to beginner and skipped to the next one. This was my task:

 Given an array of integers, find the one that appears an odd number of times.
 
 There will always be only one integer that appears an odd number of times.
 
 Examples
 [7] should return 7, because it occurs 1 time (which is odd).
 [0] should return 0, because it occurs 1 time (which is odd).
 [1,1,2] should return 2, because it occurs 1 time (which is odd).
 [0,1,0,1,0] should return 0, because it occurs 3 times (which is odd).
 [1,2,2,3,3,3,4,3,3,3,2,2,1] should return 4, because it appears 1 time (which is odd).

I know there’s a cool “Set” container type in Swift, so my plan was to iterate through the array, then for each number if there’s no entry in the set, then add one, but if there is, remove it. That way whatever is left in the set at the end must be in the original array an odd number of times. I was pretty pleased with myself. Here’s the code I Playground’d up:

func oddTimesInt(intArray: [Int]) -> Int {

var intSet: Set<Int> = \[\]

for number in intArray {
 if intSet.contains(number) {
 intSet.remove(number)
 } else {
 intSet.insert(number)
 }
}

assert(intSet.count == 1)
if let firstNumber = intSet.first {
 return firstNumber
} else {
 // this is guaranteed not to happen in the specification
 assert(false)
 return 0
}

}

While you are writing your code in their webpage, you can run it against a test suite. Mine passed the first time; even more pleased with myself.

When you’re ready, you can submit your code. Now it runs against a much bigger test suite. It passed again; now my head is swelling a little at just how canny I am.

There’s a chance to clean up, comment, or to refactor your code before it’s finally locked in. Then once you commit that, it shows you other people’s solutions. This was the top one:

func findIt(_ seq: [Int]) -> Int { seq.reduce(0, ^) }

lol. One. Line. That’ll learn me.

So, anyways…. I guess I learned there’s an array method called reduce, and it reduces an array, but I want to argue my code is easier to understand.

According to the docs, reduce “Returns the result of combining the elements of the sequence using the given closure.” Basically, the 0 in the example above is the inital value of the accumulator, then the closure repeatedly operates on the accumulaotr and each value of the array, then the final result in the accumulator is returned. An example will make a lot more sense. Here’s the one from the Apple documentation:

let numbers = [1, 2, 3, 4] let numberSum = numbers.reduce(0, { x, y in x + y }) // numberSum == 10

The closure in the winning entry used all the closure redaction tricks I think I’ve complained about before. We could make it a bit more readable by putting syntax back.

func findIt(_ seq: [Int]) -> Int { seq.reduce(0, {accumulator, element in accumulator ^ element} ) }

or to go back another step:

func superXOR(accumulator: Int, element:Int) -> Int { return accumulator ^ element }

func findIt(_ seq: [Int]) -> Int { seq.reduce(0, superXOR ) }

The ^ operator is XOR. I know what that does, and could even manually do it on two binary numbers.

This compact solution is based on knowing that XORing all the integers will leave the odd value, since XORing two identical numbers gives zero, and that carrying forward the XORed value of two different numbers will shake out to leave the number that only appears once. I was not going to think of that solution, even if I’d known reduce() existed.

Named Loops

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

Here’s a neat thing I haven’t seen before. Other languages I’ve worked in haven’t had a neat way to break out of a set of nested loops to a particular loop. It’s not an issue that comes up a lot, but when it has I’ve solved it by creating a continue flag and having that as the first condition of each loop.

To explain, say if we had these two loops (in C):

int i; int j; char string[] = “This string”; int length = strlen(string);

for (i=0; i<=3; i++) {

for (j=0; j<length; j++) {
 printf("char:%c num:%d\\n", string\[j\], i);
}

}

and for some unexplained reason, we need to break out of both loops when we encounter a lowercase ‘t’. There is a C command to break out of a loop - break. But it only breaks out of the current loop:

int i; int j; char string[] = “This string”; int length = strlen(string);

for (i=0; i<=3; i++) {

for (j=0; j<length; j++) {
 printf("char:%c num:%d\\n", string\[j\], i);
 if (string\[j\] == 't') {
 break;
 } 
}

}

Since the outside loop that is iterating ‘i’ is not broken out of, we still end up looping through to the letter ‘t’ four times. Like this:

char:T num:0
char:h num:0
char:i num:0
char:s num:0
char: num:0
char:s num:0
char:t num:0
char:T num:1
char:h num:1
char:i num:1
char:s num:1
char: num:1
char:s num:1
char:t num:1
char:T num:2
char:h num:2
char:i num:2
char:s num:2
char: num:2
char:s num:2
char:t num:2
char:T num:3
char:h num:3
char:i num:3
char:s num:3
char: num:3
char:s num:3
char:t num:3

So in C/C++ I would convert the loops to while, and set a continue flag. First the whiles:

int i; int j; char string[] = “This string”; int length = strlen(string);

i = 0; while (i <=3) {

j=0;
while (j<length) {
 printf("char:%c num:%d\\n", string\[j\], i);
 if (string\[j\] == 't') {
 break;
 } 
 j++;
}

i++;

}

Then the flag, which I’ve called keepGoing:

int i; int j; char string[] = “This string”; int length = strlen(string) ;

int keepGoing = true; i=0; while (keepGoing==true && i <=3) {

j=0;
while (keepGoing==true && j<length) {
 printf("char: %c num: %d\\n", string\[j\], i);
 if (string\[j\]=='t') {
 keepGoing = false;
 }
 j++
}

}

This gives us the output we want and we can close the ticket. Note that I have
typedef’d true and false off-screen in the code above.

char:T num: 0
char:h num: 0
char:i num: 0
char:s num: 0
char: num: 0
char:s num: 0
char:t num: 0

With Swift, we can just name the loops, then break out to a named loop level:

littleLoop: for i in 0…3 { bigLoop: for char in “This string” { print(“char:\(char) num:\(i)”) if char==“t”{ break littleLoop } } }

Note that I didn’t need to name the internal littleLoop, that was just showing off.

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

Protocols

Tue, 16 Aug 2022 00:00:00 +0000

The evolution of structs into class-like things that can hold properties and methods in Swift raised in my mind “what about inheritance?” - but no: structs in Swift can not use inheritance.

Swift classes implement inheritance, but only from one class; there’s no multiple inheritance. Protocols neatly address both these concerns to a large extent, but perhaps before we look at how they work, we should have a brief diversion into inheritance in C++.

#include

class Shape { public: int sides; };

class Drawable { public: virtual void draw() {} };

class Square : public Shape, public Drawable { public: Square(){ sides = 4; }

 void draw() {
 std::cout << "■" << std::endl;
 }

};

int main() { Square square; square.draw(); return 0; }

In the code above, there’s two classes Shape and Drawable. You could regard Drawable as an interface if you’re coming from Java world (because the method draw() is marked virtual - there’s no implementation). The class Square inherits from both those classes - it’s a new class that is a Shape, but is also Drawable. (Line 15 above)

Perhaps in this program there’s other items such as images or text - ie not shapes which might also inherit from Drawable. Elsewhere, we could have a method that had to draw a collection of things - it doesn’t care what the items are, as long as they are Drawable - they have to implement the Draw() method.

Swift addresses most of these needs with Protocols. A protocol defines a set of properties and methods. Then a struct, class, or even enum can conform with this protocol - they contain the same properties, and are required by the compiler to implement the methods from the protocol.

Here’s the Swift equivalent of the C++ above:

protocol Shape { var sides: Int { get set } }

protocol Drawable { func draw() }

struct Square: Shape, Drawable { var sides: Int = 4 func draw() { print("■") } }

let square = Square() square.draw()

So, that’s cool, but not amazing. The power is really that now we can write a function that takes anything that’s Drawable as if it was a real type. To wit:

class IanClass: Drawable { func draw() { print(“Ian”) } }

func drawAThing(_ thingToDraw: Drawable){ thingToDraw.draw() }

let squareStruct = Square() let ianClass = IanClass()

drawAThing(squareStruct) drawAThing(ianClass)

So the function drawAThing() is happy to draw anything, as long as it conforms with the Drawable protocol by implementing the draw() method. It doesn’t even matter what it is - as in this example where we’ve passed it a struct on one occasion, and a class on another.

Protocols are a great example of Swift being flexible while being type-safe.

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)

Simple MVVM

Thu, 11 Aug 2022 00:00:00 +0000

MVVM (Model-View-View Model) is an architectural pattern for apps that separates the data (Model) from the user interface (View). The communication between these two parts is facilitated by a View Model.

Model <-> View Model <-> View

Model

The Model is platform independent - we should be able to pluck it out and add it to a different application running on a different platform without any trouble. Any business rules will be part of the Model along with the data. For example, if it’s a rule that every customer has a sales contact, this can be enforced in the Model.

The Model (or Models - an app could have more than one) does not know anything about the View or the View Model. In a SwiftUI app, we’ll almost always have the model in its own file.

Our simple example app for this post is going to be a light bulb app. There will be a picture of a light bulb, and a button which will toggle the light off an on. It’s difficult to think of a simpler Model. This is what I’ve come up with.

struct Light{ var on: Bool = false }

A Model in a real application could be massive - with connections to online data stores and complex business rules. Our light just has two exclusive states - off and on. We could make it more complex - it could be an incandescent light with a particular resistance and a formula for the brightness output for any particular voltage that was applied. All of that would go into the Model. But for today, we’ll just have on or not.

In all of the SwiftUI examples I’ve seen so far, the Model has been a struct. Perhaps it can be other things, but Swift has deep magic (structs are mysteriously immutable, so they are actually rebuilt when any properties change) for efficiently knowing if structs have changed, so perhaps not.

View Model

The View Model will have the Model as a property. That way it can do things to the Model, and to access the bits it needs to pass off to the View. The View Model is always a class, as it needs to comply with the protocol of ObservableObject. If protocol and ObservableObject are foreign to you, don’t panic. You don’t need to understand any more than that the View needs to know when the View Model changes, so it observes the View Model, and for that magic to happen, the View Model needs to be a class having that ability (of being observed) which it gets from having the protocol ObservableObject.

The View Model will also have properties or methods that the View can use to access the Model data. Remember the Model is completely hidden from the View, so the View Model provides that access. In a real situation, it would also do whatever translation or packaging was required to make the View’s life easy. In our example it is rather simple.

class LightViewModel: ObservableObject { @Published private var lightBulb = Light(on: false)

func toggle() {
 lightBulb.on = !lightBulb.on
}

var isOn: Bool { return lightBulb.on }

}

Again, the View Model is in it’s own file. The only thing we haven’t mentioned is the @Published used in the property for our Model. This is just part of the magic mentioned earlier in the discussion about ObservableObject which allows the View to know that something has changed, and that it needs to react to this by rebuilding the View.

View

The View is just our regular SwiftUI view. A crucial part is that it holds the View Model for the light as a property wrapped with the @ObservedObject. This completes out connections between the three parts of our architecture.

The Model View is an @ObservableObject which has the Model as a @Published property
The View contains the View Model as an @StateObject property

These connections have these effects

The View cannot ever access the Model directly
If the Model changes, the View Model is aware, and broadcasts this in a way that the View knows about
The View just redraws itself if that happens
As the View does this, it asks the View Model for the parts of the data it needs
This both protects and hides the Model from the view, and is an opportunity for the View Model to do any work it needs to to the data to make it easy for the View to put on the screen.
Any user interaction that occurs in the View is passed to the View Model to deal with.

struct ContentView: View { @StateObject var light = LightViewModel()

var body: some View {
 VStack{
 Spacer()
 if light.isOn {
 drawLitBulb
 }
 else {
 Image(systemName: "lightbulb.fill").font(.system(size: 72))
 }
 Spacer()
 Button("Toggle Light", action: {
 light.toggle()}
 )
 .padding()
 .font(.title)
 .foregroundColor(.white)
 .background(Color.accentColor)
 .cornerRadius(10)
 .padding()
 }
}

var drawLitBulb: some View {
 // view of an iluminated bulb
 ZStack{
 Circle().fill(.yellow).frame(width: 150, height: 150)
 Image(systemName: "lightbulb").font(.system(size: 72))
 }
}

}

To make the code read nicely, the View Model is called “light”, and it’s an @StateObject so for the redrawing trigger to work correctly. The rest of the code should be reasonably clear if you’ve made a few SwiftUI views.

We check if the light is on (by asking the View Model), if it is, we draw a lit bulb, if not, an unlit bulb is drawn. The last UI element is our Button() whose action is the toggle() method of light - our View Model.

The source for this project is on GitHub here.

Memorise Assignment 1

Thu, 28 Jul 2022 00:00:00 +0000

A small milestone achieved - I’ve completed the first assignment from the CS193p lecture series - some minor changes to the app being built in the lectures. There was a couple of things I was unhappy with:

The text under the SF Symbols you can see in the preview above not being vertically aligned.
Having duplicated code in my emoji arrays:

 let animalEmojis = ["🐠", "🐢", "🦋", "🐥", "🐣", "🐰", "🐝", "🦄", "🐵", "🐛"]
 let weatherEmojis = ["🌪", "🌝", "🌈", "🔥", "🌧", "🌙", "🌬", "☃️", "☔️", "🌫"]
 let transportEmojis = ["🚗", "🚕", "🚲", "🚚", "🛵", "🚜", "🛴", "🛺", "🚃", "🚡"]

 // I'm not happy with this duplication //TODO
 @State var emojis = ["🐠", "🐢", "🦋", "🐥", "🐣", "🐰", "🐝", "🦄", "🐵", "🐛"]

This second problem is because I couldn’t just

@State var emojis = animalEmojis

When I tried it, I encountered the error:

Cannot use instance member 'animalEmojis' within property initializer; property initializers run before 'self' is available

This is vexing - the constants are defined on the lines above, so surely if this property exists, the ones before it do. Apparently that can’t be depended on - probably for some good reason that will be unveiled at some stage. It’s not because emojis is wrapped in the @State which probably does cause the variable to be created off somewhere else - I tried with just an ordinary var and had the same issue.

Then I read further down into the assignment, there’s a “hints section” which I should clearly be reading before I being. C’s get degrees.

Message received. Don’t worry about the doubled up string array, and go back and watch the lecture again. There was something about locking an aspect ratio for an SF Symbol at some stage.

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

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

Learning Retention

Thu, 14 Jul 2022 00:00:00 +0000

In order to have something to put up on GitHub (as part of working all that out) I went back to re-write the Checkpoint 2 code that I’d written, but not saved, three or four days ago.

The task was to count the unique elements in an array. The teaching had been about the complex data types, so clearly the hint was to cast the array to a set. Although the idea of sets is new to me this year, I’ve come across them twice. Once in the 100 days course (the same day as having to write this code) and once from a few days earlier from a podcast episode. This is high quality learning - getting the same topic a couple of different ways a few days apart, then having to use the information for real.

/*
 This time the challenge is to create an array of strings, then write some code that prints the number of items in the array and also the number of unique items in the array.
 */

let strArray = ["one", "two", "one", "three"]
let strSet = Set(strArray)
print("Array size:\(strArray.count) unique count:\(strSet.count)")

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

Checkpoint 4 optimisation

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

The Checkpoint 4 task was to find an integer square root of numbers up to 10000. My first pass solution was:

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
}

Although not coded for speed, there are a couple of subtle optimisations here; the first is that it gives up once it gets to the number instead of going up to the end (it assumes the square root of a number can’t be greater than the number), and the second is that it counts up from the bottom rather than down from the top - I’m assuming the bottom of the range is richer in square roots than the top.

This code works fine (there was no discernible time difference between 4 and 9999) and meets the specification, so I wouldn’t want to bill the client for any further work, or to make the code uglier. Obviously however, it does spark the question of what I’d do if the function had to work over a much larger range. When I altered it to allow maxInt and passed 1,000,000,000 to it, it took just under four minutes to find in Playgrounds on an M1 MacBook.

It’s possible a good mathematics student would know some good tricks for calculating square roots, the first couple of links I googled suggested a method of looking for multiples that themselves were squares. While that’s a viable strategy mentally, and for reasonable size numbers, it didn’t lend itself to being coded. So I guess the computer science guys would pull out the binary search.

func calculateIntSqrt(_ number:Int) throws -> Int {
 var lowerBound = 1
 var upperBound = 2_147_483_646
 if number < lowerBound {throw IntSqrtError.low}
 if number > upperBound {throw IntSqrtError.high}
 
 var guess: Int
 var guessSquared: Int
 // ensure the answer is not in one of the bounds
 lowerBound = lowerBound-1
 upperBound = number+1
 while upperBound > lowerBound+1 {
 // pick a guess number halfway between the bounds
 guess = integerMean(lowerBound, upperBound)
 guessSquared = guess*guess
 // then use it to reduce the range between the bounds
 if guessSquared < number {
 lowerBound = guess
 } else if guessSquared > number {
 upperBound = guess
 } else { 
 // our guess was the integer square root
 return guess
 }
 }
 // none found or we would have returned by now
 throw IntSqrtError.noIntRoot
}

This version has no discernible speed difference between 4 and 2,147,483,644. It’s a great example of the trade-offs to be considered when making programming choices. It’s double the lines of code, and wanted more comments to explain the intent.

Full code available on GitHub.

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