Getting back into the swing of things and I’m continuing with the tutorial. Today is about State Management.

In this tutorial, you’ll add two new features to Scrumdinger. First, you’ll add a view to create new daily scrum meetings. Then you’ll update the meeting timer to keep track of past meetings.

Section 1: Use EditView

Today, I felt a little more confident in myself and my tools. I went with the option of defining the content of views and closures in the way that Xcode wanted.

For example, Xcode places the following as a method signature.

The tutorial defines the sheet as the following.

Semantically, they are both the same but I feel that the one in Xcode definition is less ambiguous. I’m still learning and want to be able to read this code later.

I pat myself on the back for being able to understand both options.

That being said, I don’t know if I like the idea of creating multiple views in a single line to make a composition.

I can see why you would do it since you aren’t using the buttons anywhere else in the application but I hope that I’ll continue to be able to learn and think in the swift way¹.

I don’t like long lines for code.

Much better.

Section 2: Add Scrum History

Purpose: Re-enforce the ideas of state.

I’m immediately impressed with the object diagram.

The second section really made things click for me and having the alt-click shortcut allows me to look up the documentation quickly.

In review

I liked today’s progress. I really feel that a lot of stuff clicked for me. This isn’t my first tutorial, and I’ve attempted to learn multiple times in the last couple of years. Today was jun and I’m looking forward to tomorrow.

I’m continuing with the Managing State and Life Cycle section of the Apple SwiftUI Tutorial.

Section 4: Add a State Object

Purpose: Learn about State Object

This sections was pretty small and introduced the concept of “Source of Truth”.

At this point, I got a little side track with trying to get an understanding of how it all comes together and getting the above picture.

Section 6: Extract the Meeting Footer

I’m not a fan on the syntax for closures and views. Defining a closure in the view means that I have to specify it when I call the view doesn’t make since to me.

I guess it’s part of the language. You can’t have a view that has values that aren’t defined.

Section 7: Trigger Sound with AVFoundation

Purpose: Lear about audio feed back

Right away, I liked this part of the tutorial because it starts showing me how to use different resources.

Today marks the 7th day that I’ve committed to blogging about my development. This continues the walk through with Apple’s updated¹ SwiftUI tutorial.

In today’s tutorial, I’ll be working on the following.

In this tutorial, you’ll learn how to use reference type models with SwiftUI views. You’ll display meeting time and progress in views that better represent the final design. And you’ll integrate with AVFoundation to play audio when the scrum’s state changes.

It’s supposed to be 30 minutes.

Section 1: Create an Overlay View

In this tutorial, I’ve seen more warnings during the individual steps than I have with the previous days.

For me, this causes a little bit of anxiety as I think more about “how do I make this go away?” Versus “how am what I’m doing going to make this work?”

Section 2: Extract the Meeting Header

Purpose: Learning about making composited views

The steps have been pretty easy to follow.

I HATE ternary statements!

minutesRemaining == 1 ? "minute" : "minutes"

All in all, pretty fun to follow along with.

Section 3: Add Design Elements to the Meeting Header

Purpose: Make the component view use dynamic properties

As I’m adding things to make the message signature, I notice that some lines need to be wrapped. Xcode does a good job of making it legible, but I’ve spent a lot of time having code be wrapped at 80 characters for one reason or another.

End for the day

I decided that I was going to end programming for the day.

As this is Day 6 of my self directed move to learning swift, I’m thinking about how this series of tutorials is only supposed to take 3-4 hours. I think that might be if you just copy past the code or maybe to get people started without worrying that this is going to take all day.

The tutorial for today is about Passing Data.

In the previous tutorial, you used bindings to share state between the edit view and individual UI controls within the view. In this tutorial, you’ll build out the editing functions of Scrumdinger using bindings to share state between different screens in the app.

Pass the Edit View

The biggest thing I noticed about this section in the tutorial is the transition from static values to bindings. There are multiple steps where you reference different parts of a large file. For example step one would be line 7 of a file, then step 2 is line 45, followed by step 3 going to the top of that same page. It would look cool on a large monitor but it’s can be easy to loose your spot.

The second memorable thing I noticed was the note about errors showing up during the process of making these changes.

I had complained about that yesterday and understand that this is an opportunity to see what happens when things go wrong and how to fix them.

Pass the Detail View a Binding to a Scrum

This section was pretty fun to do and acted as a reminder that I need to brush up on my closure syntax.

One thing that got me was mistyping srum instead of scrums in different lines.

Pass the List View a Binding

I actually got to this part by attempting to compile the application and then clicking on the error in the Issue Navigator.