Mobile App Development 2022W Lecture 3
Video
Video from the lecture given on January 19, 2022 is now available:
Video is also available through Brightspace (Resources->Zoom Meetings (Recordings, etc.)->Cloud Recordings tab). Note that here you'll also see chat messages.
Notes
Lecture 3
---------
- how to succeed in this class
- how to suceed in computer science
- Tutorial 2
For tutorial checkoff
- no more than one week behind
- so I can checkoff Tutorial 1 while we're doing Tutorial 2, but
not once we do Tutorial 3
- don't fall behind!
From the Teams discussion
- if you have too much in a View, you can use group to fit in more
How to succeed in this class
- You *should* use Internet resources. Search away!
- But...that is just the start, not the end
- don't stop once your code is working
- continue until you understand why it works!
The ultimate source of truth in software systems is always the code
- documentation is always incomplete, and it is often wrong
- especially for systems that are being actively developed,
docs can refer to older versions
But when you're dealing with commercial systems, the code is often not all
available
- so then use documentation where it exists
- where it doesn't, do experiments!
Trust the documentation...but verify
- sometimes your code is fine, it is other people's code that is broken!
Because Internet resources are so rich, many people fall into copy-paste-fiddle
- and so they never really understand why things work or not
Your goal, always, is to enrich your mental model of how things work
- computers in general, and the software specifically that you are working with
- but, remember your model will *always* be incomplete
This really matters in mobile development
- your code runs on top of lots of other people's code
- that code keeps changing and won't be completely documented
I'm no master of Swift or Kotlin
- but, I have many years of experience with lots of software systems
and languages
- and basically the same ideas are used again and again
- keep an eye out for concepts you haven't learned before...and
then go learn them!
declaring variables
- var: variable that can change value
- let: variable that can't change variable (so it is immutable)
- but remember scoping rules, the same name isn't always referring to the same data
structs and classes
- a class is like objects in other languages
- a struct is an immutable data structure
You declare a struct by saying the name of the struct, the type, and then the contents of the struct.
When we define structs though, we actually say what "protocols" the struct follows
- essentially, what methods we are saying this struct will have
Everything you put in a body of a View is another View, or helps produce a View
Views are what make up a screen
- everything you put on screen in SwiftUI fits into a view of some kind
- and those views are often nested, potentially many deep
And so there are many ways to combine views
When you're inside of the body of a View, regular Swift rules don't always apply
- you can't just do regular loops
- only so many views you can put in
- many, many constraints
- almost like a different programming language
- actually, it is a domain-specific language for creating user interfaces
- just implemented in Swift
But if you're inside of a function, then you can do all the normal Swift/general programming language stuff
- you can call functions inside of a View body, but only in constrained ways
- note that $'s are a SwiftUI thing, not a Swift thing
analysis[analysisMode]!(t) (line 16)
analysis is a dictionary/hash table
- maps strings to functions
- so we give it a string, it returns a function, and then we call the function
- the ! is there to unwrap - we're guaranteeing the lookup in the hash
table will succeed
a hash table is an implementation of a dictionary
Note the definition of a function type on line 55:
(String) -> String
So any function that takes a string as an argument and returns a string would
match this type
We are treating functions as another kind of data that can be passed around
- "first class functions"
The -> is used to declare the return value of a function
Example:
func countUpper(_ s: String) -> String {
func this is a function declaration!
countUpper the name of the function
( start of the arguments to the function
_ you don't need to name the next argument
s name of the first argument, can be used
in the body of the function
: String the type of s
) end of argument list
-> function return value type comes next
String return value of the function
By default, in Swift are function arguments must be named
- in most other languages, the default is unnamed arguments
(so we tell the difference between them based on the position
in the argument list)
in other languages
call functions with "f(a, b, c)"
in f's declaration, a => firstarg, b => secondarg, etc
In swift, you can do the same, but you'd have to say
func f(_ firstarg: String, _ secondarg: String, ...
You specify all the potentially unnamed arguments then the ones that must be named.
Often, we use unnamed arguments for arguments that must be passed in,
and named arguments for ones that can be optional (and thus have
default values).
Note that when you use named function arguments, you can change their order
arbitrarily. (So they are more verbose but potentially easier to use.)
In analysis, "Upper Case" is defined as the key with the value being countUpper
(the function we defined previously)
But "Count"'s value is this:
{s in return String(s.count)}
This is actually a function declaration!
- but it is an anonymous function, i.e. a "closure" in Swift syntax
- it is a function without a name, it is just a value
Function is between {}
- argument list comes before "in" keyword
- body of function is afterwards
- here, the body is just a return statement
Closures actually show up everywhere in Swift
- often anywhere you have { }
You want a named function if you're going to call it in multiple places
But if you're defining a function that will have only one reference in your code, why bother with a name?