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:

1. The rock paper scissors could be some better data structure than an array and some ints.
2. I don’t love the try to win, try to lose aspect, but the client specified it
3. Having the didUserWin and didComputerWin functions is a cop out – that should probably be a single function returning a win/lose/draw type
4. I also am unhappy with nesting them in the view namespace to use my #consts
5. duplicating the last part of the view but making the elements .hidden() to keep the same spacing seems like a kludge
6. 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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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