When I start talking about drawing, most people usually say they can’t do art with the phrase “I can’t even draw a straight line.” Video 10 in the Explore art with Procreate series addresses this directly: I teach you to make the straight lines of the artist. However, in the video, I didn’t unpack what that phrase really means and why it is holding you back in a lot more than drawing.  

What do we mean by a straight line? Generally, we mean a line made with the aid of a ruler or computer. We are demanding a line that is accurate to a level only machines can do. It looks like this: 

It may be accurate, but an important feature of this line is how boring it is. It has no life or energy. the line is always the same, no matter who draws it.  What many people draw instead is this: 

It is the careful line of trying to imitate a machine. Even the slightest error is magnified in our brains, often leading to more errors. Perfectionism kills this line. The controlled line of handwriting often does not work as accurately as we wish. Controlling our fingers and wrist to make a line requires too many inputs for the long distance. Our bodies, therefore, cause us to send different inputs than someone else’s body, and this line is always unique in its mistakes. If it were accurate like the machine line, everyone’s handwriting would be the same. Our errors in lines are what make us individuals. It is part of identity, yet we curse ourselves for being unique by saying we can’t draw a straight line. That line should be celebrated, not cursed. 

I draw, like many artists, not with the fingers and wrist like we are handwriting, but with the arm. I make not one but several strokes, and somewhere in all of them is a straight line. 

This line might look like a messy scribble close up. If you make your marks small enough or use big enough paper,  it looks straight with lot more energy. 

This line is a series of attempts to make a successful straight line. Each attempt would not be considered a straight line as we defined the mechanical one. Put together. They make a line that works for most uses of straight. 

This technique is not only true of lines but most creative work. We expect our creative work to look machine-made when it is our humanity and unique perspectives and abilities that give it value. Even more, when we try not one but multiple failed lines until we get a straight line without a machine and with more energy and personality than that drab mechanical one. Only on close inspection do we see all the failures that went into making that line. 

The best, most artistic way to make a straight line is to try and fail as many times as possible. Somewhere in all that mess, what we are looking for appears. So too with life, success and all creative work. 

There are some powerful documentation features of Xcode you may not be using and will make your life a lot easier. Take a look at the downloaded exercise file. Go ahead and run it like I have here. I wrote a simple app to turn on and off a matrix of lights. Stop the app. 

Looking at the ContentView code, It is hard to figure out what is going on. Click On LightbankView.  I’ve got a light bank up top and a Toggle buttonView below it that I made. One’s a model and one is a view. I might use elsewhere they are hard to add to the code. 

Option-Click the VStack. You get a popup that describes how a VSstack works. If you open the right sidebar and click the Help icon you see the same info again. If you option-click LightBank, you get very little, but you can change this. You see under the quick help Declared in. You can click that and go to the definition. 

Above the definition, you’ll add a special comment. Instead of two slashes, add three. Add the comment. 

/// A data structure for a row of lights 

 Hit Command-B to build the project. Click on the LightBank struct and the quick help shows your summary. 

Any time you add three slashes and text above a declaration, it shows up in the Quick Help summary. In Xcode 11, You can do this faster with a command-click.  Command-click BankState, and select Add documentation. You get a place marker for your summary. Add the following: 

/// A pattern of lights.

 As this is an enum, I might want the possible values, so I’ll add that.

Can be .allOn, .allOff, .evenOn or .oddOn.

Really that should be in the discussion, not the summary. Press return before Can. The comment appears on the next line. Add a dash between the triple slash and Can. Build again and check the Quick Help. Both the sidebar and the popup show the values in the discussion section of the quick help. 

 /// - Can be .allOn, .allOff, .evenOn or .oddOn.

You can format this too. For using code case on my enum values, I’ll use the reverse single quote found above the tab key. I can quote my values like this: 

 /// - Can be `.allOn`, .`allOff`, `.evenOn` or `.oddOn`.

Build and check it out. 

There are other callouts besides discussion. Head down to the init. Command-click and Add documentation to init. For methods with parameters you also get the parameters already listed for you. You can add these manually or use the Add parameter in Command-Click.  Add these comments: 

/// A data structure for a row of lights
/// - Parameter count: The number of lights in a row
/// - Parameter on: The pattern of lights in the row from `BankState`

I like having enum values handy, so I’ll finish this off with a copy and paste of the line above. 

 /// - Can be `.allOn`, .`allOff`, `.evenOn` or `.oddOn`.

Build again and head back to ContentView. 

Option-Click LightBank. You get the summary for the Struct.

Option-Click on count and you get the quick help for the initializer.

Your summary even shows in the code completion. add this: 

var moreLights = Lightban

Code completion has a summary. 

You can do a lot more formatting and even links with markup in quick help. Markup is also used in Playgrounds. Check out chapter 4 of my Swift Playgrounds Application Development course for a lot more you can do with markup.  

The Whole Code

You can look at the completed code for this project on GitHub here:

In our last tip, I made a single checkbox in SwiftUI. Let’s learn more about collections in SwiftUI and build a checklist. 

If you download the exercise file, you’ll find an expanded version of last week’s project. Under the model folder, I added some data for our list of pizzas to try.

let checkListData = [
     CheckListItem(title: "Neopolitan"),
     CheckListItem(title: "New York"),
     CheckListItem(title:"Hawaiian"),
     CheckListItem(title:"Chicago Deep Dish"),
     CheckListItem(title:"Californian")
 ]

You’ll see that has a struct backing it that stores the title and  an default value of false for each item. 

struct CheckListItem{
     var isChecked: Bool = false
     var title: String
 }

Suppose I wanted to make a list of all my items. Head to CheckListView.  I’d use a list like this: 

List(checkListData){ item in
     CheckView(isChecked: item.isChecked, title: item.title)
}
.font(.title)

However we get a message that CheckListItem does not conform to the Identifiable protocol.  Any object you iterate in Swift UI must have essentially a primary key, a unique identifier. I have two options here: The first is to use existing data, such as the title as my key. I can specify that by adding a parameter of id, set to my title.

 List(checkListData, id:\.title){ item in

The error disappears. However, that means I cannot have two titles the same. If you have unique data this works fine. You have to specify the id in this case, so this makes the checklist less adaptable. 

Our second and better possibility is to adopt the protocol Identifiable.  Head over to the ChecklistItem.  Add the Identifiable protocol to the struct. 

struct CheckListItem:Identifiable{ 

This protocol has one required property named id, which contains a unique identifier. While id can be any hashable type, I’ll make id an integer. 

var id: Int

I’ll change my data to include the id. I’ll add it to the first item. Then cut and paste into the rest. 

let checkListData = [
     CheckListItem(id:0,title: "Neopolitan"),
     CheckListItem(id:1,title: "New York"),
     CheckListItem(id:2,title:"Hawaiian"),
     CheckListItem(id:3,title:"Chicago Deep Dish"),
     CheckListItem(id:4,title:"Californian")
 ]

Our errors have disappeared. 

Change your content view to use the CheckList view. 

Again, I’ll Run on a device instead of the canvas.  You get a nice looking checklist that you can check. This is not yet storing the checkmarks. We’ll look into that in another tip. You’ll find it is best to adopt the Identifiable protocol for iterating in lists. 

The Whole Code

The code for this project is downloadable on GitHub at https://github.com/MakeAppPiePublishing/Tips_08_04_Checklist_End. There’s an accompanying video you can find at LinkedIn Learning.