This lesson takes the same demo used in the previous lesson to illustrate input controls & @Binding

I opened up the app to toy with those stars, start giving the recipes new approval metrics…
Some breakpoints I had forgotten about were active on the Recipe struct. Each time I updated the recipe, the actual Recipe struct would update also from inside the emptyRecipe extension?? 🤔
Why is this extension function for new recipes firing given we are updating an existing recipe?

The other weird thing, while I had breakpoints activated inside DetailView, to try and learn why the emptyRecipe extension was fired and run through memory.
If you have breakpoints placed inside Recipe extension static func emptyRecipe, when running the app you will discover this function is fired first, before any method that called this function. I don’t like that. I don’t want to get sucked into a rabbit hole so let me try to display quickly.

They have Experiments where they suggest we change the SFSymbol Image, or change the foregroundColor. Do it! Make it whatever you want- triangle & green if you are still stumped after taking Apple’s suggestion.

Looking at Section 2, they mention the tap gesture that drives action for the star/circle/triangle to get a fill or not. I could envision how the system may want to update & save when a user interacts with this view. It is not a best practice, meaning the system is making a few unnecessary operations which may now or in the future impact performance in the app an on the device. Does that make sense?

We have Section 3, which attempts to tie things together. I tapped around the View, it would fire my breakpoints on emptyRecipe, I’d say what the hell? It works, but this other function is distracting. Turn off breakpoints there for now– so my breakpoints are off on Recipe.swift- but they still kind of went crazy in DetailView.swift. They seemed to repeat 8 times when I clicked in and then StarRating had breakpoints that fired 8 or 11 times, back to DetailView another 12 ish times and finally the render came through.

Updating the recipe at that point seemed to refresh all the ratings for reach recipe. The weird point is, the recipeID stayed the same:

So what is happening under the hood? I have no idea now- this tutorial challenged my comfort with SwiftUI. It feels as though they tried to make an amazing cake, put too much stuff in and now it’s not so great. I want to hurry up, wrap the final lesson and have my retro where I can explain between tutorial 1 and tutorial 2, I think you, whoever is in Internetland reading, knows where my feelings about this are. Maybe if I ignored the breakpoints things would have been fine, but I feel as though once you see some activity is wrong and should not occur, it would also be wrong to not call it out. Maybe I am misinformed about SwiftUI in this demo- but I hope someone can send me a message and tell me what I am doing wrong.

Picking up where we left off, I will wrap my ideas on @State & @Binding presented here.

Looking at ContentListView, I am kinda sorta grasping this a little better- follow me as I try to lead us to the 💡

In ContentListView, our @State property is recipeEditorConfig. We have the required default setting of us creating the object. Let’s take a look at this file, RecipeEditorConfig.

It is a ViewModel- or this struct is meant to help us organize our actions meant to happen in the view.
I guess reading this the first time, it all went over my head 🫨. Now, after the Nth try, the idea of @State is getting clearer. In Section 1 they start discussing RecipeEditorConfig but I like to look at where it is being accessed from first- it helps me understand the context a bit better. So on that other level, ContentListView, recipeEditorConfig is used for the Button behavior, also to present the sheet, and it is passed to the RecipeEditor. Below this, we have a private function that also uses recipeEditorConfig to determine ‘save this?’ with a conditional that helps us determine if the recipe is new, or just an update. Okay so what? @State manages “down flow” where the information is there, and the data flows down to the subviews. Click into RecipeEditor, and we can right away notice recipeEditorConfig has a different attribute- now this is a @Binding. What makes this important? The property config is the instance of RecipeEditorConfig, and its strength changes because now config cancels the action or confirms it as done. The result of this action changes everything, makes the whole view go away. Also @State has to have a default value and should be private. @Binding, from the example of this tutorial, should not be private. The information we receive needs to be injected from somewhere, and the information we deal with here, could blow everything up- feels like we are dealing with firecrackers more here

