Mobile App Development 2022W Lecture 9

Video

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

Today: Tutorial 5

Also, questions about A1 or Tutorial 4?

Tutorial 5 is the last on iOS
Tutorial 6 we start with Android

Please have Android Studio running before Feb. 16th (for Tutorial 6).

Android will be in Kotlin, which has many connections with Swift
 (but Swift was a better Objective-C, Kotlin is a better Java)

A2 is due Feb 18th but is accepted until Feb 22nd, solutions will come out on Feb 23rd (during Winter Break) and we'll discuss them during the midterm review.

A2 will come out tomorrow.

Tutorial 5
----------
 - UIKit/Storyboard, not SwiftUI
 - with SwiftUI, we specify the layout using constraints
    - avoid absolute coordinates because supposed to work
      on many differently sized devices
 - with Storyboard, we can do constraint-based layout, but
   by default it will use absolute coordinates

Storyboard *seems* very easy to use.  It is a GUI for making layouts!
 - but if you want layouts that work on different devices, not so good...


Storyboard is based on old tech
 - direct descendent of NeXTStep's interface builder (IB),
   which is from 1989 or so
 - MacOS is a direct descendent of NeXTStep
    (In some frameworks you'll see the abbreviation "NS", that stands for
    NeXTStep)

Notice that SwiftUI is really taking ideas from web development and
using them for mobile and desktops
 - web pages have to adapt to different screen sizes, after all

Storyboard is fundamentally more mature than SwiftUI
 - underlying tech mostly for SwiftUI
 - been around decades longer
 - Storyboard is how iOS apps have been built since the beginning
 - so, you may need to use components from UIKit/Storyboard
   - but you can integrate the two, you don't have to make pure SwiftUI apps

"weak" variables means that someone else manages the underlying storage
 - so we're not in charge of reference counting, this reference
   doesn't control the object's lifetime

Why are there !'s after the @IBOutlet declarations?
 - we're manually unwrapping the value
 - basically, we're asserting that this value will never be nil
   (if it ever is, the app will crash)
    - note that we won't be assigning values to it,
      iOS will take care of it through the connection to the appropriate storyboard

Note that ViewController is a class, not a struct
 - structs are immutable, classes are mutable
   - (yes Views in SwiftUI have state, but @State declarations
      actually are an immutable reference to a mutable class
      that stores the actual data)

There's no weird domain specific language in Swift code in Storyboard apps
 - the DSL part is in the XML/interface builder for the storyboards