Mobile App Development 2022W Lecture 3

From Soma-notes
Revision as of 18:06, 19 January 2022 by Soma (talk | contribs) (Created page with "==Video== ==Notes== <pre> Lecture 3 --------- - how to succeed in this class - how to suceed in computer science - Tutorial 2 For tutorial checkoff - no more than one...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Video

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?