Swiftui on blog.iankulin.com

Sharing is caring

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

SwiftUI provides

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

A few hours after I speculated about pausing work on the tickets app because outputting the tickets was too far out of my expertise, a helpful instance of the Baader–Meinhof phenomenon threw up some help in the form of this tweet from @FloWritesCode. It turns out this was an addition in iOS16 announced at WWDC that makes this straightforward.

As soon as I googled around about it I also found good solutions that wrapped the old code to provide similar functionality. So that’s a lesson for me about not assuming something’s hard before I’ve spent some time investigating it. I took that lesson and applied it to rendering to a PDF, and of course, @twostraws has a code example for that from three days ago!

Obviously I’m going to have some fiddling around to lay it out and so on, and I still need to figure out the share behaviour (which I’m expecting to be straightforward) but it feels like SwiftUI is just going to help me express my intents in code. I’m really enjoying this language, framework and community!

Something weird 'append

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

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

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

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

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

But, no. This is what happens:

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

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

Prints:

Array: Mutated
Local: White Lodge

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

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

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

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

I’m almost tempted to ask for help.

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

import Foundation

struct Animal {
 var name: String = ""
}

var animals: [Animal] = []

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

print(animals)

Produces the output:

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

Grrr. It turns out Swift works perfectly.

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

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

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

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

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

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

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

If I fix the ids:

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

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.

Cupcake Corner challenges

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

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

1) Whitespace validation

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

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

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

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

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

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

 return true
}

source

2) Show an alert if the POST fails

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

3) Change order to struct

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

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

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

 deinit {
 }
}

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

source

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.

List Apps

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

When I was first programming professionally, it wasn’t long before I noticed that there were patterns to the sort of bread-and-butter things I was writing most times - the majority of the small business applications I wrote tracked several entities; for each entity there needed to be add/edit/delete screens, there would be some business rules around those things, and some reports and search functionality.

The Day 47 Milestone app is for tracking habits - presented in a list; you need to be able to add and delete them, view details and do some business logic on them. Not only does this sound a lot like the earlier expense tracking app, but also not that different to the app idea I’ve got for tracking when I charge each of the rechargeable batteries in my house.

Eventually these list type apps written in SwiftUI will need a better (perhaps MVVM) architecture, but at the simple end, it seems these apps are going to be some variation on this recipe:

The item is going to be a struct with an id
It will conform to Identifiable and Codable
The collection of items will be a class that inherits from ObservableObject
The collection property will be @Published
The collection property will have an init() that reads the items from somewhere and a didset() that writes them
The instance of that collection class will be an @StateObject
The items will be shown as a List inside a NavigationView
It will probably have a toolbar with a control to add items

Patterns in development like this are convenient - they lead to high quality programs developed quickly, and being compliant with the Apple HIG means all the behaviours will be familiar to users as well as being accessible.

The danger is that they look and feel like every other list type app, so developers need to think carefully about what all the common use cases are, as well as appealing design, to ensure the users’ needs are being addressed and the application can justify it’s existence alongside all the other offerings.

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.

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.

Times Tables -Day 35 Challenge

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

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

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

Source

User Defaults & Horizontal Pickers

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

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

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

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

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

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

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

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

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

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

Getting it back is no harder:

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

Super simple!

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

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

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

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

Animation Feedback

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

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

Another round to Paul!

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.

Before SwiftUI

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

I’m on Day 26 of 100 Days, and didn’t grok the dates on my first read through, so I’ve read a couple of other explanations and sat down with a coffee and thought I’d see what YouTube had for me on the subject. I seen a few great iOS Academy videos, so this one seemed like a good choice.

I haven’t seen enough to say if it is a good or great explanation of dates, calendars and date components in Swift yet, but man, getting to the stage of writing useful code when using storyboards and UIKit takes a while! It’s literally 3:42 in to the video before there’s enough infrastructure done for “hello world”.

Takeaways: (1) Watching the launch of SwiftUI must have been mind-blowing. (2) I super appreciate the existence of Playgrounds for learning Swift.

Rock, Paper Scissors (2)

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

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

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

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

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

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

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

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

Here’s the progress

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

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

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

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

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

enum GameResult {
 case win
 case loss
 case draw
}

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

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

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

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

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

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

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

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

Current source

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

