https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Mobile_App_Development_2022W_Lecture_6 2026-04-06T01:52:59Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=Mobile_App_Development_2022W_Lecture_6&diff=23748&oldid=prev 2022-01-28T20:07:49Z

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

Soma