I guess I caught up to where they describe it in Section 2 🏃‍♂️‍➡️
Section 3 is where they caught up to me 😂 They discuss ContentListView, I couldn’t make sense of it- it made me want to look at the code for inspiration.
Maybe after reading it, it started to make sense in reverse, but I’m glad I took time to try and break it down. Hopefully some of y’all do as well.

Recipe editor is the app shared to demonstrate how to use @State and @Binding

This project they share is fluffy for a Recipe Editor. It has recipes which are stored in JSON, an option to ‘favorite’ a recipe and a way to add new recipes. Regrettably, new recipes are not saved nor are favorites persisted. If I favorite a different recipe or add a new one, once I turn the app off it will all be gone, with the app in this form.

There are a few property wrappers we should understand from this lesson:
State & Binding I mentioned above, we also have @StateObject, @EnvironmentObject, @ObservedObject. There is a class they created that manages Images. It was awkward where they mention the solution is a hack which should not be used in real life. The other class is the RecipeBox, which is an ObservedObject.

I need to take a moment and just say it- this lesson had me confused most of the time, like what is the best use of @State? I prefer how they presented it here. The intro was more gentle, clear and with a purpose. Anyhow, I wanted to take a step back and explain the relationship of @State and @Binding:
You have a view, which has properties. These properties impact the way our view looks with regard to a switch, some color or text, whatever. Let’s say that one of our subviews would display different content based on one of our properties’ result. The first line in the docs states : Use state as the single source of truth for a given value type that you store in a view hierarchy. So here we have this important piece of information, the PlayButton.isPlaying (as in the docs), we will showFavoritesOnly (as in the first tutorial), and in this tutorial we will configure the Recipe Editor, show delete confirmation on the View level, and on the App level we select a Sidebar Item & select a Recipe ID. I guess I didn’t have that 💡 moment over the past week reading the code, running breakpoints, and I’m sort of fuzzy on if @Binding is too heavy of a ‘hammer’ for the same task.

Docs on @State have a comment regarding @Binding: If you pass a state property to a subview, SwiftUI updates the subview any time the value changes in the container view, but the subview can’t modify the value. To enable the subview to modify the state’s stored value, pass a Binding instead. Okay, that seems clear. reading further, Like you do for a StateObject, declare State as private to prevent setting it in a memberwise initializer, which can conflict with the storage management that SwiftUI provides. Unlike a state object, always initialize state by providing a default value in the state’s declaration, as in the above examples. Use state only for storage that’s local to a view and its subviews. A whazza? @StateObject we have in our sample app, fuzzy on how it relates but here we are!

Pivoting back to the app, looking at RecipeBox it behaves as our data fetcher. Inside RecipeBox, we can see it manages the recipes and there is a method to pull data from JSON. It makes me curious: if we want to write to JSON in our RecipeBox, would this remain a @StateObject 🤔

Choosing the right way to hide a view was short & sweet. Essentially, there are two objectives when hiding a view. Hide and save the space, or hide and pretend like it was never there. We can use .opacity(_:) and VoiceOver will respect that we don’t want a zero-opacity view to be ‘voiced’, yet the space will remain. If we want to close the space, we can use a Conditional (if) statement.

Apple uses a train example, I’m using shapes.
We use a boolean @State var to control both Conditional & Opacity lines.

