I seem to consume a lot of iOS Academy videos with great, short (< 10 minute) explanations of various Swift iOS programming topics - particularly little UI topics, like this one on the Grid View.
I really appreciate the generous content provision in the Swift and iOS development community. Perhaps this is the same for lots of technologies, but for someone who started programming pre-internet, it’s a stark difference to how I used to learn - so many magazines, and so many 2" thick books.
The first nine minutes of this video from Emmanuel Okwara finally gave me a clear understanding of the difference between MVC and MVVM.
In both MVC and MVVM the data & logic (Model) are separated from the part that the user interacts (View). Usually the View is a screen with controls and so on, but that’s not compulsory - for example a voice mail app interface would be all audio and DTMF. The point is that in both, the user interface (view) does not mess directly with the data (model) - it has to go through some sort of gatekeeper.
I’ve been playing in the zsh shell since I started on the Missing Semester , and was wondering how to get my git branch name in the prompt. A few googles later, I’ve installed Oh My Zsh, and added the git and macos plugins. Pretty.
On my git odyssey yesterday, I came across which is an MIT class for CS about practical things CS students don’t strictly need for their degree, but will greatly benefit from. I was interested in their git introduction, but they explain the course by saying:
Videos of the lectures, and all the course notes and assignments are freely made available. I’ve only watched the first lecture about the shell, and their git lecture. Both were excellent, so I’ll add this series to by Goals .
I spent most of the day learning about, and practicing with git. I’ll list some of the resources at the bottom, but for the moment, this is my understandings / cheat sheet for git. Since this could conceivably turn up in someone’s google search, and slightly less conceivably be of some use, I will come back and edit it if there’s something bad/wrong here. Comments would be great if you think that’s the case.
Thank you YouTube algorithm for this recommendation - Chris Lattner, the main author of Swift (amongst other things including LVM) chatting with Lex Fridman. Ignore the clickbait title. There is a good, brief discussion about the tradeoffs in value vs references types which is a topic I’ve been thinking a bit about this week.
Also some interesting comments about how a language delivers it’s complexity. Chris gives the funny example of what “hello world” looks like in Swift vs C++. Here’s Swift: Print("Hello world"), here’s C++:
Variables and constants in Swift can be a value type (their data is copied when they are copied) or a reference type (a pointer to the data is passed when they are copied.
Structs, integers, and enums are value types, classes are reference types.
Memory management of value types is relatively straightforward - there’s a 1:1 relationship between the variable name and its data, so if the variable goes out of scope it can get the chop. With reference types, it’s possible to have several variables (or class or struct properties etc) all pointing to the data, so a more sophisticated system is needed to know when it’s safe to delete the data.
Most of the things I’ve learned so far have been familiar, interesting, or cool - but now I’ve ventured far enough into the Swift Language Programming book to find something that is definitely going to take a couple of readings to piece together.
I was surprised, then pleased with functions as first class types, and the idea of passing closures around is powerful and useful.
My current difficulty is getting my head around closures capturing variables. It was tolerable (but not safe) when I just thought of it as a pointer, but when turned out the captured variable continues to exist in some sort of zombie state even after the scope where the variable was contained has ended.
Unwrap is the Paul Hudson app for Swift learning. It’s good for using those three minute gaps in life to digest a concept. I’ve incorporated it into my goals , as some days its the only progress I make.
I solved the problem (well, I googled a stackoverflow result to the problem) in the previous post about the different heights of the SF Symbols. The answer was to put them in a frame and lock the height. A problem that then arises from that is that when the user changes the text size, they’ll be out of wack. Apple’s solution to that, introduced in iOS 14 is the @ScaledMetric property wrapper that does some magic I don’t fully understand yet.
A small milestone achieved - I’ve completed the first assignment from the CS193p lecture series - some minor changes to the app being built in the lectures. There was a couple of things I was unhappy with:
The text under the SF Symbols you can see in the preview above not being vertically aligned.
Having duplicated code in my emoji arrays:
let animalEmojis = ["🐠", "🐢", "🦋", "🐥", "🐣", "🐰", "🐝", "🦄", "🐵", "🐛"]
let weatherEmojis = ["🌪", "🌝", "🌈", "🔥", "🌧", "🌙", "🌬", "☃️", "☔️", "🌫"]
let transportEmojis = ["🚗", "🚕", "🚲", "🚚", "🛵", "🚜", "🛴", "🛺", "🚃", "🚡"]
// I'm not happy with this duplication //TODO
@State var emojis = ["🐠", "🐢", "🦋", "🐥", "🐣", "🐰", "🐝", "🦄", "🐵", "🐛"]
I hadn’t fully gotten my head around what’s going on with the declarative nature of SwiftUI, until I’d watched this video
It’s from the 2019 WWDC which is when (I guess) SwiftUI was new. I still don’t have a good handle on how the views are bound to their data, but there is a video from this same series about Data Flows which I imagine will also answer those questions.
Dave Verwer’s iOS Dev Weekly digest of links mainly about Swift libraries was mentioned on a podcast I was listening to last night - perhaps the Swift with Sundellchat with Sommer Panage .
My first issue (it’s an email newsletter) arrived, and it’s pretty great. Not too long, chatty but on topic, and with links to follow for more info. As well as new or improved libraries, other topics are mentioned - I went down a rabbit hole on SwiftUI Split View Configuration , ending up at this WWDC video about it.
I had one of those synchronicity in learning moments this morning. I am reading The Swift Book - ie The Swift Programming Language, Swift 5.7 as part of my cs193p homework, and this morning, in a coffee shop was admiring what a clear, well written explanation was given for closures . It is super well written, stepping the reader through in logical (and digestible) steps.
If you’ve never carelessly passed around a pointer to a function and caused the Blue Screen of Death, or done much multi-threaded programming, the use-case for closures, and use of them is going to be challenging at first. Then Swift’s ability to cut the syntax down to very little will be challenging.
If you need a solid tour of the basics plus of Xcode, this is a great video from Karin Prater. Its the first video in her “Design-oriented course on SwiftUI”.
/*
create a struct to store information about a car, including its model, number of seats, and current gear, then add a method to change gears up or down. Have a think about variables and access control: what data should be a variable rather than a constant, and what data should be exposed publicly? Should the gear-changing method validate its input somehow?
*/
struct Car {
static let maxGear = 10
static let minGear = 1
var model = "no model"
var seats = 4
private (set) var currentGear = Car.minGear
init (model: String, seats: Int) {
self.model = model
self.seats = seats
}
mutating func gearUp() {
if currentGear < Car.maxGear{
currentGear += 1
}
}
mutating func gearDown() {
if currentGear > Car.minGear{
currentGear -= 1
}
}
}
var myUte = Car(model: "Rodeo", seats:2)
print("My \(myUte.model) has \(myUte.seats) seats and is in gear: \(myUte.currentGear)")
myUte.gearDown()
print("My \(myUte.model) has \(myUte.seats) seats and is in gear: \(myUte.currentGear)")
myUte.gearUp()
print("My \(myUte.model) has \(myUte.seats) seats and is in gear: \(myUte.currentGear)")
One of the iOS development podcasts in my current rotation is “Swift Over Coffee”, it’s blurb is:
Swift over Coffee is a podcast that helps you keep your Swift skills up to date the easy way, hosted by Paul Hudson and Erica Sadun. Each episode has news, our picks of the week, plus an open ballot where you can share your views on important topics.
And that is about how it goes. In Season One, it’s actually Paul and Sean Allen at the mic, they chat about news and topics related to Swift and iOS development, and each week there’s a Twitter question that people have chipped in on and the hosts go over these different views in some detail.
A couple of times in the App Development seminar I went to, we used system symbols in the place of images, and in his tutorial on Swift UI Basics, Sean Allen spent a few minutes talking about where they come from and how to choose them.
First, here’s how they look in code - this is from the default Hello World app.
struct ContentView: View {
var body: some View {
VStack {
Image(systemName: "globe")
.imageScale(.large)
.foregroundColor(.accentColor)
Text("Hello world")
}
}
}
Sean Allen has come to my notice a couple of times, once where he was mentioned as freelance contractor who is a great contributor to the community (I think perhaps that was on Swiftcoders Podcast ), and I’ve also bumped into him as co-host (with Paul Hudson) of the early episodes of the “Swift over Coffee ” podcast.
This video I watched last night is a compilation of the first few videos of Sean’s SwiftUI course , and it’s pretty great. In particular he does a great job of explaining how to start to refactor child views out and call them, and how all the stacks go together to make a pretty interface. What he does not do is vist/explain any of the Swift language fundamentals. If you don’t already know what a struc is, and the Swift flavour of them, it may be a challenging place to start.
