UPGRADE YOUR SKILLS: Learn advanced Swift and SwiftUI on Hacking with Swift+! >>

Working Through my 100 Days of SwiftUI

Forums > 100 Days of SwiftUI

Hi. I am Eric. I have dabbled in front end and mobile development for many years. I was once a GIS analyst who did some light weight scripting and was comfortable pulling data from a range of remote sources, but by no means have I ever considered myself a programmer. Most of my career has been in project management, focused on stakeholder management and acting as a client's primary point of contact on a variety of different types of endeavors. I am here to change that. I want to get my hands dirty with code again, and puruse work as an iOS Developer.

As suggested by @Obelix, I will use this thread to share my progress through this course.

I'm starting with Lesson/Day 8 and its wonderful Checkpoint 4. I feel that Lessons seven and eight really took things up a notch.

Day 8

Regarding Check Point 4. As I always do, I started by breaking the challenge down into managable parts.

Some thoughts:

  • The error handling was kind of intimidating at first, but once I built my enum and reviewed the previous lecture material it was not all that difficult to put together.
    enum numberError: Error {
    case lessThanOne, greaterThanTenThousand
    }

and later in the code:

do {
    let result = try findTheSquareRoot(number: number)
    print("Your number is \(result)")
} catch {
    print("Out of bounds.")
}
  • To get started on the whole square root part of the function I relied upon sqrt(). This allowed me to focus on generating random numbers for input, making sure the error handling worked, and my various print statements were in line with requirements.
  • Once I had a version working that relied upon sqrt(), I went about making a standalone square root solution function. Wow was there a lot of tiral and error here, including the review of many SO posts about finding square roots, in other programming languages.
  • In the end, I made something that worked, but didn't like that I was coming up with ridiculously long Doubles as solutions--I need Ints, also a requirement of the drill.
  • Using sqrt() was a tremendous help. Keep things simple. I also used a set Int as my input, a perfect square. Working with the perfect square as an input also helped me focus on making the entire function work correctly, before introducing random numbers as input. I later changed from a set perfect square (for some odd reason I used 900) to random the Ints. I toyed with floor() quite a bit, to help me with test of my input number. I also spent time working with the % operator.

1      

Day 9 - Closures and Cleaner Code

An observation, or maybe a frustration, or how about point of discussion???

Swift does an excellent job of letting developers shorten code--make it cleaner.

As a less experienced programmer, this often frustrates me. Longer version are easier to make sense of and digest, at least for me that is true.

I am getting hit with this in the discussion of closures.

let sayHello = { (name: String) -> String in
    "Hi \(name)!"
}
print(sayHello("Taylor"))

The fact that we don't see what I will call an arguement name (or outside name?) makes for cleaner code, but it leaves out a nice indicator of what is required to make the closure or function work.

For me, more syntax can often be helpful.

1      

Checkpoint 5 -- Lucky Numbers

From the hip, here is version 1.0 of my solution to this checkpoint. I will keep after it, as I know there is room for improvement--but I'm out of time right now.

import Cocoa

// Filter out any numbers that are even
// Sort the array in ascending order
// Map them to strings in the format "7 is a lucky number"
// Print the resulting array, one item per line

let luckyNumber = [7, 4, 38, 21, 16, 15, 12, 33, 31, 49]
let arrayWithoutEvens = luckyNumber.filter { $0 % 2 != 0 }
let sortedArrayWithoutEvens = arrayWithoutEvens.sorted()
print(sortedArrayWithoutEvens)
for i in sortedArrayWithoutEvens {
    print("\(i) is a lucky number")
}
for i in sortedArrayWithoutEvens {
    print("\(i)\n")
}

Output

[7, 15, 21, 31, 33, 49]

7 is a lucky number

15 is a lucky number

21 is a lucky number

31 is a lucky number

33 is a lucky number

49 is a lucky number

7

15

21

31

33

49

1      

Eric makes a case for parameter names within Closures.

The fact that we don't see what I will call an arguement name (or outside name?)
makes for cleaner code, but it leaves out a nice indicator of what is required
to make the closure or function work.

Honestly, I don't have an answer or a rebuttal.
But look at the case below. When I defined someFunction, I just defined a signature that I need. I am leaving it up to the developer to provide me with a function that meets that signature. Indeed, there may be several functions available to a user supplied by a picker selection. I provide two examples.

At the time I define the signature for this function, I dont know if it's someone's first name, peer title, bovine species, or favorite spice.

// Paste into Playgrounds.
// Closure 1: a function that takes a String and returns an Integer
let countChars   = { (input: String) -> Int in input.count }

// Closure 2: a function that takes a String and returns an Integer
let almostRandom = { (input: String) -> Int in  input.count + Int.random(in: 1...4) }

// someFunction is a variable. not an Int, or a String, or a Bool
// someFunction must hold a function!
// Don't care what the function does.
// BUT the function must take a String and return an Integer.
var someFunction: (String) -> Int  // Here I don't know enough to name this string. countMyChars? randomSeedString?

someFunction = countChars  // doesn't care what the function does
someFunction("Count the letters in this string.")   // What parameter name would you use here?

someFunction = almostRandom // same. doesn't care.
someFunction("Return pseudo random Int.")  // What parameter name would you use here?

2      

Eric likes Swifty code.

Swift does an excellent job of letting developers shorten code--make it cleaner.

Which code is easier to read?

// From the hip:
luckyNumber.filter { $0 % 2 != 0 }          // Looks like C++ 🤢
// or
luckyNumber.filter{ $0.isMultiple(of: 2) }  // This seems easier to read!

2      

Eric sings a familiar song!

Day 8 Regarding Check Point 4. As I always do, I started by breaking the challenge down into managable parts.

Nice! That logic looks very familiar to me!

See-> Elephant Eating Instructions

1      

Hacking with Swift is sponsored by RevenueCat

SPONSORED Take the pain out of configuring and testing your paywalls. RevenueCat's Paywalls allow you to remotely configure your entire paywall view without any code changes or app updates.

Learn more here

Sponsor Hacking with Swift and reach the world's largest Swift community!

Archived topic

This topic has been closed due to inactivity, so you can't reply. Please create a new topic if you need to.

All interactions here are governed by our code of conduct.

 
Unknown user

You are not logged in

Log in or create account
 

Link copied to your pasteboard.