// Conditional
if moreShapes {
    Image(systemName: "triangle"
}

// Opacity
Image(systemName: "triangle")
    .opacity(moreShapes ? 0 : 1)

to recap, if we want to hide a view, and pretend like it was never there, use a Conditional approach

if we want to save the space, use Opacity

Layering Content

While there is much to be gained from this lesson, I feel like it would have been nicer if, again, they had followed the paradigm from Landscapes. It is nice to read code, but if that is the point, why go through the trouble of making an Xcode project & scrollable sliding detail? It looks fabulous but at the end this lesson is in fact a walkthrough.

This was interesting, though:

Could the same code entered in a different approach on separate machines render something different?
Does this question make sense?

Choosing the right way to hide a view felt like a sticky pad with the text .opacity( 🙂 ✅

I want to take a moment and shout out another dev, Diego Lavalle for the article https://swiftui.diegolavalle.com/posts/linewrapping-stacks/. I had an issue which I was trying to grapple and this post gives me ideas on how to solve it.

Scaling Views to Complement Text I spent a lot of time reflecting on. Why? I was working on a problem around Accessibility and edge cases. On my ExitRowUI the circles would remain the same size as the Dynamic Type got larger, then if there are several trains at a particular station (Times Sq, Atlantic Av), the text inside would be clipped. The user would not be able to tell what they are seeing: it was just a circle with clipped text inside. This led me to tinkering with Label and reverting back to Text after noticing the content was no longer centered when I changed to Label. I did some digging and just like Diego made me imagine a solution to this problem on my ExitRow, I found a snippet from Apple in LazyHStack documentation that solved the problem in a different way.

Last post, I wanted to share how I’d start about helping new Swift developers understand how to use HStack, VStack, ZStack & a modifier .onAppear. In addition, I introduced the idea of running a Task and hitting a URL and returning some information to the console.

It was too much! I did not have a formal plan and as a result I wanted to explain too many things, the post was getting too long and it was not interesting anymore. This was my fault and I’m sorry readers. Many things going on here, and it is challenging staying focused and consistent. I’m here to review SwiftUI Concepts Tutorials. Once I am done maybe then I will create my own version of the tutorial. For now, let’s move forward.

Starting this lesson, I gained heaps 💡

They introduce the idea of KeywordBubbleDefaultPadding. Okay so what?

It goes back to the idea we started a few days ago. We parsed a CSV file that had locations for subway exits, and in the end we were able to parse and display a list of stations. What if we had a chance to prettify this and make the style of the letters what you would see from the MTA themselves?

I made some modifications here after reading this lesson. Originally, I had made it a ZStack with a Circle typed above Text. The sizes were independent of each other, so I like now I use .padding to let the system center the line designation.

Moving on the lesson highlighted the idea of ‘Dynamic Type’. This is for users who may want the font on their phone to be larger than standard- I was able to see the .frame(width: modifier I set was negatively impacting the size. Design would have my head! 😭 Removing that made my Circle increase with Dynamic Type. Again, the lesson helps me feel the gains 🏋️‍♂️

Exploring the Structure of a SwiftUI App

Today I started the next lesson from 🍎
It was a much softer launch than Landmarks. There, we are instructed to create a new app right away & start experimenting. Here in Section 1, we given some reading on the App, Scene & View protocols, further down we are directed to the Import Declaration & the @main attribute.

One thing I am curious about- are there other App attributes we should know aside from @main? Maybe it’s a silly question but let me write it for us to laugh at later and keep it moving

Section 2 seemed to be shorter than Section 1
They did have Experiment highlights on the side, encouraging followers to make small changes, change the padding parameter values, build and run, and that’s about it. Felt a little underwhelming, as they had us download a sample and officially we didn’t even change it.

Took some time to sit back & read the App protocol documentation.
The App manages the Scenes
The Scenes manage the View
Scenes respond to state changes
State is declared in the app, and it is shared across the Scenes.
A Scene may have one of three phases:
Active, Inactive, & Background
An Active Scene is in your face and we are interacting with it.
Background Scene has our app in the background, we have a phone call or different app in the foreground
Inactive tells us that the app should not receive events, and release memory / caches held
We are getting ready to shutdown and save. Apps would never stay in this state for very long.

In Lesson 2, we are learning about the view hierarchy of a scene. It made me feel a little down how the lesson could have been similar to Landmarks, there we actually have some tasks to accomplish. The whole gist of the lesson would have been stronger had they had us create a file such as MyAlternativeScene and give the learner some driving ability.

Lesson 3 was more reading and felt like it put me back in the learner’s seat instead of feeling like a passenger. Text, Symbols, Labels, Controls, Images and Shapes are introduced to the reader.

Came back around & read up on the Attributes, linking the idea that we could have a macro above a struct, why, and what some others are. Whew! Didn’t read it all, but I did see what they had to say about @main and now it is a bit more clear.