> 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 |

<figure><img src="/files/byimjsMlMyk6gFysNXKn" alt=""><figcaption></figcaption></figure>

**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&#x20;

**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.&#x20;

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.&#x20;
* **Popping** - removes it

<figure><img src="/files/97xZ4UrJrrUJfSsKvPwC" alt=""><figcaption></figcaption></figure>

#### 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.

<figure><img src="/files/wohU2aFOPSXaIibxUzJe" alt=""><figcaption></figcaption></figure>

***

### 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.