Mobile App Development 2022W Lecture 10

From Soma-notes
Revision as of 05:57, 12 February 2022 by Soma (talk | contribs) (Created page with "==Video== Video from the lecture given on February 11, 2022 is now available: * [https://homeostasis.scs.carleton.ca/~soma/mad-2022w/lectures/comp1601-2022w-lec10-20220211.m4...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Video

Video from the lecture given on February 11, 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 10
----------

introduce Assignment 2
continue with Tutorial 5

Go ahead and download android studio before next Wednesday
 - give it time to run and update itself

Plain text files can have different line endings
 - CR, \r <--- old MacOS (like, really old)
 - LF, \n <--- Linux, UNIX, modern macOS
 - CR+LF, \r\n <--- windows

When you have a controller in Storyboard that can send events, those events are received by functions that are marked with "@IBAction"
  - you then have to connect the function to the correct storyboard outlet
    for the sent event

AnalysisResult view in textanalyzer-2 corresponds to
updateAnalysis in textanalyzer-3.
 - updateAnalysis is called in three places
   - when the first view is displayed
   - when the user types anything into the input field
   - when a menu item is selected
 - but, when is AnalysisResult called?
   - it is run whenever it needs to be, automatically
   - it will run when Contentview is put on the screen
     (because AnalysisResult is included), and it will run
     whenever mode and userInput change
       - i.e., when a menu item is selected and when a user types
       - but these calls are implicit, not explicit, we don't
         have to put them in manually, they just happen

Remember, in SwiftUI, when a @State variable changes, any views dependent on those state variables are automatically updated (i.e., their code is re-run)

When you have to do updates manually, it is very easy to skip or to do the wrong ones
 - then your interface is stale, doesn't reflect the underlying app state
 - leads to lots of bugs

That's why the modern way is to do things more declaratively
 - tell the system what the screen looks like based on data
 - the framework figures out when the screen needs to be updated based
   on changes to designated data
   
@State variables are the actual "state"
@Binding variables are references to @State variables
 - essentially pointers/call by reference

@State variables are really objects under the hood which do extra work whenever the object's properties are read from or written to
 - the set's and get's are overridden with extra functionality