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.

On day 5 of the tutorial and I think I’m growing more comfortable with the keyboard shortcuts.

I’m hoping that future versions of Xcode will have more information in the quicklook for different classes. At the minimum, they could offer a link to get more information or have example of the different styles on one page.

Accessibility

I still enjoy the promotion of accessibility at the very beginning of someone’s journey to be a better programmer. There is also a little

Error handling

When you’re learning, it can be stressful to see errors and warnings. At this point, I don’t know if it’s just a typo or because I haven’t finished all the lines that I’m supposed to be typing.

Ultimately, I had to do a diff using BBEdit to figure out where the difference was between what I wrote and what was expected. Maybe I shouldn’t code at the end of the day?

Today’s tutorial was pretty good. I did run into a small problem with specifying the destination view.

I think it’s pretty cool that I’m recognizing some of the closures in swift.

Day 3 is the third day of the tutorial.

I spent most of this time just reading over the document and I stopped myself because I want to make this a daily habit and not something that I put down and never come back to.

I’m working on the second part of the tutorial.

The autocorrect is much nicer when it is filling out items from data structures that I’ve created, but I’m still having trouble with some of the longer method signatures. I took a moment to look up a tutorial online and I think tomorrow will be much better.

Started iOS App Dev with SwiftUI Tutorials.

Why?

I know it’s my X numbered attempt to learn swift, and I gave myself so many deadlines/goals. I thought that this time would just be me attempting to learn enough to finish an app that has been haunting me for years.

I hope that by writing about my experience in the open that it will help me move forward.

The experience

I decided to set a small goal of finishing up the first steps of the tutorial

The preview in Xcode is really slow when you first start it. Some of the keyboard short cuts feel really awkward and Command clicking keywords sometime doesn’t work. This could just be me hitting ctrl on accident. The first part is supposed to take 15 minutes but I’m 25 minutes already.

I love the fact that the first thing you do after setting up the initial view is to provide accessibility.

I wish that it would point me to more information on how the different pieces work together.

I kind of cheated and used the Option-click on the different keywords and it looks like they still have a little more work in the documentation department.

Here is .accessibilityElement

Here is .accessibilityLabel

I think I’m going to have to look into making the autocomplete work more in line of other editors, because there are a lot of options and it would be colt have a way to go through them all quickly.

Afterwards, there are three questions to review.

I made this post with MarsEdit.

Well, this is a little unsettling.

There are now businesses that sell fake people. On the website Generated.Photos, you can buy a “unique, worry-free” fake person for $2.99, or 1,000 people for $1,000.

Link: www.nytimes.com/interacti…