> For the complete documentation index, see [llms.txt](https://ios-course.cornellappdev.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ios-course.cornellappdev.com/course-content/week-2-or-uikit-mvc-and-control/pre-lecture-reading-ii.md).
# Pre-lecture Reading II
### What is MVC?
MVC stands for **Model-View-Controller**. It's a software design pattern — a set of rules that govern how we organize our code. UIKit apps follow MVC as their core architecture.
Think of it like a TV setup as an analogy:
| Component | TV Analogy | Role |
| -------------- | -------------- | ----------------------------------------------- |
| **Model** | TV channels | Where the actual data lives |
| **View** | TV screen | Displays what's happening right now |
| **Controller** | Remote control | Tells the system what to do based on user input |
**Key Rule**: Views and Models never talk to each other directly. They always communicate through the Controller.
***
### Model
Models are objects that represent your app's **data**. They hold the information your app works with and get updated based on user interaction or data from a backend.
* Example: In Eatery, the models are things like dining halls and food items.
* We typically define models as **structs** in Swift.
#### Quick refresher on Structs vs Classes
**Structs are value types.** When you assign a struct to a new variable or mutate it, Swift creates a *copy*. The original is untouched.
swift
```swift
struct User {
var name: String
}
var user1 = User(name: "Vin")
var user2 = user1
user2.name = "Richie"
// user1.name is still "Vin"
// user2.name is "Richie"
```
**Classes are reference types.** Multiple variables can point to the *same* object in memory. Changing one affects all references.
swift
```swift
class User {
var name: String
init(name: String) {
self.name = name
}
}
var user1 = User(name: "Vin")
var user2 = user1
user2.name = "Richie"
// user1.name is now "Richie" too!
// Both variables point to the same object.
```
**When to use which?** Use structs for simple data models — they're faster and safer since mutations don't have unintended side effects. Use classes when you need inheritance or shared mutable state (like `UIViewController`).
***
### View
Views are the **visible UI components** — everything the user sees and interacts with.
This includes `UILabel`, `UIButton`, `UIImageView`, and so on, all of these are its own view!
In Eatery, the dining hall name displayed on screen is a `UILabel` that pulls its text from a dining hall model.
***
### Controller
Controllers are the **glue** between models and views. In UIKit, the controller is a `UIViewController`.
A typical flow:
1. User taps a `UIButton` (a **view**)
2. The controller receives that tap event
3. The controller updates the **model** (e.g., adds an item)
4. The controller updates the **view** to reflect the change
***
### Navigation
So far you've been working with a single screen. But real apps have many screens, each represented by its own `UIViewController`.
There are **two main ways** to navigate between screens:
#### Pushing / Popping
* View controllers are pushed onto and popped off of a **navigation stack**.
* The stack is managed by a `UINavigationController` (typically set up in `SceneDelegate.swift`).
Imagine a screen of information
* **Pushing** - slides a new screen in from the right.
* **Popping** - removes it
#### Presenting / Dismissing
* A view controller is **presented** on top of the current one (like a modal/sheet).
* It can be **dismissed** via gestures like swiping down or tapping a close button.
***
### Delegation (Preview)
Delegation is a pattern that lets a **child** view controller communicate back to its **parent**. For example, a settings screen might need to tell the home screen that the user changed their name.
The key idea: the child VC doesn't know *which specific* parent it's talking to — it just knows the parent can do certain things, defined by a **protocol**. This keeps things loosely coupled.
**Key terminology:**
* **Delegator** = the child VC that asks someone else to do something
* **Delegate** = the parent VC that actually does the work
* **Protocol** = the contract between them (similar to interfaces in Java)
> We'll dive much deeper into delegation and protocols in a future lecture. For now, just understand the high-level flow: child says "hey delegate, something happened" → parent handles it.
***
### Key Takeaways
* **MVC** separates your code into data (Model), UI (View), and logic (Controller). Views and models communicate only through the controller.
* **Structs** copy on assignment (value type). **Classes** share references (reference type). Prefer structs for data models.
* **Navigation** uses pushing/popping (with `UINavigationController`) or presenting/dismissing to move between screens.
* **Delegation** uses protocols to let child VCs communicate back to parent VCs without tight coupling.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://ios-course.cornellappdev.com/course-content/week-2-or-uikit-mvc-and-control/pre-lecture-reading-ii.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.