Mobile App Development 2021W Lecture 1
Video
Video from the lecture given on January 11, 2021 is now available.
Notes
Mobile Application Development Lecture 1 --------- Course outline - grading - communication - collaboration - accommodation - software Introduction - why this course doesn't make sense - why it does make sense Themes - working with large software systems - managing ignorance - mental models & experimentation - design rationale, not syntax - concurrency, asynchronous programming - event-driven programming - declarative programming - security constraints Tools - Xcode <--- only runs on MacOS - Android Studio <--- cross-platform you don't *need* your own device, but it can be fun! Programming languages for MAD - there are many languages - Swift - Legacy: Objective-C - Kotlin - Legacy: Java* We're starting with Swift and iOS, then will cover Android iOS is further along on the "modern" path - SwiftUI Why do I say these languages are more "modern"? - not memory management (we'll talk about that) It is all about types - especially type inference Normally with types we have - static <- C, Java - dynamic <- Python, JavaScript - references have no type, only data does - a reference (variable) can refer to data of any type With static types, the compiler can check function/method arguments - but at the cost of extra syntax, mental overhead With dynamic types, the runtime or app code checks types - so you get runtime errors that would have been detected by a compiler - but, you don't have to spend as much time thinking/ declaring types Swift, Kotlin do type inference - statically typed - but, compiler infers type based on context where it can - if type cannot be inferred and isn't specificed, you get a compiler error - no runtime type errors double f = 32.0; <-- C-like var f = 32.0; <-- JavaScript-like f = "Hello"; <-- legal in JavaScript, illegal in C var f = 32.0 <-- Swift knows that f is a double f = "Hello" <-- compiler error also used for object-oriented programming Big advantage: removes non-semantic text from code, makes code "clearer" when determining purpose Big disadvantage: adds magic, because while the compiler knows the types, the developer may not! Type inference comes from functional programming ML was a pioneer (I think) Programming paradigms - procedural <-- C functions, data - object oriented <-- Java, C++, objects that combine functions and data, inheritance - functional - no state, only bindings - based on *math* - changes i = i+1 - ML, Haskell, F#, - declarative <-- Prolog, automated theorem proving - give rules, knowledge, constraints - system figures out how to combine/use them Temperature converter - input a string, convert it to a float - but when I converted it, I got a "float?" - could be a float, could be null - using a null is bad, will cause program to crash - so compiler doesn't allow you to use a "float?", you have to check its value to convert it to a "float"