@ObservedObject v @StateObject

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

The Youtube algorithm thinks I need to watch more MVVM videos, and it turns out it’s probably right. A day or two ago in an MVVM post using a super simple example, I stored the view model as a property of the view using the @ObservedObject wrapper, as I created it.

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

var body: some View {
 VStack{
 Spacer()
 if light.isOn(){
 drawLitBulb
 }
 else{
 Image(systemName: "lightbulb.fill").font(.system(size: 72))
 }

But then today, Youtube served me up this video from BeyondOnesAndZeros

They start off with @ObservableObject, but then say that if the View Model is instantiated there, that this is repeated every time the View is recreated (which happens every time it’s redrawn).

I don’t really understand the property wrappers (like @ObservableObject) but I assume this was a type property - ie static. Apparently not. The Apple documentation on managing data says:

SwiftUI might create or recreate a view at any time, so it’s important that initializing a view with a given set of inputs always results in the same view. As a result, it’s unsafe to create an observed object inside a view. Instead, SwiftUI provides the StateObject attribute for this purpose.

So that code should use @StateObject, and @ObservedObject should be used where I pass it down into other view structs in the hierarchy.

Paul Hudson gives a good example in his explanation on this topic here.

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.

@ScaledMetric

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

I solved the problem (well, I googled a stackoverflow result to the problem) in the previous post about the different heights of the SF Symbols. The answer was to put them in a frame and lock the height. A problem that then arises from that is that when the user changes the text size, they’ll be out of wack. Apple’s solution to that, introduced in iOS 14 is the @ScaledMetric property wrapper that does some magic I don’t fully understand yet.

SwiftUI Essentials

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

I hadn’t fully gotten my head around what’s going on with the declarative nature of SwiftUI, until I’d watched this video

It’s from the 2019 WWDC which is when (I guess) SwiftUI was new. I still don’t have a good handle on how the views are bound to their data, but there is a video from this same series about Data Flows which I imagine will also answer those questions.

Of course, I could also have been pushing forwards on the two courses I’m undertaking - no doubt they are about to teach me these same things, but at least I’m procrastinating constructively.

iOS Dev Weekly

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

Dave Verwer’s iOS Dev Weekly digest of links mainly about Swift libraries was mentioned on a podcast I was listening to last night - perhaps the Swift with Sundell chat with Sommer Panage.

My first issue (it’s an email newsletter) arrived, and it’s pretty great. Not too long, chatty but on topic, and with links to follow for more info. As well as new or improved libraries, other topics are mentioned - I went down a rabbit hole on SwiftUI Split View Configuration, ending up at this WWDC video about it.

Passing Data

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

Sean Allen has come to my notice a couple of times, once where he was mentioned as freelance contractor who is a great contributor to the community (I think perhaps that was on Swiftcoders Podcast), and I’ve also bumped into him as co-host (with Paul Hudson) of the early episodes of the “Swift over Coffee” podcast.

This video I watched last night is a compilation of the first few videos of Sean’s SwiftUI course, and it’s pretty great. In particular he does a great job of explaining how to start to refactor child views out and call them, and how all the stacks go together to make a pretty interface. What he does not do is vist/explain any of the Swift language fundamentals. If you don’t already know what a struc is, and the Swift flavour of them, it may be a challenging place to start.

In the last couple of tutorials he starts on the way the views are called, and how we can pass values into them. This is great marketing for me - it’s exactly where I’m up to in my journey - I’m perplexed about the structure of a SwiftUI app (where’s main?!) and the engine that’s watching when the UI needs updated and building the views. For example, I want to write a little hello world that just prints the time on the screen. I got this far:

struct ContentView: View {
 let today = Date.now
 var body: some View {
 Text(today, style:.time)
 }
}

But then a minute later when it needs changed what happens? In traditional programming there would be a loop in main where I could check the minutes have changed, and force the redraw of the label.

I feel this is the thing that’s going to be explained clearly in the next few videos of Sean’s course, which is cunningly behind the paywall. I’m very tempted, although my learning is already spread over two proper courses plus a shotgun blast of other reading, podcasts and self created programming tasks.

I did have one moment of confusion when Sean passes down an @State variable to a child view and said the variable in the child view needed to be made @Binding. One of the top comments points this out as being unneeded and Sean agrees.