Mobile App Development 2022W Lecture 6
Video
Video from the lecture given on January 28, 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 6
---------
Assignment 1 due Feb 3rd
- accepted until Feb. 15th, solutions discussed in class on the 16th
Assignment 2 due Feb 18th
- but accepted until Feb 22nd, no penalties
- A2 solutions posted on Feb 23rd, discussed in class on March 2nd
You can submit multiple times
- only the last submission is kept
A2 will be posted after T4 is posted
- so by the end of next week
When completing assignments and exams:
- download the template
- rename template, replacing "template" with your MyCarletonOne username
- fill in the top of the template
- make sure to use the correct Student ID number!
otherwise your grades may not be properly recorded
- put answers in the template using a text editor
- make sure to keep line endings as LF (not CR/LF)
- you can use a word processor, but then be sure to save
it as a text file (but beware, Word can insert weird characters
into text files)
- when you cite outside work, just add the info to the end of your answer
(references should be per question)
It can just be a link, but say what you got from each source
- run your answers through the validator
- make sure it reports "PASSED" at the top and
all your answers were properly split up
- if it passes, upload to brightspace
Why do this?
- because this way we can use a script to split up answers
- thus we grade all of question 1, then all of question 2, etc
- all with no names
- makes grading fairer and faster
LF is linefeed character, CR is carriage return
Text files can use these in multiple ways to indicate end of line
- LF is for UNIX-like systems (including modern MacOS)
- CR is for old Macs (MacOS 9 and before)
- CR/LF is for DOS/Windows text files
Note that the script looks for questions by looking for lines that start with a letter/number combination followed by a period. So don't start any lines in your answers with such a combination or it won't pass validation
- just add a space before a letter/number/period combination if you really
need it in your answer
Tutorial 3 - let's talk about gestures
In order to understand user events, we have to make sure we have a solid mental model of how things work in SwiftUI wrt user input
When a user touches the screen, presses a key, what happens?
Specifically, what code of yours runs?
- to a first approximation, your code does nothing at all, it is
all handled for you
You can choose to handle specific events, but they are mostly high level events
- something happened and you then respond
Notice what is happening with a TextField
- we tell it what the initial text is and we give it a state variable
- our code doesn't see individual keystrokes *at all*
- indeed, it doesn't directly see any of the keyboard input
- so we aren't doing anything like "readline", "scanf" etc
- that all happens behind the scenes
Instead, what happens is this
- we associate a state variable with the TextField
- when that state variable changes, SwiftUI refreshes all affected views
- by running our code defining how those views should look
In textanalyzer-1, only one view depends upon t (other than the TextField itself), the Text view on line 16 that reports the results of the analysis
- this Text view is redrawn whenever t changes, automatically
In classic GUI frameworks, things are very different
- we register an event handler for user input
- that handler processes the input, updates the app's state,
and then updates the user interface as needed (manually)
- many developers just create a "refresh entire screen"
after user input, but that can be slow and can lead to
the interface flickering
- SwiftUI does this, but it does so automatically and efficiently
Observe how we do animation then
- we can just update state variables, and the associated things displayed
will automatically change
- that's how the circle moves
So when we handle gestures, all we do is register functions/closures
that will be called when user input events happen
- and all those functions do is update state variables
Note that touch events are defined using high-level abstractions
- because processing user events manually is painful
- and also, that sort of state management doesn't fit in well with SwiftUI