entangledDEV

Git How-Tos I Reach For Daily Work

Mon, 27 Oct 2025 17:42:48 +0000

This is my running log of Git moves I reach for when I do work. Each mini-how-to includes the exact commands plus a quick note on what to watch for.

Squash Multiple Commits Into One

Use interactive rebase to collapse the last n commits into a single, tidy changeset.

Optional safety: create a backup branch before rebasing:

git branch backup/feature-branch-before-squash

git rebase -i HEAD~3

Replace 3 with however many commits you want to include, counting the current HEAD as part of that total. HEAD refers to the current commit, HEAD~1 to its parent, HEAD~2 to the one before that, and so on. When you run git rebase -i HEAD~3, Git lists the last three commits including HEAD. Run git log --oneline to count backward until you reach the oldest commit you intend to squash.

Tip: Use HEAD~3^ if you need to include the fourth commit in the interactive list.

For example, if your history looks like this (newest first):

a1b2c3 (HEAD)
d4e5f6
g7h8i9
j0k1l2

The command git rebase -i HEAD~3 opens the editor with:

pick j0k1l2
pick g7h8i9
pick d4e5f6

In the editor:

Leave the first commit as pick
Change the rest to squash (or s)
Save, then compose the final commit message

If conflicts appear, resolve them and resume with git rebase --continue.

To abort the squash at any point, run:

git rebase --abort

Force Push After Squashing

Once history changes, update the remote branch.

git push --force-with-lease origin feature/my-branch

--force-with-lease protects teammates by refusing to overwrite work you haven’t fetched.

Create a Local Repo and Wire Up a Remote

mkdir my-project && cd my-project
git init
# add files, then commit
git add .
git commit -m "Initial commit"
git remote add origin git@github.com:username/my-project.git
git push -u origin main

If the remote is empty, main (or master) becomes the default branch once you push with -u. Double-check the URL format (git@ for SSH, https:// for HTTPS) before adding the remote.

Track a Remote Branch Locally

When you create a local branch that should follow an existing remote branch, set the upstream explicitly.

git switch -c feature/api-integration origin/feature/api-integration
# or, if branch already exists locally
git branch --set-upstream-to=origin/feature/api-integration

Now git pull and git push know which remote branch to use. If Git complains that the remote ref is missing, fetch it first (git fetch origin feature/api-integration) and rerun the command.

Create a Branch and Push It Upstream

Shortcut to create a branch, commit, and publish it with upstream tracking in one go.

git switch -c feature/search-bar
git commit -am "Add search bar styles"
git push -u origin feature/search-bar

-u (or --set-upstream) wires the remote for future pushes. Remember that git commit -am only stages files Git already tracks—run git add first if you created new files.

Sync With the Latest From Main Without Merge Commits

Rebase your current branch onto main to replay your commits on top of the latest state.

Optional safety: create a backup before rebasing:

git branch backup/feature-search-bar-before-rebase

Make sure you have no pending edits: git status -sb should report a clean tree.
Update main so you are rebasing onto the real latest code.
```
git switch main
git pull --ff-only origin main
```
Return to your feature branch (replace with your branch name).
```
git switch feature/search-bar
```
Replay your commits on top of the freshly updated main.
```
git rebase main
```

⚠️ Rebase pointer:
In merges: ours = current branch, theirs = incoming.
In rebases: ours = target branch, theirs = replayed commit.
Pick the pieces you need, git add each resolved file, and continue with git rebase --continue.
If the rebase turns chaotic, bail out with git rebase --abort.

Once the history looks right, rerun your tests and publish the new linear history:

git push --force-with-lease origin feature/search-bar

If you prefer to preserve merge commits instead, use git merge origin/main.

Rebase Onto the Remote Version of Your Branch

When teammates update the remote feature branch, pull those commits in and resolve conflicts locally.

Optional safety: create a backup before rebasing:

git branch backup/feature-payment-before-rebase

Ensure a clean tree first: git status -sb.
Update your knowledge of the remote branch.
```
git fetch origin feature/payment
```
Switch to your local branch that you want to replay.
```
git switch feature/payment
```
Rebase onto the remote tracking branch you fetched.
```
git rebase origin/feature/payment
```

⚠️ Rebase pointer:
In merges: ours = current branch, theirs = incoming.
In rebases: ours = target branch, theirs = replayed commit.
Merge the pieces you want, stage them with git add, and continue (git rebase --continue).
If the rebase turns chaotic, bail out with git rebase --abort.
Alternatively, if your upstream is set, you can pull and rebase in one step:

git pull --rebase

After the rebase, rerun tests and share the rewritten history safely:

git push --force-with-lease origin feature/payment

Cherry-Pick a Fix Onto Another Branch

Grab a single commit and apply it elsewhere.

git switch release/1.2
git cherry-pick <commit-sha>

If conflicts arise, fix them, git add the files, and run git cherry-pick --continue.

For multiple commits, cherry-pick a range (the upper bound is exclusive):

git cherry-pick A..B

Tip: Use A^..B if you want to include commit A itself.

Quick Patch From a File Diff

Generate a patch for one file and drop it into another branch or repo.

git diff main..feature/payment checkout.swift > checkout.patch
git switch hotfix/payment-crash
git apply checkout.patch

Review the applied changes before committing.

git apply only affects the working tree; follow up with git add and git commit once you confirm the patch looks right.

Tip: Run git am checkout.patch instead if you want to preserve the original author and commit message from the patch.

Merge Main Into Your Branch (Keep the Merge Commit)

If your team relies on merge commits for context, integrate the latest main without rewriting history.

git fetch origin
git merge --no-ff origin/main

Resolve conflicts, run the test suite, and let Git create the merge commit message. --no-ff retains the merge node even when a fast-forward is possible, preserving the branch narrative.

See What Changed Between Two Branches

Compare your feature branch to main, highlighting only the files or commits that differ.

git log --oneline main..feature/billing
git diff --stat main...feature/billing

Two dots (..) show unique commits; three dots (...) reveal files that diverged from the common ancestor.

Undo the Last Commit (Keep Changes)

Keep your working tree but remove the most recent commit.

git reset --soft HEAD~1

HEAD is the current commit, so HEAD~1 targets the one before it. The changes remain staged. To unstage but keep edits, use git reset --mixed HEAD~1.

Recover Work You Thought Was Gone

If a commit vanished after a reset or rebase, scan the reflog.

git reflog

You can use git show <reflog-sha> to inspect the commit before checking it out.

git switch --detach <reflog-sha>

Create a new branch from that SHA to rescue the work: git switch -c rescue/forgotten <sha>.

Stash Selective Files

Avoid stashing the whole tree by selecting specific paths.

git stash push -- src/HomeView.swift
git stash list
git stash pop

Combine with --keep-index to stash only unstaged changes. Stashes are stored in order; use git stash list to view entries and git stash pop stash@{1} to apply a specific one.

Clean Untracked Files Safely

Preview deletions before scrubbing untracked files and directories.

git clean -nd
git clean -fd

-n performs a dry run; -f is required to delete, and -d includes directories. Double-check the dry-run output carefully—git clean is irreversible once it runs with -f.

Revert a Commit That Already Hit Main

Create a new commit that undoes a previous one (keeps history intact).

git revert <commit-sha>

Grab the commit SHA from git log --oneline. If the revert itself fails because of conflicts, resolve them, git add the files, and run git revert --continue.

Tip: Need to revert several commits in one go? Use git revert -n <sha1> <sha2> ... to stage the reversions and commit once at the end.

Rename a Branch Locally and Remotely

git branch -m old-name new-name
git push origin --delete old-name
git push -u origin new-name

If the branch is protected, you may need admin permissions (or to lift protection temporarily) before deleting it remotely. Afterwards, clean up stale references locally:

git fetch --prune

Anyone else using the old branch should do the same and check out the new name.

I add to this page whenever I find myself repeating a Git flow. If you’re reading along and need another scenario covered, let me know and I’ll expand the list.

Parsing JSON with Swift

Thu, 23 Oct 2025 03:44:31 +0000

Swift’s Codable APIs make JSON parsing approachable, but real-world payloads often include missing keys, dates, snake_case fields, or constrained enums that deserve stronger typing. This guide captures the patterns I reach for when building production decoders, so future-me has a single reference of best practices and battle-tested examples.

Sample JSON Payload

{
  "id": 42,
  "username": "entangled_dev",
  "display_name": "Entangled Dev",
  "created_at": "2025-10-01T09:42:00Z",
  "is_admin": false,
  "profile": {
    "bio": "Building with Swift and SwiftUI.",
    "website": "https://entangled.dev"
  },
  "favorite_languages": ["Swift", "Rust", "TypeScript"]
}

Create a Codable Model

struct User: Codable {
    let id: Int
    let username: String
    let displayName: String
    let createdAt: Date
    let isAdmin: Bool
    let profile: Profile
    let favoriteLanguages: [String]

    struct Profile: Codable {
        let bio: String
        let website: URL
    }

    enum CodingKeys: String, CodingKey {
        case id
        case username
        case displayName = "display_name"
        case createdAt = "created_at"
        case isAdmin = "is_admin"
        case profile
        case favoriteLanguages = "favorite_languages"
    }
}

CodingKeys let you align Swift’s camelCase with the snake_case keys from the backend, keeping the rest of the code clean.

Decode with JSONDecoder

Assume sampleJSONString is the raw JSON string you received from a network call or fixture.

let jsonData = sampleJSONString.data(using: .utf8)!

let decoder = JSONDecoder()
decoder.keyDecodingStrategy = .convertFromSnakeCase
decoder.dateDecodingStrategy = .iso8601

do {
    let user = try decoder.decode(User.self, from: jsonData)
    print("Loaded user:", user.username)
} catch {
    print("Failed to decode user:", error.localizedDescription)
}

convertFromSnakeCase handles most key conversions automatically. Define explicit CodingKeys when the mapping is more nuanced or when you want control over a single property.

Configure a Shared Decoder

For larger projects, configure JSONDecoder once so the rest of your codebase stays focused on domain logic.

enum Decoders {
    static func api() -> JSONDecoder {
        let decoder = JSONDecoder()
        decoder.keyDecodingStrategy = .convertFromSnakeCase
        decoder.dateDecodingStrategy = .iso8601
        decoder.dataDecodingStrategy = .base64
        decoder.nonConformingFloatDecodingStrategy = .throw
        return decoder
    }
}

Returning a fresh decoder keeps the instance stateless and thread-safe. Keeping the configuration in one place makes it obvious which strategies are in play. If the API delivers milliseconds-since-epoch dates tomorrow, you only have one place to update.

extension JSONDecoder.DateDecodingStrategy {
    static let millisecondsSince1970: JSONDecoder.DateDecodingStrategy = .custom { decoder in
        let container = try decoder.singleValueContainer()
        let milliseconds = try container.decode(Double.self)
        return Date(timeIntervalSince1970: milliseconds / 1000)
    }
}

Swap this strategy in whenever the service moves away from ISO 8601 timestamps.

Handling Optional Data

Use optionals for fields the API might omit and supply sensible defaults.

{
  "id": "F2A0D5C2-3E43-4E58-880E-6BA16AD669E8",
  "title": "Build SwiftUI Layouts Quickly",
  "read_time_minutes": 6
}

struct Article: Codable {
    let id: UUID
    let title: String
    let subtitle: String?
    let readTimeMinutes: Int

    enum CodingKeys: String, CodingKey {
        case id
        case title
        case subtitle
        case readTimeMinutes = "read_time_minutes"
    }
}

let decoder = Decoders.api()
let articleJSON = """
{
  "id": "F2A0D5C2-3E43-4E58-880E-6BA16AD669E8",
  "title": "Build SwiftUI Layouts Quickly",
  "read_time_minutes": 6
}
"""
let data = Data(articleJSON.utf8)
let article = try decoder.decode(Article.self, from: data)
print(article.subtitle ?? "No subtitle provided")

When a key is missing and the property is non-optional, decoding fails. Treat optional values as a contract with the API, annotating properties only when absence is valid.

Supplying Defaults Without Optionals

Sometimes the backend omits a value but you still want a non-optional property. Provide the default inside a custom initializer so callers always receive a fully-formed model.

{
  "enabled": false
}

struct NotificationSettings: Codable {
    let isEnabled: Bool
    let frequency: Frequency

    enum CodingKeys: String, CodingKey {
        case isEnabled = "enabled"
        case frequency
    }

    enum Frequency: String, Codable {
        case immediate, hourly, daily
    }

    init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        isEnabled = try container.decodeIfPresent(Bool.self, forKey: .isEnabled) ?? true
        frequency = try container.decodeIfPresent(Frequency.self, forKey: .frequency) ?? .daily
    }
}

let settingsJSON = """
{
  "enabled": false
}
"""
let settingsData = Data(settingsJSON.utf8)
let settings = try Decoders.api().decode(NotificationSettings.self, from: settingsData)
print(settings.frequency) // daily

decoder.container(keyedBy:) hands you a keyed view into the JSON object so you can look up multiple fields by CodingKey. Think of it as opening a dictionary-like sub-decoder scoped to the current object. Without grabbing a container, you could only decode a single value at a time, which is fine for simple payloads but breaks down when you need to read several properties and coordinate defaults in one initializer.

Once you have a container, you reach into it with decode(_:forKey:) and decodeIfPresent(_:forKey:). They belong to the container—not JSONDecoder—and are the workhorses for extracting values.

decode(_:forKey:) assumes the value exists and is well-formed, so it either returns the decoded value or throws. Use it when the API contract says “this key is always there.”
decodeIfPresent(_:forKey:) returns nil when the key is missing or explicitly null, letting you fall back to sensible defaults without leaking optionals throughout the call site.

JSONDecoder will automatically assign nil to optional properties when you rely on the synthesized initializer, but only if the property itself is declared optional. In this example frequency is non-optional because the rest of the app expects a real value. Using decodeIfPresent lets you detect a missing key, supply a fallback (.daily), and still keep the property non-optional. If you called decode(_:forKey:) and the key or value was missing, decoding would throw instead of letting you inject a default.

What Happens to `init(from:)`

You never call init(from:) directly. When you ask JSONDecoder to decode a type, it checks whether that type implements init(from:). If it does, the decoder instantiates the Decoder context (containing the key/value containers) and invokes your initializer, passing that context in. If your type has no custom initializer, the compiler synthesizes one automatically. All you do is call decode(_:from:); the Decoder plumbing happens under the hood.

Here is what Decoders.api().decode(NotificationSettings.self, from: settingsData) does behind the scenes:

decode builds a Decoder object with the raw bytes and your global strategies.
The decoder sees NotificationSettings conforms to Decodable, so it calls your init(from:) (or the synthesized one if you didn’t write one).
Inside init(from:), you pull data out of the keyed container and provide defaults.
When the initializer returns, JSONDecoder hands you the fully initialized instance.

So the initializer is “injected,” but only because it’s mandated by the Decodable protocol; the runtime simply honors the implementation you supplied.

Modeling Enumerated Values

APIs often send constrained values that map cleanly to Swift enums. Prefer strongly typed enums over raw String or Int fields so you get compiler guidance and exhaustiveness checking.

1. Direct String Backing

{
  "path": "https://cdn.entangled.dev/images/header.png",
  "type": "png"
}

struct RemoteImage: Codable {
    let path: URL
    let type: ImageType

    enum ImageType: String, Codable {
        case png
        case jpg
        case heic
    }
}

Because ImageType conforms to String and Codable, decoding fails fast when the backend introduces an unexpected value, helping you spot contract changes. When a payload truly allows free-form values, fall back to String or Int; otherwise, rely on enums to keep the domain explicit and safe.

2. Mapping Backend Slugs to Expressive Cases

Sometimes the backend uses values that do not align with Swift naming conventions. When the payload is still a single string, mirror CodingKeys by assigning the raw value directly:

{
  "kind": "profile-picture"
}

enum AvatarKind: String, Codable {
    case profilePicture = "profile-picture"
    case organizationLogo = "organization-logo"
    case systemGenerated = "system-generated"
}

For richer enums that need custom logic during decoding or encoding, map them explicitly while keeping expressive case names.

{
  "path": "https://cdn.entangled.dev/avatars/42.png",
  "kind": "profile-picture"
}

struct Avatar: Codable {
    let path: URL
    let kind: Kind

    enum Kind: Codable {
        case profilePicture
        case organizationLogo
        case systemGenerated

        init(from decoder: Decoder) throws {
            let container = try decoder.singleValueContainer()
            switch try container.decode(String.self) {
            case "profile-picture": self = .profilePicture
            case "organization-logo": self = .organizationLogo
            case "system-generated": self = .systemGenerated
            default: throw DecodingError.dataCorruptedError(in: container, debugDescription: "Unsupported avatar kind")
            }
        }

        func encode(to encoder: Encoder) throws {
            var container = encoder.singleValueContainer()
            switch self {
            case .profilePicture: try container.encode("profile-picture")
            case .organizationLogo: try container.encode("organization-logo")
            case .systemGenerated: try container.encode("system-generated")
            }
        }
    }
}

decoder.singleValueContainer() is what you reach for when the JSON fragment you’re decoding is literally just a single primitive (a string, number, or bool) instead of an object with keys. Without it, you’d be forced to introduce fake CodingKeys or wrap the value in another type just to read it. The single-value container hands you that raw value directly so you can convert it into an enum case (or any other type) in one step. encoder.singleValueContainer() mirrors the idea when writing JSON, ensuring the enum encodes back to the original one-value payload.

Why does this work when the parent JSON (Avatar) also has a path key? JSONDecoder handles the outer object first. It builds a keyed container for Avatar, decodes path, and when it reaches kind it delegates to Kind.init(from:). That delegate initializer receives a nested decoder that already points at the "kind" value, so singleValueContainer() sees only that scalar string—"profile-picture"—instead of the whole object. Containers are scoped, so they never “see” sibling keys; the keyed container for Avatar keeps walking properties one-by-one.

switch try container.decode(String.self) then decodes the underlying string (throwing if it is missing or malformed) and immediately pattern-matches on the result. Each case maps the backend slug to the right Swift case, while the default branch surfaces unsupported values. This syntax keeps the decode + mapping logic tight and ensures the initializer exits once it finds a match.

func encode(to encoder: Encoder) is the flip side of init(from:). Conforming to Codable implicitly means conforming to both Decodable and Encodable; implementing this method lets you control how the enum (or struct) writes back to JSON when you call JSONEncoder().encode(...).

3. Capturing Unknown Cases

If you need to keep the app resilient while still flagging surprises, add an unknown case that stashes the raw value for logging.

enum ImageType: Codable {
    case png
    case jpg
    case heic
    case unknown(String)

    init(from decoder: Decoder) throws {
        let value = try decoder.singleValueContainer().decode(String.self)
        switch value {
        case "png": self = .png
        case "jpg": self = .jpg
        case "heic": self = .heic
        default: self = .unknown(value)
        }
    }

    func encode(to encoder: Encoder) throws {
        var container = encoder.singleValueContainer()
        switch self {
        case .png: try container.encode("png")
        case .jpg: try container.encode("jpg")
        case .heic: try container.encode("heic")
        case .unknown(let raw): try container.encode(raw)
        }
    }
}

This approach guards you against backends that silently add new types while preserving diagnostics for analytics or crash logs. You can combine it with the explicit mapping technique above by routing the default branch to .unknown(value) instead of throwing.

Custom Decoding Logic

For more complex transformations, implement init(from:).

{
  "accent_color": "FF0080"
}

struct Color: Codable {
    let red: Double
    let green: Double
    let blue: Double

    init(from decoder: Decoder) throws {
        let container = try decoder.singleValueContainer()
        let hex = try container.decode(String.self)

        guard let rgb = Int(hex, radix: 16) else {
            throw DecodingError.dataCorruptedError(
                in: container,
                debugDescription: "Expected a hex string like FF0080"
            )
        }

        red = Double((rgb >> 16) & 0xFF) / 255
        green = Double((rgb >> 8) & 0xFF) / 255
        blue = Double(rgb & 0xFF) / 255
    }
}

let colorJSON = """
{
  "accent_color": "FF0080"
}
"""
let accent = try Decoders.api().decode([String: Color].self, from: Data(colorJSON.utf8))
print(accent["accent_color"]?.red ?? 0)

Here the payload is a hex string ("FF0080") and the decoder must convert it into normalized color components. Throwing a DecodingError produces actionable diagnostics during development.

Decoding Polymorphic Payloads

When APIs send unions (one of several shapes under the same key), model them with enums that have associated values.

{
  "attachments": [
    { "type": "image", "url": "https://cdn.entangled.dev/image.png", "width": 640, "height": 480 },
    { "type": "file", "name": "report.pdf", "size_bytes": 10240 },
    { "type": "code", "language": "swift", "snippet": "print(\"Hello\")" }
  ]
}

enum Attachment: Codable {
    case image(Image)
    case file(File)
    case code(Code)

    struct Image: Codable {
        let url: URL
        let width: Int
        let height: Int
    }

    struct File: Codable {
        let name: String
        let sizeBytes: Int
    }

    struct Code: Codable {
        let language: String
        let snippet: String
    }

    private enum CodingKeys: String, CodingKey {
        case type
    }

    init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        let type = try container.decode(String.self, forKey: .type)
        switch type {
        case "image":
            self = .image(try Image(from: decoder))
        case "file":
            self = .file(try File(from: decoder))
        case "code":
            self = .code(try Code(from: decoder))
        default:
            throw DecodingError.dataCorruptedError(
                forKey: .type,
                in: container,
                debugDescription: "Unsupported attachment type: \(type)"
            )
        }
    }
}

Using enums keeps the call site type-safe. A switch on Attachment forces you to handle every variant and lets you opt in to unknown-case strategies where appropriate.

Mapping Nested Collections

When the API wraps arrays under a key, decode them via nested containers.

{
  "data": {
    "articles": [
      { "id": "1", "title": "Swift Strings 101", "read_time_minutes": 4 },
      { "id": "2", "title": "Macros in Swift 5.9", "read_time_minutes": 7 }
    ]
  }
}

struct FeedResponse: Decodable {
    let articles: [Article]

    enum CodingKeys: String, CodingKey {
        case data
    }

    enum DataKeys: String, CodingKey {
        case articles
    }

    init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        let dataContainer = try container.nestedContainer(keyedBy: DataKeys.self, forKey: .data)
        articles = try dataContainer.decode([Article].self, forKey: .articles)
    }
}

Nested containers keep your models minimal while handling payload structures that mirror database responses or GraphQL-style edges.

If the nested payload carries multiple fields you care about, decode each sibling from the same container.

{
  "data": {
    "articles": [
      { "id": "1", "title": "Swift Strings 101", "read_time_minutes": 4 },
      { "id": "2", "title": "Macros in Swift 5.9", "read_time_minutes": 7 }
    ],
    "other_property": "some value",
    "featured_article": { "id": "3", "title": "Concurrency Deep Dive", "read_time_minutes": 12 }
  }
}

struct RichFeedResponse: Decodable {
    let articles: [Article]
    let featured: Article?
    let otherProperty: String

    enum CodingKeys: String, CodingKey { case data }

    enum DataKeys: String, CodingKey {
        case articles
        case featuredArticle = "featured_article"
        case otherProperty = "other_property"
    }

    init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        let dataContainer = try container.nestedContainer(keyedBy: DataKeys.self, forKey: .data)
        articles = try dataContainer.decode([Article].self, forKey: .articles)
        featured = try dataContainer.decodeIfPresent(Article.self, forKey: .featuredArticle)
        otherProperty = try dataContainer.decode(String.self, forKey: .otherProperty)
    }
}

Nested containers behave like scoped dictionaries; once you have one, read every relevant key—required or optional—before you leave it.

Integrating with Legacy `[String: Any]` Stores

Some codebases funnel network payloads through a store that already parses JSON into [String: Any]. You can still lean on your Codable models instead of hand-casting dictionaries.

let storePayload: [String: Any] = [
    "data": [
        "articles": [
            ["id": "1", "title": "Swift Strings 101", "read_time_minutes": 4],
            ["id": "2", "title": "Macros in Swift 5.9", "read_time_minutes": 7]
        ],
        "other_property": "some value"
    ]
]

func decodeFeed(from payload: [String: Any]) throws -> RichFeedResponse {
    guard JSONSerialization.isValidJSONObject(payload) else {
        throw NSError(domain: "Store", code: 0, userInfo: [NSLocalizedDescriptionKey: "Invalid JSON object"])
    }

    let data = try JSONSerialization.data(withJSONObject: payload)
    return try Decoders.api().decode(RichFeedResponse.self, from: data)
}

Converting back to Data lets you reuse the same decoders and validation logic while keeping the legacy store untouched. If you truly need to stay in dictionary space, encapsulate the nested lookups in a helper so the casting is localized.

func articles(from payload: [String: Any]) throws -> [[String: Any]] {
    guard
        let data = payload["data"] as? [String: Any],
        let articles = data["articles"] as? [[String: Any]]
    else {
        throw NSError(domain: "Store", code: 1, userInfo: [NSLocalizedDescriptionKey: "Articles missing"])
    }
    return articles
}

The dictionary approach works, but it is fragile: missing keys collapse to nil, spelling mistakes slip through, and you duplicate parsing logic everywhere you need the data. Wrapping that plumbing in a helper at least centralizes the risk, but re-encoding to Data and letting Codable handle validation buys you type safety, better diagnostics, and parity with the rest of the codebase. Start with the helper as a stopgap, then migrate callers to the Codable path.

articles ends up as [[String: Any]] because every element of the JSON articles array is a JSON object ({ ... }). When bridged to Swift without a model, each object becomes a [String: Any] dictionary containing the article’s fields ("id", "title", "read_time_minutes", and so on). The surrounding array just preserves the list of those dictionaries until you map them into strong types.

Surface Decoding Errors Clearly

DecodingError carries rich context. Pattern-match on it to log actionable diagnostics instead of generic “data corrupted” messages.

func log(_ error: Error) {
    switch error {
    case DecodingError.keyNotFound(let key, let context):
        print("Missing key \(key.stringValue):", context.debugDescription)
    case DecodingError.typeMismatch(let type, let context):
        print("Type mismatch for \(type):", context.debugDescription)
    case DecodingError.valueNotFound(let type, let context):
        print("Expected value for \(type):", context.debugDescription)
    case DecodingError.dataCorrupted(let context):
        print("Data corrupted:", context.debugDescription)
    default:
        print("Unexpected error:", error.localizedDescription)
    }
}

Attach decoded context, request identifiers, or user IDs to this logging to make server/client contracts easier to debug.

Decoding with Swift Concurrency

func loadUser(from url: URL) async throws -> User {
    let (data, _) = try await URLSession.shared.data(from: url)
    return try Decoders.api().decode(User.self, from: data)
}

By returning the decoded type directly, your async functions stay composable. Propagating thrown errors lets the caller decide whether to retry, show an alert, or load fallback data. Pass the decoder in as an argument when you want to override strategies (e.g., JSON with UNIX timestamps).

Testing Your Decoders

Decode against local fixtures in unit tests to assert that the models match the API contract.

func testUserDecoding() throws {
    let bundle = Bundle.module
    let url = try XCTUnwrap(bundle.url(forResource: "user_fixture", withExtension: "json"))
    let data = try Data(contentsOf: url)
    let decoder = Decoders.api()

    let user = try decoder.decode(User.self, from: data)
    XCTAssertEqual(user.favoriteLanguages.count, 3)
    XCTAssertEqual(user.profile.website.host, "entangled.dev")
}

Testing with captured payloads surfaces breaking changes early and documents assumptions about optional versus required fields.

Wrap Up

Swift’s Codable ecosystem covers the majority of JSON parsing scenarios: adopt Decodable models, configure JSONDecoder centrally, lean on enums for constrained values, and reach for custom initializers when you need defaults or polymorphism. Combine these patterns with targeted logging and fixture-based tests to keep API integrations resilient and easy to reason about.

Inspecting your network traffic in Apple Platforms

Fri, 03 Oct 2025 17:21:27 +0000

Debugging HTTPS calls on iOS and iPadOS usually means reaching for a TLS proxy that can show you encrypted payloads. Charles Proxy remains a reliable option because it integrates with Apple devices, supports on-the-fly rewriting, and lets you archive sessions for later analysis. This guide walks through the minimal setup to get your device routing traffic through Charles without breaking App Transport Security (ATS).

Prerequisites

Charles Proxy 4.6 or newer installed on your Mac.
The iOS or iPadOS device connected to the same Wi‑Fi network as the Mac running Charles.
Developer access to the app you are testing so you can safely tweak networking settings if needed.

Configure the Wi‑Fi proxy on the device

Open Settings → Wi‑Fi on your device and tap the ℹ︎ icon next to the active network.
Scroll to Configure Proxy and choose Manual.
Enter your Mac’s local IP address in Server. You can find it in System Settings → Network or by running ipconfig getifaddr en0 on macOS.
Set Port to 8888 (Charles’ default) and leave Authentication off unless you enabled it in Charles.
Tap Save. Traffic now routes through your Mac for that Wi‑Fi network only.

Keep Charles open; if the proxy stops listening, iOS calls will fail immediately with NSURLErrorCannotConnectToHost.

Install and trust the Charles SSL certificate

Charles needs to present its own certificate so it can decrypt HTTPS. Apple treats any custom certificate as untrusted until you explicitly approve it.

On the device, open Safari and navigate to https://chls.pro/ssl.
Safari downloads a configuration profile and shows an Profile Downloaded banner. Tap it or go to Settings → General → VPN & Device Management.
Under Downloaded Profile, select Charles Proxy CA and tap Install. Confirm with your passcode and approve the warning prompts.
Navigate to Settings → General → About → Certificate Trust Settings.
Under Enable Full Trust For Root Certificates, toggle on Charles Proxy CA and confirm. Without this step, every HTTPS connection will fail due to trust errors.

Once trusted, Charles can decrypt traffic for domains that permit re-signing. ATS exceptions are unnecessary unless the app pins certificates or forbids proxies.

Verify the capture

In Charles, hit the Start Recording button (red circle). Leave Proxy → macOS Proxy off when you only care about physical devices; toggle it on if you also want macOS apps or simulators to route through Charles.
Launch your app and repeat the network flow you want to inspect.
Requests should stream into Charles’ session list. Double-click an entry to view request headers, response payloads, and TLS information.
Use Tools → SSL Proxying Settings to add specific hosts if Charles reports SSL handshake failed. Add domains with wildcards (for example, api.example.com or *.example.com).

If your traceroute stays empty, confirm the device still uses the same Wi‑Fi network and that no VPN profiles override your proxy settings.

Troubleshooting tips

Certificate pinning: Apps that implement SSL pinning will reject Charles’ certificate. Disable pinning in a debug build or use a build flavor without pinning to capture traffic.
HTTP/3 traffic: Charles downgrades HTTP/3 to HTTP/2. If your API strictly requires QUIC, test with Apple’s PacketLogger or consider Proxyman/mitmproxy with HTTP/3 support.
Background sessions: Background URLSession traffic may not route through the proxy when the app is suspended. Keep the screen awake or use Instruments’ HTTP template for background captures.
Different networks: Switching Wi‑Fi networks clears the proxy configuration. Re-apply the manual proxy after every network change.

Clean up when finished

Return to Settings → Wi‑Fi → (ℹ︎) and set Configure Proxy back to Off (or Automatic).
In Settings → General → About → Certificate Trust Settings, disable the Charles Proxy CA toggle.
Optionally remove the profile from VPN & Device Management to keep the device’s trust store clean.

Resetting both the proxy and certificate ensures future HTTPS requests use your production trust chain and keeps users from accidentally routing through a dormant proxy.

With these steps in place you can capture, inspect, and replay network flows directly from real devices, which is invaluable when simulator behavior diverges from field reports.

Handling Touch Gestures in UIKit

Sat, 21 Jun 2025 00:14:26 -0600

Hey everyone! In this post, I want to talk about how we can add and manage different gestures in UIKit. This post will be updated as I explore more gesture interactions. When needed, I’ll also touch on accessibility considerations, especially for VoiceOver.

Long Press Gesture

UIKit handles long press gestures using a class called UILongPressGestureRecognizer. You can attach it to any UIView using the addGestureRecognizer() method.

With UILongPressGestureRecognizer, you can configure:

The action that will be executed (this method must be marked with @objc),
The required duration before the gesture triggers,
And other options, which you can explore through the class’s available properties and methods.

Gesture States

The UILongPressGestureRecognizer can be in one of several states:

.possible: The default state before the gesture has been recognized.
.began: The gesture has met the minimum duration and has started.
.changed: The user’s finger has moved while still pressing.
.ended: The user has lifted their finger, ending the gesture.
.cancelled: The system canceled the gesture (e.g., an interruption).
.failed: The gesture didn’t meet the criteria for recognition.

Example

Here is a simple example of a label with an attached long press gesture recognizer:

import UIKit

class ViewController: UIViewController {
    
    private lazy var label: UILabel = {
        let label = UILabel()
        label.translatesAutoresizingMaskIntoConstraints = false
        label.text = "Hello, World!"
        label.textAlignment = .center
        label.font = .systemFont(ofSize: 24, weight: .medium)
        label.isUserInteractionEnabled = true // Required to detect gestures on the label
        return label
    }()

    override func viewDidLoad() {
        super.viewDidLoad()
        setupUI()
        setupLongPressGesture(for: label)
    }
}

private extension ViewController {
    func setupUI() {
        view.backgroundColor = .systemBackground
        
        view.addSubview(label)
        NSLayoutConstraint.activate([
            label.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            label.centerYAnchor.constraint(equalTo: view.centerYAnchor),
        ])
    }
    
    func setupLongPressGesture(for view: UIView) {
        let recognizer = UILongPressGestureRecognizer(target: self, action: #selector(handleLongPress))
        recognizer.minimumPressDuration = 0.5 // Customize duration if needed
        view.addGestureRecognizer(recognizer)
    }
    
    @objc func handleLongPress(_ gesture: UILongPressGestureRecognizer) {
        switch gesture.state {
        case .began:
            label.text = "Long press!"
        case .ended:
            label.text = "Hello, World!"
        default:
            break
        }
    }
}

This is a great starting point for adding more complex gestures or chaining interactions. In future updates, I’ll cover tap gestures, swipes, and how to handle VoiceOver interactions effectively.

Thanks for reading!

Reactive Sous Vide Cooking

Thu, 08 May 2025 22:52:30 -0600

Sous Vide Is the Combine of Cooking (and It’s Not Just a Joke)

Have you ever moved from imperative to reactive, functional Combine code and thought:

“Wait… why doesn’t everything work like this?”

That’s exactly how I felt after discovering sous vide cooking.

Sous vide isn’t just a trendy food technique. It’s a declarative, functional, reactive system for cooking. It replaces the chaos of heat guessing and overcooked edges with precise timing, temperature control, and fully composed flavour pipelines.

And yes — it’s basically Combine, but for food.

Traditional Cooking Is Imperative

Most traditional cooking is full of guesswork, manual state management, and side effects. You:

Flip meat constantly
Poke it to check doneness
Guess when it’s ready
Hope the inside isn’t raw while the outside burns

That’s imperative cooking — direct, stateful, and prone to edge-case disasters.

var isDone = false

while !isDone {
    checkCenter()
    flipSteak()
    hopeItWorks()
}

Sous Vide Is Combine

Now let’s look at sous vide — where you:

Set the desired temperature (like defining a Publisher)
Apply a precise duration (like chaining .debounce(for:))
Add aromatics and fats (like injecting dependencies)
Finish with a sear (a side-effect terminal operator)

Suddenly, your food becomes a purely defined stream of transformation:

ribeyePublisher
    .setTemperature(54)
    .forDuration(.hours(2))
    .combineLatest(thyme)
    .map { sear($0) }
    .sink { plate($0) }

That’s not just metaphor — that’s real cooking logic.

Ingredients Are Data — The Bag Is the DI Container

Before your food enters the pipeline, it’s prepared with all its required dependencies:

A protein with defined attributes: cut, fat content, target temp
Aromatics like garlic or thyme
Optional modifiers like butter, ghee, miso, or oil

You seal this together in a sous vide bag — your immutable dependency container:

let protein = Protein(cut: .ribeye, temp: 54)
let flavor = [thyme, garlic, butter]

let bag = SousVidePackage(main: protein, additions: flavor)

The bag acts like a sealed struct — containing everything your food needs to be transformed with zero mutation mid-process.

Once it enters the bath, it’s a pure, self-contained unit of flavour.

Cooking Pipelines: Combine-Style Breakdown

Combine Operator	Cooking Equivalent
`.setTemperature(_:)`	Declare target doneness
`.forDuration(_:)`	Sous vide cooking time
`.combineLatest`	Add infused flavours (herbs, fats)
`.map`	Sear, smoke, or torch the result
`.delay(for:)`	Resting time
`.sink`	Serve the final plate

Sous vide lets you build entire meals this way. Want to run proteins and veggies at different temps? Just spin up two pipelines (containers + circulators), and compose your plate from multiple streams.

Why This Actually Matters

This isn’t just a metaphor — it’s functionally better cooking.

Most of the cooking process becomes purely declarative:
you describe the end state (target temperature, duration, flavour infusions), and the sous vide system ensures it reaches that state with precision.

And yes, we still use imperative cooking — but only at the end.
The sear, the smoke, the torch — these are controlled, purposeful side effects, isolated to a small, well-defined step. That step is short, visible, and easy to get right.

This separation of concerns means:

The majority of the cooking is error-free and repeatable
The only mutable phase is optional and cosmetic (crust, browning)
You dramatically minimise the risk of failure, because 95% of the process is handled declaratively

Just like a good software architecture, sous vide isolates the risky, stateful parts of the process, keeping them out of the core logic — and your food is better for it.

Structuring Your Meal as Data

With sous vide, you start thinking in food components:

struct Protein {
    let cut: Cut
    let weight: Grams
    let desiredTemp: Celsius
    let aromatics: [Herb]
}

Even flavour additions can be typed and quantified:

protocol Flavoring {
    associatedtype Unit
    var amount: Unit { get }
}

struct Salt: Flavoring {
    typealias Unit = Grams
    let amount: Grams
}

struct Thyme: Flavoring {
    typealias Unit = Sprigs
    let amount: Sprigs
}

Each ingredient can now express what it is and how much of it belongs in the bag, keeping your recipe data clean, predictable, and reusable.

The more you model your meals like this, the more you realise:
you’re not improvising — you’re declaring data, composing systems, and defining a pipeline that transforms raw input into delicious output.

Conclusion

Sous vide didn’t just improve my meals — it changed the way I think about food.

It’s precise. It’s elegant. It’s reactive.
It respects the ingredient, avoids mutation, and lets me compose my meals with confidence.

And perhaps most beautifully: with sous vide, you start the pipeline, walk away, and wait for the system to emit a ready-to-finish result — perfectly aligned with Combine’s flow.

You don’t poke or poll. You don’t micromanage.
You subscribe once, and the water does the rest.
All you need to do… is sink { searAndServe($0) }.

Combine your flavours.
Compose your meals.
Serve with intention.

You’re not just cooking.
You’re declaring dinner.

PS: No sink was harmed in the making of this ribeye.

State Driven Enum Navigation

Sun, 06 Apr 2025 07:43:36 -0600

Navigating SwiftUI with an Enum Router (Cyclical A → B → C Flow) — A Simple example

Introduction

In this post, we’ll explore a lightweight, type‑safe way to manage navigation in SwiftUI by modelling screens as an enum and driving transitions with closures. We’ll illustrate a simple cyclical flow through three views—A → B → C → A—and then dive into the pros and cons of this approach.

1. Defining the Router State

First, we define an enum with three cases—one for each screen. This enum is our “single source of truth” for navigation state:

// Represents each screen in our app.
enum AppScreen {
    case viewA
    case viewB(someData: String) // We can pass values to next screens
    case viewC
}

2. The Router Protocol & Default Implementation

Next, we encapsulate navigation logic in a router object. Here’s a minimal protocol and default router using @Observable (iOS 17+), so SwiftUI updates automatically when currentScreen changes:

import Observation

protocol AppRouter {
    var currentScreen: AppScreen { get }
    func navigate(to screen: AppScreen)
}

@Observable
final class DefaultAppRouter: AppRouter {
    private(set) var currentScreen: AppScreen = .viewA
    
    func navigate(to screen: AppScreen) {
        currentScreen = screen
    }
}

We centralise navigation in one SwiftUI container. It switches over router.currentScreen and injects closures into each view to advance the flow cyclically:

import SwiftUI

struct CyclicalNavigationView: View {
    @State private var router = DefaultAppRouter()
    
    var body: some View {
        content
    }
    
    @ViewBuilder
    private var content: some View {
        switch router.currentScreen {
        case .viewA:
            ViewA { receivedData in // We capture the data send by ViewA.
                // We send the data to ViewB using the router.
                router.navigate(to: .viewB(someData: receivedData))
            }
        // We get the data from previous state and inject it when creating ViewB.
        case .viewB(let someData):
            ViewB(dataFromViewA: someData) {
                router.navigate(to: .viewC)
            }
        case .viewC:
            ViewC {
                router.navigate(to: .viewA)
            }
        }
    }
}

4. The Three Views

Each view is oblivious to the overall navigation logic—it simply calls its onNext closure when the user taps a button:

struct ViewA: View {
    let onNext: (String) -> Void // The closure receives tha data we want to pass to the next state.
    
    var body: some View {
        VStack {
            Text("View A")
            Button("Go to B") {
                // We pass data to next state using the closure argument.
                onNext("some Data from screen A")
            }
        }
    }
}

struct ViewB: View {
    // We optionally received some data from the router previous state.
    let dataFromViewA: String?
    let onNext: () -> Void
    
    var body: some View {
        VStack {
            Text("View B")
                .font(.title)
            if let dataFromViewA {
                Text(dataFromViewA)
                    .font(.caption)
            }
            Button("Go to C", action: onNext)
        }
    }
}

struct ViewC: View {
    let onNext: () -> Void
    
    var body: some View {
        VStack {
            Text("View C")
            Button("Go to A", action: onNext)
        }
    }
}

5. How It Works

Initial State The router starts at .viewA, so ViewA is presented.
Advancing Tapping “Go to B” calls router.navigate(to: .viewB), updating currentScreen. SwiftUI recomputes the switch and shows ViewB. Optionally if data must be shared or passed, we can use associated values and closure arguments to pass the data between states.
Cyclical Flow Similarly, B → C and C → A form a loop. There’s no back‑stack—each transition replaces the current screen.

Here is the navigation working:

6. Pros and Cons

Pros:

This enum‑and‑closure router is completely type‑safe and exhaustive—every possible screen must be handled in your switch, so you’ll never accidentally forget a case. All of your navigation state lives in one place, making it easy to reason about where the app is and simple to write unit tests against your navigate(to:) calls. Because each view only knows about its own onNext closure, your views stay decoupled from routing details and remain highly reusable. You can also test the router in isolation—just invoke navigate(to:) and assert that currentScreen changes as expected. Finally, modelling screens as an enum feels very “functional,” with no magic strings or identifiers floating around.

Cons:

On the flip side, there’s no built‑in history or back‑stack: each transition outright replaces the current screen, so if you need “go back” behaviour you’ll have to roll your own stack. You also miss out on SwiftUI’s native push/pop animations and swipe‑back gestures, unless you add transitions manually or switch to NavigationStack. As your app grows, the central switch can become large and repetitive, leading to boilerplate that’s harder to maintain. Supporting deep‑linking or state restoration means you must write custom serialization for your enum state. And finally, this pattern is best suited to single, linear (or cyclical) flows—if you have branching paths, modals or nested stacks, you’ll likely need a more sophisticated coordinator.

7. Conclusion

This enum‑and‑closure router shines for simple, linear or cyclical flows. It’s clear, type‑safe and easy to test. However, if you need: • A back‑stack with swipe‑back animations • Deep‑linking or state‑restoration support • Complex branching or modal flows

you might migrate to SwiftUI’s NavigationStack (iOS 16+) or adopt a more full‑featured coordinator. For many lightweight apps—like our A → B → C cycle—this pattern is both elegant and practical.

SwiftUI Generic Containers

Sun, 06 Apr 2025 05:20:12 -0600

Want to make your SwiftUI views more reusable, composable, and clean?
This post explores how to build your own generic containers using Swift’s type system and SwiftUI’s powerful @ViewBuilder + closure patterns.

Whether you’re building custom layouts, DSL-like preview wrappers, or logic-driven composition — understanding generic containers is a key unlock.

💡 SwiftUI Tip: Wrapping Views with Generics and Closures

I recently hit a situation in SwiftUI that seemed small at first — but led to a mini “aha!” moment about closures, generics, and how SwiftUI composes views.

This is one of those tricks that’s easy to overlook until you need it — but once it clicks, it unlocks a whole new layer of composability.

🚧 The Problem

I wanted to create a wrapper for SwiftUI previews — one that adds common styling like background color and full-frame layout, so I wouldn’t have to repeat this over and over:

#Preview {
    VStack {
        MyCoolView()
    }
    .frame(maxWidth: .infinity, maxHeight: .infinity)
    .appBackground()
}

Simple enough, right?

So I tried to create a wrapper like this:

struct PreviewWrapperView: View {
    let content: some View // ❌ Error!
    
    var body: some View {
        VStack {
            content
        }
        .frame(maxWidth: .infinity, maxHeight: .infinity)
        .appBackground()
    }
}

But Swift gave me the error:

“Property declares an opaque return type, but has no initializer expression…”

🔍 The Fix: Use a Generic + Closure

Swift doesn’t allow some View as a stored property type — it only works for return values.

The correct pattern looks like this:

struct PreviewWrapperView<Content>: View where Content: View {
    @ViewBuilder let content: () -> Content

    var body: some View {
        VStack {
            content()
        }
        .frame(maxWidth: .infinity, maxHeight: .infinity)
        .appBackground()
    }
}

And then you use it like this:

#Preview {
    PreviewWrapperView {
        MyCoolView(param: 123)
    }
}

🤯 But wait — doesn’t `MyCoolView(param: 123)` need a closure like `(Int) -> some View`?

This was the part that clicked for me.

No.
You’re not passing MyCoolView as a function.
You’re calling it inside the closure, and returning the result.

That means you’re passing a closure like:

() -> MyView

Which matches () -> Content just fine.

🧠 What this unlocked for me

I realized this pattern is everywhere in SwiftUI:

NavigationStack { ... }
Section(header: Text("...")) { ... }
Button { ... } label: { ... }

Once you know how to create your own view wrapper using a generic and a closure, you can build anything from:

DSL-style layout containers
Reusable environment-aware wrappers
Onboarding and modal flows
Themed previews
Stylized layout shells with safe areas, animations, shadows…

🧪 Bonus: Custom Layout Containers

Now that you understand how to use closures and generics to wrap views, here’s a real-world way to apply this pattern for styling and layout reuse.

Let’s say you want a layout that wraps your screen content in consistent padding, background, and spacing — and optionally adds a footer.

At first, you might be tempted to make the footer closure optional, or try to hack it using AnyView or Footer? tricks. But there’s a cleaner, more Swifty way — and it’s the way Apple does it too.

Instead of creating multiple types, Apple defines multiple initializers in the same struct — and we can do the same.

Here is the wrapper using all we have learned today!

struct StyledScreen<Content: View, Footer: View>: View {
    let content: Content
    let footer: Footer?

    init(
        @ViewBuilder content: () -> Content
    ) where Footer == EmptyView {
        self.content = content()
        self.footer = nil
    }

    init(
        @ViewBuilder content: () -> Content,
        @ViewBuilder footer: () -> Footer
    ) {
        self.content = content()
        self.footer = footer()
    }

    var body: some View {
        VStack(spacing: 24) {
            content
                .padding()
                .background(Color.secondary.opacity(0.1))
                .cornerRadius(12)

            if let footer = footer {
                footer
                    .padding(.top, 32)
            }
        }
        .padding()
        .overlay(
            RoundedRectangle(cornerRadius: 16)
                .stroke(.gray.opacity(0.3), style: StrokeStyle(lineWidth: 1, dash: [6]))
        )
        .frame(maxWidth: .infinity, maxHeight: .infinity)
        .background(Color(.systemBackground))
    }
}

📦 Usage

#Preview {
    VStack {
        // With no footer
        StyledScreen {
            Text("No footer")
        }
        
        // With footer
        StyledScreen {
            Text("Has a footer")
        } footer: {
            Button("Continue") { }
        }
    }
}

This version matches Apple’s API design philosophy.

Here is the result:

🤔 What’s up with `where Footer == EmptyView`?

This line:

init(@ViewBuilder content: () -> Content) where Footer == EmptyView

might look strange at first — but it’s key to enabling a clean, SwiftUI-style API.

💡 Why it exists:

Our StyledScreen struct uses two generics:

struct StyledScreen<Content: View, Footer: View>

That means Swift needs to know both types — even if the user doesn’t explicitly pass a footer.

If we don’t specify what Footer is, Swift will throw an error like:

“Cannot infer generic parameter ‘Footer’ without more context”

To fix that, we say:

“If the user only provides content, then assume Footer == EmptyView.”

This satisfies the compiler and lets us write:

StyledScreen {
    Text("Hello")
}

Without needing to manually pass an EmptyView.

This pattern is used inside SwiftUI itself — like in NavigationLink, Button, and Section — to support clean, overloaded initializers while keeping everything fully type-safe.

📦 TL;DR

Use Content: View + () -> Content to pass view content into your wrapper
Use @ViewBuilder if you want to support multiple children
Don’t try to store some View — use a closure instead
This unlocks powerful layout composition in SwiftUI

✨ Hope this helped someone else!
If you’ve used this pattern in an interesting way, or have a cool layout abstraction — let me know! I’d love to see what you’re building.

Fedora Silverblue Toolbox 101

Thu, 26 Dec 2024 06:14:43 -0500

I’m a total fan of immutable Operating System. the peace of mind, stability, and consistency they provide is invaluable but getting started can be a bit difficult, specially if you’re coming for more traditional operating systems (mutable ones).

With this post I aim to show my current workflow working on Fedora Silverblue, I am by no means an expert on Fedora SilverBlue. I want to share the way I use these systems and I hope to helps other by sharing my current understanding and workflows.

I intend to update this post with new workflows and ideas that helped me to create this new mental map for stateless operating systems. I wish you find this useful.

How to install VSCode

As a developer I find VSCode quite useful for a myriad of programming task, so a natural question arise: How do we install it on Fedora Silverblue?

Normally we would add the official Microsoft repository and install it using dnf but in Silverblue we don’t have access to dnf, instead we have rpm-ostree. rpm-ostree is a tool used to layer other software on top of your current Fedora image. But I find this not ideal since we will start to pollute our host OS, a better alternative is using Toolboxes.

toolbox is a tool used to create separated mutable containers where we can install our tools, normally used to install CLI software is also a great alternative to install our IDE.

The magic of toolbox is that it creates a separate mutable environment for us to install and use software that was not installed by default in our stateless operating system. This also apply to the repositories added to the system, each toolbox contains a separate list of repositories, independent of each other, even from the host.

Bear in mind these containers are not completely isolated from the host, as a consequence you cannot install mindlessly any unknown software thinking it’s isolated and safe to run. Please be cautious and treat the security inside these containers the same as you would with you local host system.

These toolboxes won’t pollute our main operating system and once we delete them, all the installed apps will be gone and our system will remain clean and stable. There is one catch, containers have by default access to our $HOME directory, so if the program creates configurations or files in this directory they will remain after the deletion of the container (you can delete these files if needed).

After this introduction let’s start with the installation of VSCode inside a toolbox.

Creating the toolbox

Let’s start by creating a new toolbox container, open a new terminal on the host OS and type the following:

To create the toolbox we enter:

You can give any name to your toolbox by replacing programming-box.

toolbox create programming-box

To enter the toolbox we type:

toolbox enter programming-box

The terminal prompt will add a small hexagon, this tell us we’re inside the toolbox.

Installing VSCode inside the toolbox

Now that we are inside the toolbox we can use is as a regular mutable OS, inside the toolbox we have access to dnf. This mean that the installation steps are the same as the official guide from Microsoft.

Inside the toolbox run the following commands to add the official repository and install the software.

Add the official repository by running this inside the toolbox.

sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
echo -e "[code]\nname=Visual Studio Code\nbaseurl=https://packages.microsoft.com/yumrepos/vscode\nenabled=1\ngpgcheck=1\ngpgkey=https://packages.microsoft.com/keys/microsoft.asc" | sudo tee /etc/yum.repos.d/vscode.repo > /dev/null

Update the repository list to get the newest software available.

dnf check-update

Install VSCode inside the toolbox.

sudo dnf install code # or code-insiders

Running VSCode

You may noticed that after installing the software you cannot find it in the installed apps, this is due to the nature of the isolated containers. The app is only accessible from inside the toolbox, so a system wide access is not possible.

If you want a system-wide access to the software, you could consider using a community-driven Flatpak or layering the app using rpm-ostree. I would not recommend layering unless is strictly necessary for your use case, and using a Flatpak may impose some extra steps to access the tools inside your toolboxes. Installing via dnf inside a toolbox seems like the best solution for most cases.

Flatpaks are the recommended way to install GUI apps in Fedora Silverblue but sometimes this way of working may create conflicts with other tools. For programming I find having everything I need (from toolchains to IDEs) inside a toolbox a hassle free solution.

To run VSCode, enter the toolbox container where the app is installed and run the following.

code

This will open the VSCode GUI and you can use it as usual.

You can install your programming toolchains inside the toolbox that contains VSCode and start using VSCode with these tools.

Considerations

You can follow this steps to install any tool you need. For example, GitHub CLI tools are not included by default in Fedora repositories, so we can add the repository and install the software in a similar fashion as we did with VSCode.

Other CLI tools that are part of Fedora repositories can be installed easily inside a toolbox by using sudo dnf install app_name.

Conclusion

Immutable Operating Systems are a great way to get rock solid and performant systems without worrying about updates or dependency problems. They container workflow is a great way to separate your tools and projects.

By using toolboxes you can add and configure your toolchains and programs as you would in a Mutable OS, with the adding benefit that once you’re done you can delete the changes and your system will stay clean and secure.

I wish these small how’s to helps you in your journey towards immutability.

101 Guide To Microcontroller Programming Inside Virtual Machines

Mon, 25 Nov 2024 03:21:54 +0000

Introduction

Hey everyone, I’m back with a new entry. This time, I’d like to guide you on how to create a simple hello world program for the ESP32-C6 inside a Virtual Machine.

Having all the toolchain inside a VM is a great way to unclutter your host machine. Programming inside a VM or containers for web development is quite common, but for microcontrollers, it’s a thing I don’t encounter that often.

What we need

For this tutorial, we will need:

Fedora Server 41 ARM
UTM
ESP32-C6
USB-C cable

Creating the Virtual Machine

Let’s start by creating the Virtual Machine. To archive this, you need a software capable of virtualizing your OS environment. Get UTM from the macOS Apple Store or directly from their website.

We also need to get the ISO we are going to use to create the VM. In this tutorial, we are using Fedora Server. Download the ARM ISO from here.

We will follow similar steps to install the OS similar to the ones on this post I made some time ago. We can follow along, with the difference that we are selecting Virtualize this time.

Once the OS is ready and SSH is working, let’s install the dependencies!

Installing dependencies inside the VM

Once you’re inside the VM, let’s run the following commands:

# Update the virtual OS
sudo dnf update -y
# Installing the needed software
sudo dnf install -y python3 python3-pip
# Install the udev needed to connect to the microcontrollers
curl -fsSL https://raw.githubusercontent.com/platformio/platformio-core/develop/platformio/assets/system/99-platformio-udev.rules | sudo tee /etc/udev/rules.d/99-platformio-udev.rules
# Install PlatformIO Core CLI
curl -fsSL -o get-platformio.py https://raw.githubusercontent.com/platformio/platformio-core-installer/master/get-platformio.py python3 get-platformio.py

We are using the PlatformIO CLI because the graphical interface installed by the plugin doesn’t work by default inside the VM. As a workaround, you could run pio home --host 0.0.0.0 --port 8008 to access the VSCode plugin GUI interface from your host browser.

Creating our basic project template

Once we have finished installing the tooling, we can start creating our hello world project.

As a first step, let’s activate the Python environment created by PlatformIO, to achieve that run:

# Activate the Python environment for PlatformIO
source ~/.platformio/penv/bin/activate

Then let’s create our project, navigate to the directory where you want to host the project, and run the following:

# Find the name of your microcontroller from the supported list, copy this name
pio boards | grep "YOUR_BOARD_NAME_HERE"
# We use pio to create the basic template project
pio project init --project-dir . --board "YOUR_BOARD_NAME_HERE"
# Open your project in VSCode
code .

As simple as that, we have our base project ready for us, now let’s do some code!

Programming the Hello World

Once you have opened the project, open the file called main.c located inside /src/ and add the following:

#include <stdio.h>
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"

void app_main() {
    while (true) {
        printf("Hello world\n");
        vTaskDelay(1000 / portTICK_PERIOD_MS);
    }
}

The ESP32-C6 is an ARM device, so we are using the Espressif framework instead of the Arduino framework. Check with your manufacturer the type of architecture your board uses.

This program will print to the serial bus the string Hello world\n every second.

We also need to specify the baud rate so that we can monitor the output correctly. Open the file called platformio.ini and append at the end the following line:

monitor_speed = 115200

With all this done, we are one step closer to seeing our awesome code working!

Compiling, flashing, and monitoring the microcontroller

Now it’s time to connect our board via USB to the VM:

Connect the board using USB to your host machine.
Open the VM window in UTM and, in the top right, press the USB plug icon and connect your board to the VM.
Check that the board is read by Fedora by running lsusb. You should see the same name that appeared on the UTM menu.

We can use the PlatformIO extension to make the next steps easier. Install the extension inside the VM. After reloading, you will see at the bottom left these 3 icons: check mark, right arrow, and electric plug.

Now let’s do the final steps!

Press the check mark to build the project.
Press the right arrow to flash your board (some boards may need to press some buttons on the board to activate the flash mode).
Press the electric plug icon to see the hello world string being sent to the serial monitor every second!

Congratulations, now you can start developing inside a VM for your microcontrollers.

Conclusion

Developing for microcontrollers inside a virtual machine not only helps keep your host system clean and organized but also creates a portable and reproducible development environment. By following this guide, you’ve set up a Fedora Server VM with all the necessary tools to program an ESP32-C6, created a basic “Hello World” project, and successfully flashed it to your board.

This approach combines the flexibility of modern tools like PlatformIO with the advantages of virtualization, providing a robust setup for any microcontroller project. Whether you’re just starting with embedded systems or looking for a cleaner workflow, this method proves that virtual machines are a practical solution for microcontroller development.

Now that you’ve mastered the basics, you can explore more complex projects, experiment with different boards, or even automate your setup further. Happy coding, and enjoy building your next microcontroller masterpiece!

Emulating Ubuntu Server X86_64 on macOS ARM64

Tue, 19 Nov 2024 07:31:29 +0000

ARM processors are becoming more ubiquitous thanks to the introduction of Apple Silicon and Qualcomm Snapdragon. These new processors offer great performance, silent operation, and all-day battery life. On the other hand, not all software is ported to this new architecture, so there could be cases when we need to run or program x86_64 devices.

To solve this problem, we have several tools at our disposal. In this post, let’s explore one solution to emulate and run x86_64 software.

What we need

An ARM64 machine. In our case, any Apple Silicon Mac would suffice.
UTM App.
Any x86_64 OS ISO. In our case, we’re installing Ubuntu Server 24.10.

Installing UTM

The piece of software that will be doing the work for us is called UTM. This is a macOS app that uses QEMU under the hood for virtualization and emulation.

We can get this software from their website or directly from the macOS App Store. I find the former option the best.

Choose the option that best suits your needs.

Creating the emulated Virtual Machine

Once we have UTM installed, let’s download the ISO of the operating system we want to emulate. In our case, Ubuntu Server 24.10.

Next, let’s open UTM and click on Create a New Virtual Machine. Here, we just need to select emulation, select the downloaded ISO, and configure the virtualized hardware. The process is quite straightforward.

In the last screen, you can view the summary of the VM. If this looks good to you, press Create and start the VM on the main UTM window.

This will start the normal installation of the selected OS using the provided ISO.

It’s a good idea to install OpenSSH for Ubuntu Server.

Configuring SSH

Once we are logged into our VM, we can start configuring SSH. This will allow us to access our VM from our host OS and connect via VSCode to start programming.

First, we need to create our SSH key. For that, we can follow the GitHub tutorial here.

Once we have the SSH key ready, we can connect to the VM.

The previously added SSH server list is located in ~/.ssh/config

On VM, get the IP address using ip a. The IP should look similar to inet 192.168.1.10/24 (we don’t need the ending /24 part, just the numbers).
On macOS terminal, shh into the vm machine using ssh username@vm_ip_address.

If your VM doesn’t have OpenSSL installed, run the following inside your VM sudo apt update && sudo apt install openssh-server && sudo systemctl start ssh && sudo systemctl enable ssh && sudo systemctl status ssh. This will install SSH, run it, enable it on startup, and check its current status.

Coding an ASM example with VSCode

Now it’s time to do some x86_64 ASM to verify that our system is working properly.

Open VSCode and click on the lower left blue icon ><.
Select + Add New SSH Host... and add your VM host parameters using this structure ssh username@vm_ip_address.
Select the configuration file to save your new host (the first option is okay).
Once the host is added, click on Connect. (On macOS, you may need to give VSCode permission to access the network, allow it, and press retry).
Wait for the VSCode server to install on the VM.

Now that everything is ready, let’s make a hello world!

Open VSCode integrated terminal (CMD + BACKTICK) and create a new file called hello.asm (use touch hello.asm to create the file and code hello.asm to open the file on VSCode) with the following content:

section .data
    msg db 'Hello, World!', 0xA  ; Message to print with newline
    len equ $ - msg              ; Length of the message

section .text
    global _start                ; Entry point for the program

_start:
    mov rax, 1                   ; sys_write system call (1)
    mov rdi, 1                   ; File descriptor (stdout)
    mov rsi, msg                 ; Address of the message
    mov rdx, len                 ; Length of the message
    syscall                      ; Make the system call

    mov rax, 60                  ; sys_exit system call (60)
    xor rdi, rdi                 ; Exit code 0
    syscall                      ; Make the system call

Before continuing, install the assembler using sudo apt install nasm.

Now let’s run the program!

# Assembling the code
nasm -f elf64 hello.asm -o hello.o
# Linking the code
ld hello.o -o hello
# Running the code
./hello

If all went well, you should see on the integrated terminal the text Hello, World!. Congratulations, your emulated x86_64 system is working correctly!

Conclusion

ARM processors have revolutionized the computing landscape with their efficiency, performance, and battery life, making them an excellent choice for modern devices. However, their growing adoption doesn’t eliminate the need to run or develop software for the x86_64 architecture. With tools like UTM, we can easily emulate x86_64 systems on ARM-based devices, such as Apple Silicon Macs.

This post guided you through the process of setting up UTM, creating a virtual machine, configuring SSH, and even running an x86_64 assembly program. By following these steps, you’ve not only learned how to emulate a different architecture but also created a functional environment for programming and development.

The flexibility of emulation tools bridges the gap between architectures, ensuring that developers can maintain productivity regardless of the hardware they are using. This workflow demonstrates how we can adapt to and leverage the best of both ARM and x86_64 worlds. Happy coding!

Working With Collections

Sun, 09 Jun 2024 12:17:07 +0000

Welcome to another installment of UIKit Learning! Today, we will dive into UICollectionView and explore how to use it effectively in your iOS apps.

A UICollectionView is a versatile and powerful component in UIKit that allows you to present a grid or list of items in a highly customizable layout. Whether you need a simple grid of images, a complex layout with multiple sections and headers, or dynamic, animated updates, UICollectionView provides the flexibility to create engaging user interfaces.

We’ll start with a minimal example and gradually build up to more complex scenarios, using the latest best practices and features, including diffable data sources (a favorite of mine).

Setting Up a Minimal UICollectionView

Creating the base view controller

As usual, we’re going to approach our development programmatically, so you can refer to my post on setting up a programmatic UIKit project.

Let’s start by creating a new file called ViewController.swift and add the following code.

import UIKit

class ViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
    }
}

This is the minimal view controller we are going to use to display the collection.

We are using this controller as the root ViewController for window in Scene Delegate.

Adding the collection to the view

Now it’s time to add our UICollectionView, inside the ViewController add the following property.

import UIKit

class ViewController: UIViewController {

    private var collectionView: UICollectionView! // add this

    override func viewDidLoad() {
        super.viewDidLoad()
    }
}

Next, let’s configure the collection, by adding and calling a configure function.

class ViewController: UIViewController {

    private var collectionView: UICollectionView!

    override func viewDidLoad() {
        super.viewDidLoad()
        setupCollectionView() // 2. call the function
    }

    // 1. create this function
    func setupCollectionView() {
        // Creating layout
        let layout = UICollectionViewFlowLayout()
        layout.itemSize = CGSize(width: 100, height: 100)
        layout.sectionInset = UIEdgeInsets(top: 10, left: 10, bottom: 10, right: 10)
        layout.scrollDirection = .horizontal
        
        // creating actual collection
        collectionView = UICollectionView(frame: .zero, collectionViewLayout: layout)
        collectionView.backgroundColor = .darkGray
        
        // adding to view
        view.addSubview(collectionView)
        
        // adding constraints
        collectionView.translatesAutoresizingMaskIntoConstraints = false
        NSLayoutConstraint.activate([
            collectionView.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor),
            collectionView.bottomAnchor.constraint(equalTo: view.safeAreaLayoutGuide.bottomAnchor),
            collectionView.leadingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.leadingAnchor),
            collectionView.trailingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.trailingAnchor)
        ])
    }
}

This functions creates the actual collection and the layout for the collection.

Why we need a `collectionViewLayout`

When working with UICollectionView, you need to provide a layout object that determines how the items in the collection view are arranged.

UICollectionViewFlowLayout is a concrete layout object that organizes items into a grid with optional header and footer views for each section. It’s the most commonly used layout class because it provides a lot of built-in functionality that suits many common use cases.

UICollectionView does not come with a default layout. You must provide a layout object for it to work. UICollectionViewFlowLayout is the default layout provided by UIKit that supports basic grid-like arrangements.

Adding the data source

Our collection is already created with a basic layout but we need to have actual data to make it display any information, to solve this problem we could implement the UICollectionViewDataSource but I prefer to use a diffable data source.

What’s a diffable data source

A diffable data source is a modern way to manage the data in your collection views and table views. It makes it easier to update your UI when your data changes, ensuring smooth and efficient updates without having to manually calculate the differences between the old and new data.

In simple terms, you provide the entire set of new data to the data source using a snapshot, then the data source internally manages the update without any intervention from the user. A snapshot is like a picture of your data at a particular moment.

Creating the diffable data source

Inside the class let’s create a new property called dataSource.

class ViewController: UIViewController {

    private var collectionView: UICollectionView!
    private var dataSource: UICollectionViewDiffableDataSource<Int, String>! // add this

    // More code ...

The provided types are for the section identifier and the actual data our collection will display, in our case we are using Int as the section identifier and String as the data we want to display. We could use any custom types as long as they are valid for the role.

Configuring the data source

The next step is crucial for our collection to work, we need to configure how the cells will be updated and we need to register the collection in our data source.

Let’s add the following function to our class

class ViewController: UIViewController {
    // more code ...

    override func viewDidLoad() {
        super.viewDidLoad()
        setupView()
        setupCollectionView()
        setupDataSource() // 2. call the function
    }

    // 1. create the function
    private func setupDataSource() {
            // configuring cell with diffable data source
            collectionView.register(CustomCollectionCell.self, forCellWithReuseIdentifier: CustomCollectionCell.name)
            
            // configure cell update
            dataSource = UICollectionViewDiffableDataSource(collectionView: collectionView) { collectionView, indexPath, name in
                guard let cell = collectionView.dequeueReusableCell(withReuseIdentifier: CustomCollectionCell.name, for: indexPath) as? CustomCollectionCell else { fatalError("Unable to dequeue CustomCollectionCell") }
                cell.backgroundColor = .orange
                cell.update(with: name)
                return cell
            }
        }

        // more code ...
}

First, we are registering the cell we are going to use in our collection.

Next, creating the diffable data source and passing the reference to our collection. By doing this we are telling our data source the collection it will be managing.

The closure we are passing tells the data source how the update of each cell will be managed. Inside the closure we have access to the actual collection, the indexPath of the current element and the actual data element we want to display inside the cell.

By doing these simple steps we have our collection connected with its data source.

Creating the snapshot

Finally we need a way to update the collection data, to do this let’s add a new function that will handle the snapshot.

class ViewController: UIViewController {
    // more code ...

    // updating the diffable with new data
    func updateSnapshot(with data: [String]) {
        var snapshot = NSDiffableDataSourceSnapshot<Int, String>()
        snapshot.appendSections([0])
        snapshot.appendItems(data) // Adding more items
        dataSource.apply(snapshot, animatingDifferences: true)
    }

    // more code ...
}

This function creates a snapshot and applies the new data to the underlying system that will automatically updates the collection for us.

If your collection wants to show different data, you need to update the snapshot and the data source to be compatible. The data source and snapshot must be of the same type to work.

Creating a custom cell

By default, collection cell doesn’t have text or other elements, so let’s create a custom cell we can reuse in our collection. You already register this cell for the collection and you’re already using it in the data source. It’s a simple cell that only shows a centered label.

final class CustomCollectionCell: UICollectionViewCell {
    static let name = "CustomCollectionCell"
    
    private var label: UILabel!
    
    override init(frame: CGRect) {
        super.init(frame: frame)
        setupLabel()
    }
    
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    func update(with data: String) {
        label.text = data
    }
    
    private func setupLabel() {
        label = UILabel()
        label.textAlignment = .center
        
        self.contentView.addSubview(label) // remember to add it to the contentView
        
        label.translatesAutoresizingMaskIntoConstraints = false
        NSLayoutConstraint.activate([
            label.topAnchor.constraint(equalTo: contentView.topAnchor), // we are referring to contentView not view
            label.leadingAnchor.constraint(equalTo: contentView.leadingAnchor), // we are referring to contentView not view
            label.trailingAnchor.constraint(equalTo: contentView.trailingAnchor), // we are referring to contentView not view
            label.bottomAnchor.constraint(equalTo: contentView.bottomAnchor), // we are referring to contentView not view
        ])
    }
}

In cells you need to add sub elements to the contentView not the view.

Testing the collection

Let’s test the collection. We need some data to show, here is some data you can add to your class.

class ViewController: UIViewController {
    
    private var collectionView: UICollectionView!
    private var dataSource: UICollectionViewDiffableDataSource<Int, String>!
    
    private var mockData: [String] {
        [
            "Bulbasaur", "Ivysaur", "Venusaur", "Charmander", "Charmeleon", "Charizard",
            "Squirtle", "Wartortle", "Blastoise", "Caterpie", "Metapod", "Butterfree",
            "Weedle", "Kakuna", "Beedrill", "Pidgey", "Pidgeotto", "Pidgeot",
            "Rattata", "Raticate", "Spearow", "Fearow", "Ekans", "Arbok",
            "Pikachu", "Raichu", "Sandshrew", "Sandslash", "Nidoran♀", "Nidorina",
            "Nidoqueen", "Nidoran♂", "Nidorino", "Nidoking", "Clefairy", "Clefable",
            "Vulpix", "Ninetales", "Jigglypuff", "Wigglytuff", "Zubat", "Golbat",
            "Oddish", "Gloom", "Vileplume", "Paras", "Parasect", "Venonat", "Venomoth",
            "Diglett", "Dugtrio", "Meowth", "Persian", "Psyduck", "Golduck",
            "Mankey", "Primeape", "Growlithe", "Arcanine", "Poliwag", "Poliwhirl",
            "Poliwrath", "Abra", "Kadabra", "Alakazam", "Machop", "Machoke", "Machamp",
            "Bellsprout", "Weepinbell", "Victreebel", "Tentacool", "Tentacruel",
            "Geodude", "Graveler", "Golem", "Ponyta", "Rapidash", "Slowpoke",
            "Slowbro", "Magnemite", "Magneton", "Farfetch'd", "Doduo", "Dodrio",
            "Seel", "Dewgong", "Grimer", "Muk", "Shellder", "Cloyster",
            "Gastly", "Haunter", "Gengar", "Onix", "Drowzee", "Hypno",
            "Krabby", "Kingler", "Voltorb", "Electrode", "Exeggcute", "Exeggutor",
            "Cubone", "Marowak", "Hitmonlee", "Hitmonchan", "Lickitung", "Koffing",
            "Weezing", "Rhyhorn", "Rhydon", "Chansey", "Tangela", "Kangaskhan",
            "Horsea", "Seadra", "Goldeen", "Seaking", "Staryu", "Starmie",
            "Mr. Mime", "Scyther", "Jynx", "Electabuzz", "Magmar", "Pinsir",
            "Tauros", "Magikarp", "Gyarados", "Lapras", "Ditto", "Eevee",
            "Vaporeon", "Jolteon", "Flareon", "Porygon", "Omanyte", "Omastar",
            "Kabuto", "Kabutops", "Aerodactyl", "Snorlax", "Articuno", "Zapdos",
            "Moltres", "Dratini", "Dragonair", "Dragonite", "Mewtwo", "Mew"
        ]
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        setupView()
        setupCollectionView()
        setupDataSource()
        updateSnapshot(with: mockData) // call the update and pass the data
    }

    // more code ...

Pass the data to the snapshot and run the code, you should see your data in the collection.

It should looks and behaves like the video above.

Conclusion

Congratulations! You’ve successfully set up a UICollectionView using a diffable data source and a custom cell, all programmatically. By following this tutorial, you now understand the basics of UICollectionView and how to leverage diffable data sources to manage your data efficiently. This approach not only simplifies your code but also ensures smooth and animated updates to your collection view.

In this post, we’ve covered:

Creating a minimal view controller and adding a UICollectionView to it.
Setting up a layout using UICollectionViewFlowLayout.
Understanding the importance of a layout object for UICollectionView.
Implementing a diffable data source to manage and update your collection view data.
Creating and registering a custom cell to display text within your collection view.

With these foundational concepts in place, you’re well-equipped to build more complex and dynamic collection views in your iOS apps. Whether you’re displaying a grid of images, a list of text items, or something entirely custom, UICollectionView and diffable data sources provide the flexibility and power you need.

Stay tuned for more in our UIKit Learning series, where we’ll dive deeper into advanced topics and best practices. Happy coding!

Apendix

Here is the full code.

import UIKit

class ViewController: UIViewController {
    
    private var collectionView: UICollectionView!
    private var dataSource: UICollectionViewDiffableDataSource<Int, String>!
    
    private var mockData: [String] {
        [
            "Bulbasaur", "Ivysaur", "Venusaur", "Charmander", "Charmeleon", "Charizard",
            "Squirtle", "Wartortle", "Blastoise", "Caterpie", "Metapod", "Butterfree",
            "Weedle", "Kakuna", "Beedrill", "Pidgey", "Pidgeotto", "Pidgeot",
            "Rattata", "Raticate", "Spearow", "Fearow", "Ekans", "Arbok",
            "Pikachu", "Raichu", "Sandshrew", "Sandslash", "Nidoran♀", "Nidorina",
            "Nidoqueen", "Nidoran♂", "Nidorino", "Nidoking", "Clefairy", "Clefable",
            "Vulpix", "Ninetales", "Jigglypuff", "Wigglytuff", "Zubat", "Golbat",
            "Oddish", "Gloom", "Vileplume", "Paras", "Parasect", "Venonat", "Venomoth",
            "Diglett", "Dugtrio", "Meowth", "Persian", "Psyduck", "Golduck",
            "Mankey", "Primeape", "Growlithe", "Arcanine", "Poliwag", "Poliwhirl",
            "Poliwrath", "Abra", "Kadabra", "Alakazam", "Machop", "Machoke", "Machamp",
            "Bellsprout", "Weepinbell", "Victreebel", "Tentacool", "Tentacruel",
            "Geodude", "Graveler", "Golem", "Ponyta", "Rapidash", "Slowpoke",
            "Slowbro", "Magnemite", "Magneton", "Farfetch'd", "Doduo", "Dodrio",
            "Seel", "Dewgong", "Grimer", "Muk", "Shellder", "Cloyster",
            "Gastly", "Haunter", "Gengar", "Onix", "Drowzee", "Hypno",
            "Krabby", "Kingler", "Voltorb", "Electrode", "Exeggcute", "Exeggutor",
            "Cubone", "Marowak", "Hitmonlee", "Hitmonchan", "Lickitung", "Koffing",
            "Weezing", "Rhyhorn", "Rhydon", "Chansey", "Tangela", "Kangaskhan",
            "Horsea", "Seadra", "Goldeen", "Seaking", "Staryu", "Starmie",
            "Mr. Mime", "Scyther", "Jynx", "Electabuzz", "Magmar", "Pinsir",
            "Tauros", "Magikarp", "Gyarados", "Lapras", "Ditto", "Eevee",
            "Vaporeon", "Jolteon", "Flareon", "Porygon", "Omanyte", "Omastar",
            "Kabuto", "Kabutops", "Aerodactyl", "Snorlax", "Articuno", "Zapdos",
            "Moltres", "Dratini", "Dragonair", "Dragonite", "Mewtwo", "Mew"
        ]
    }
    
    override func viewDidLoad() {
        super.viewDidLoad()
        setupView()
        setupCollectionView()
        setupDataSource()
        updateSnapshot(with: mockData)
    }
    
    
}

private extension ViewController {
    
    func setupView() {
        view.backgroundColor = .systemBackground
    }
    
    func setupCollectionView() {
        // Creating layout
        let layout = UICollectionViewFlowLayout()
        layout.itemSize = CGSize(width: 100, height: 100)
        layout.sectionInset = UIEdgeInsets(top: 10, left: 10, bottom: 10, right: 10)
        layout.scrollDirection = .horizontal
        
        // creating actual collection
        collectionView = UICollectionView(frame: .zero, collectionViewLayout: layout)
        collectionView.backgroundColor = .darkGray
        
        // adding to view
        view.addSubview(collectionView)
        
        // adding constraints
        collectionView.translatesAutoresizingMaskIntoConstraints = false
        NSLayoutConstraint.activate([
            collectionView.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor),
            collectionView.bottomAnchor.constraint(equalTo: view.safeAreaLayoutGuide.bottomAnchor),
            collectionView.leadingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.leadingAnchor),
            collectionView.trailingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.trailingAnchor)
        ])
    }
    
    func setupDataSource() {
        // registering cell to the collection
        collectionView.register(CustomCollectionCell.self, forCellWithReuseIdentifier: CustomCollectionCell.name)
        
        // creating and configuring diffable data source
        dataSource = UICollectionViewDiffableDataSource(collectionView: collectionView) { collectionView, indexPath, name in
            guard let cell = collectionView.dequeueReusableCell(withReuseIdentifier: CustomCollectionCell.name, for: indexPath) as? CustomCollectionCell else { fatalError("Unable to dequeue CustomCollectionCell") }
            cell.backgroundColor = .orange
            cell.update(with: name)
            return cell
        }
    }
    
    // updating the diffable with new data
    func updateSnapshot(with data: [String]) {
        var snapshot = NSDiffableDataSourceSnapshot<Int, String>()
        snapshot.appendSections([0])
        snapshot.appendItems(data) // Adding more items
        dataSource.apply(snapshot, animatingDifferences: true)
    }
}

final class CustomCollectionCell: UICollectionViewCell {
    static let name = "CustomCollectionCell"
    
    private var label: UILabel!
    
    override init(frame: CGRect) {
        super.init(frame: frame)
        setupLabel()
    }
    
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    func update(with data: String) {
        label.text = data
    }
    
    private func setupLabel() {
        label = UILabel()
        label.textAlignment = .center
        
        self.contentView.addSubview(label) // remember to add it to the contentView
        
        label.translatesAutoresizingMaskIntoConstraints = false
        NSLayoutConstraint.activate([
            label.topAnchor.constraint(equalTo: contentView.topAnchor), // we are referring to contentView not view
            label.leadingAnchor.constraint(equalTo: contentView.leadingAnchor), // we are referring to contentView not view
            label.trailingAnchor.constraint(equalTo: contentView.trailingAnchor), // we are referring to contentView not view
            label.bottomAnchor.constraint(equalTo: contentView.bottomAnchor), // we are referring to contentView not view
        ])
    }
}

Configuring a Programmatic UIKit Project

Sun, 26 May 2024 22:35:31 +0000

In some projects, you might not want to use Storyboards or XIBs for various reasons, such as greater flexibility and control over your views, better version control, or simply personal preference. If that’s your case, this post will guide you through the basic steps to configure a Storyboard project to work with UIKit programmatically.

Step-by-Step Guide

I’m using Xcode 15.4, the graphical user interface (GUI) may change in the future causing some images to be outdated or some steps to be different.

1. Create a New Project

Start by creating a new iOS project in Xcode:

Open Xcode and select “Create a new Xcode project”.

Choose the “App” template under the iOS tab.

Enter your project details (Product Name, Team, etc.) and make sure “Storyboard” is selected for the User Interface.

Save your project wherever you like and optionally tick the “Create Git repository on my Mac” to initialize a local git repository for this project.

2. Remove the Main Storyboard

Next, we’ll remove the storyboard file and configure the project to work without it:

Delete Main.storyboard:
- In the Project Navigator, locate Main.storyboard.
- Right-click on Main.storyboard and select “Delete”. Choose “Move to Trash” to remove it completely.

Remove Storyboard References from Info.plist:
- Open Info.plist.
- Delete the Main storyboard file base name key (usually named Storyboard Name).

Remove Storyboard References from Build Settings:
- Select your project in the Project Navigator.
- Select your app target.
- Go to the “Build Settings” tab.
- Search for Main and make sure there are no references to Main.

3. Set the Root View Controller Programmatically

Depending on whether your project uses a SceneDelegate (iOS 13 and later) or not, you’ll set the root view controller differently.

Using AppDelegate (iOS 12 and earlier or single-window apps)

Open AppDelegate.swift.

In the application(_:didFinishLaunchingWithOptions:) method, add the following code to set up the window and root view controller:

import UIKit

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {

    var window: UIWindow?

    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        window = UIWindow(frame: UIScreen.main.bounds)

        let initialViewController = YourInitialViewController()
        window?.rootViewController = UINavigationController(rootViewController: initialViewController)
        window?.makeKeyAndVisible()

        return true
    }
}

Using SceneDelegate (iOS 13 and later)

Open SceneDelegate.swift.

In the scene(_:willConnectTo:options:) method, add the following code to set up the window and root view controller:

import UIKit

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var window: UIWindow?

    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        guard let windowScene = (scene as? UIWindowScene) else { return }

        window = UIWindow(windowScene: windowScene)
        let initialViewController = YourInitialViewController()
        window?.rootViewController = UINavigationController(rootViewController: initialViewController)
        window?.makeKeyAndVisible()
    }
}

In these files, you can do more complex setups like configuring routers for navigation, setting up a tab bar controller, or managing a split view controller, depending on your app’s needs.

4. Create Your Initial View Controller

Create a new Swift file for your initial view controller:

In the Project Navigator, right-click on the project folder and select “New File”.
Choose “Swift File” and name it YourInitialViewController.swift.

Implement your view controller as follows:

import UIKit

class YourInitialViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()

        // Set the background color to visually verify the setup
        view.backgroundColor = .white

        // Additional setup for your view controller
    }
}

5. Run the Project

Build and run your project. You should see a white screen, indicating that your initial view controller is being presented programmatically.

Conclusion

By following these steps, you’ve successfully configured your Storyboard-based project to work programmatically with UIKit. This setup provides you with greater flexibility and control over your views, and you can now add your UI elements directly in code.

Happy coding!

Programmatic Tab Bar

Sun, 26 May 2024 22:17:06 +0000

Tabs bars are one the most recognizable UI elements for an iOS apps. We can find this element in build in apps like Phone, Photos, Music, AppStore, and many more.

Lucky for us, this element is quite easy to use, and in this tutorial, we’ll learn how to create a tab bar programmatically using UIKit. Let’s start!

Simple example

Let’s start by configuring our project to allow us to instantiate our views programmatically. You can follow this guide.

1. Create the Tab Bar class

I prefer to have a separate class that handle all the Tab Bar related responsibilities, so let’s create a new file called TabBarViewController.swift and add the following code.

import UIKit

final class TabBarController: UITabBarController {
    override func viewDidLoad() {
        super.viewDidLoad()
    }
}

This is the minimum code we need to have a working tab bar.

2. Adding the tab bar to the app

Now we can instantiate this as we would do with a UINavigationController.

Open SceneDelegate.swift and and update the willConnectTo method as follows:

func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        guard let windowScene = (scene as? UIWindowScene) else { return }
        window = UIWindow(windowScene: windowScene)
        window?.rootViewController = TabBarController()
        window?.makeKeyAndVisible()
    }

We are assigning the new Tab Bar as the window root view controller. This will present this as the first element in our screen.

Now run the app, you should see an empty tab bar in the screen.

3. Creating the View Controllers to show

We need to have some view controllers to show on the screen. Let’s make two simple dummy ones.

Create two new files, AViewController.swift and BViewController.swift and add the following code:

// A View Controller
import UIKit

final class AViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        view.backgroundColor = .yellow
    }
}

// B View Controller
import UIKit

final class BViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        view.backgroundColor = .orange
    }
}

These two view controllers are quite simple, with the only difference being their background color.

4. Presenting the View Controllers in the Tab Bar

Each UIViewController has a property called tabBarItem to which we can assign the tab bar item it will display in a tab bar.

Open the TabBarController.swift and update the code as follows:

import UIKit

enum TabBarTag: Int {
    case a, b
}

final class TabBarController: UITabBarController {
    override func viewDidLoad() {
        super.viewDidLoad()
        setupTabBar() // 3. Call the new function
    }
}

// 1 .Add this private extension
private extension TabBarController {
    // 2. Add this function that will instantiate the ViewControllers and assign their tab bar items
    func setupTabBar() {
        let aViewController = AViewController()
        // Adding the tab bar item to show in the tab bar for AViewController
        aViewController.tabBarItem = UITabBarItem(
            title: "A",
            image: UIImage(systemName: "1.lane"),
            tag: TabBarTag.a.hashValue
        )
        
        let bViewController = BViewController()
        // Adding the tab bar item to show in the tab bar for BViewController
        bViewController.tabBarItem = UITabBarItem(
            title: "B",
            image: UIImage(systemName: "2.lane"),
            tag: TabBarTag.b.hashValue
        )
        
        // UITabBarController contains an array of the view controllers that will be showing in the screen
        self.viewControllers = [aViewController, bViewController]
    }
}

I’m using an enum for the tag, so that we can refer to each tab bar item easily in the future for other parts of our app.

5. Run the app

Now run the app and see the tab bar in action.

With this little code, we have a simple tab bar implemented in our app.

Advanced Usage

Under development …

VSCode Dev Container Configurations

Tue, 21 May 2024 00:46:23 +0000

VSCode + Dev Containers are a great way to create custom environments without modifying our actual system.

They provide a consistent development environment, ensure dependencies are managed correctly, and make it easy to share setups with your team.

Here are some configurations you can use to create them.

Vapor

{
    "name": "Swift",
    "image": "swift:latest",
    "features": {
        "ghcr.io/devcontainers/features/common-utils:2": {
            "installZsh": "false",
            "username": "vscode",
            "userUid": "1000",
            "userGid": "1000",
            "upgradePackages": "false"
        },
        "ghcr.io/devcontainers/features/git:1": {
            "version": "os-provided",
            "ppa": "false"
        }
    },
    "runArgs": [
        "--cap-add=SYS_PTRACE",
        "--security-opt",
        "seccomp=unconfined"
    ],
    "customizations": {
        "vscode": {
            "settings": {
                "lldb.library": "/usr/lib/liblldb.so"
            },
            "extensions": [
                "sswg.swift-lang",
                "streetsidesoftware.code-spell-checker"
            ]
        }
    },
    "remoteUser": "root",
    "postCreateCommand": "apt-get update && apt-get install -y libssl-dev libsqlite3-dev zlib1g-dev make && rm -rf toolbox && git clone https://github.com/vapor/toolbox.git && cd toolbox && make install && cd .. && rm -rf toolbox"
}

Scala

{
	"name": "Scala",
	"image": "mcr.microsoft.com/devcontainers/java:1-21-bullseye",

	"features": {
		"ghcr.io/devcontainers/features/java:1": {
			"version": "none",
			"installMaven": "false",
			"installGradle": "false"
		}
	},
	"postCreateCommand": "curl -fL https://github.com/VirtusLab/coursier-m1/releases/latest/download/cs-aarch64-pc-linux.gz | gzip -d > cs && chmod +x cs && yes | ./cs setup && echo 'before start run source ~/.profile'",

	"customizations": {
		"vscode": {
			"extensions": [
				"scala-lang.scala",
				"streetsidesoftware.code-spell-checker"
			]
		}
	}
}

Delegate Pattern in Swift

Thu, 16 May 2024 22:16:34 +0000

Lately, I’ve been writing a lot about UIKit and I noticed I haven’t covered the delegate pattern.

This pattern is not exclusive to UIKit but it’s quite used in this framework.

In this post, we’ll dive into the Delegation Pattern, a fundamental design pattern in iOS development that helps in creating a well-structured codebase.

What is the Delegation Pattern?

The Delegation Pattern is a design pattern where one object (the delegator) hands off (or delegates) some of its responsibilities to another object (the delegate). This allows for a clear separation of concerns and makes it easier to manage and extend code.

By responsibilities, we mean functions or actions the object needs to perform but doesn’t want to implement itself because it’s not directly responsible. This allows for a clear separation of concerns and makes it easier to manage and extend code.

Why Use the Delegation Pattern?

Separation of Concerns: It helps in dividing the functionality into different classes, making the code more modular and easier to manage.
Reusability: Delegate objects can be reused across different contexts and components.
Flexibility: It provides a way to customize or extend the behavior of a class without modifying its source code.

How to Implement the Delegation Pattern in Swift

Let’s go through a practical example to illustrate the Delegation Pattern.

Step 1: Define the Protocol

First, define a protocol that outlines the responsibilities to be delegated.

protocol CustomDelegate: AnyObject {
    func someDelegatedFunction()
    func someOtherDelegatedFunction(withString: String)
}

Here, we are specifying the actions our object needs to perform but are not implemented by the object itself.

We can also pass information back to the delegate object. This can be as simple as one string or as complex as the whole object.

Step 2: Create the Delegator

Next, create the delegator class, which will hold a reference to the delegate and call its methods when appropriate.

class SomeObject {
    weak var delegate: CustomDelegate?

    func someAction() {
        delegate?.someDelegatedFunction()
    }

    func someOtherAction() {
        delegate?.someOtherDelegatedFunction(withString: "Some data being passed")
    }
}

It’s important to mark the delegate property as weak to avoid retain cycles and memory leaks.

This is a minimum example. In most cases, the object will also contain its own logic and only some parts will be delegated.

Step 3: Implement the Delegate

Finally, implement the delegate in a class that will handle the delegated tasks.

class OtherClassThatWantsToPerformTheActions {
    // Creating the object that needs the delegate
    // This can also be injected from a different object if we don't want to create it here.
    let someObject = SomeObject() 

    init() {
        // Assigning this class as the delegate object,
        // now someObject can call the implemented methods in this class when needed.
        someObject.delegate = self 
    }
}

// Implementing the delegate methods needed to be a valid delegate
extension OtherClassThatWantsToPerformTheActions: CustomDelegate {
    func someDelegatedFunction() {
        // Logic implemented when the method is called by the delegator 
    }

    func someOtherDelegatedFunction(withString: String) {
        // Logic implemented when the method is called by the delegator,
        // In this case, the delegator is passing back some information we may need to perform the action.
    }
}

Here are two crucial steps: we need to assign to SomeObject the class that will handle the delegate, and we need to implement the delegate protocol in the delegate class so that the assigned object can respond to the actions of SomeObject.

You’re done! Now, when you need to perform a delegated action, the responsible object will be called and perform the action in place of our delegator.

Example with UITableView

Let’s see an example involving UITableView, which frequently uses the delegation pattern.

With objects managed by UIKit we only need to implement the step 3 of the previous example (for our custom objects we need to implement all steps ourselves).

We will make our ViewController to act as the delegate for the UITableView.

import UIKit

class ViewController: UIViewController {
    
    // Creating the TableView that needs the delegate for certain actions
    let tableView = UITableView()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        // Set up the table view
        tableView.frame = view.bounds
        tableView.delegate = self // assigning this object as the delegate
        tableView.dataSource = self
        tableView.register(UITableViewCell.self, forCellReuseIdentifier: "cell")
        view.addSubview(tableView)
    }
}

// MARK: - UITableViewDataSource
extension ViewController: UITableViewDataSource {
    
    // Return the number of rows in the section
    func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        return 10 // Example number of rows
    }
    
    // Configure and return the cell for the given index path
    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        let cell = tableView.dequeueReusableCell(withIdentifier: "cell", for: indexPath)
        cell.textLabel?.text = "Row \(indexPath.row)"
        return cell
    }
}

// MARK: - UITableViewDelegate
extension ViewController: UITableViewDelegate {
    
    // Handle row selection
    // this method is defined in the delegate protocol for UITableView
    func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
        print("Selected row \(indexPath.row)")
        tableView.deselectRow(at: indexPath, animated: true)
    }
}

Both the delegate and the data source follow the delegation pattern, but the delegate manages user interactions and appearance, while the data source provides the data to be displayed.

In this example:

Define the Protocols: We use the built-in UITableViewDelegate and UITableViewDataSource protocols.
Create the Delegator: The UITableView instance is created and set up in the viewDidLoad method. It is configured to use the ViewController as its delegate and data source.
Implement the Delegate and Data Source: The ViewController class conforms to the UITableViewDelegate and UITableViewDataSource protocols. It implements required methods such as tableView(_:numberOfRowsInSection:) and tableView(_:cellForRowAt:) for the data source, and tableView(_:didSelectRowAt:) for the delegate.

Conclusion

The Delegation Pattern is a fundamental design pattern in iOS development that allows for a clear separation of concerns, making your code more modular and easier to manage. By delegating responsibilities, you can create reusable and flexible components that improve the maintainability of your codebase.

In this post, we explored the Delegation Pattern, learned how to implement it with a simple custom example, and saw how it is applied in a real-world scenario with UITableView.

Understanding and utilizing this pattern will help you create well-structured and efficient code, ensuring that your iOS applications remain robust and scalable. As always, following best practices and leveraging powerful design patterns like delegation will lead to better, more maintainable applications.

Happy coding!

Builder Pattern to Simplify UIKit Object Creation

Wed, 15 May 2024 20:52:02 +0000

One common issue with programmatic UIKit development is dealing with the creation and configuration of UI objects. Configuring UI elements in our code can be cumbersome and hard to synchronize their behavior and style across several screens.

By using the Builder Pattern, we can centralize the creation and configuration of these objects. This simplifies our codebase and decouples the creation of UI objects from our views.

What is the Builder Pattern?

The Builder Pattern is a creational design pattern that allows us to construct complex objects step by step. It separates the construction of a complex object from its representation, allowing the same construction process to create different representations.

I don’t want to focus on the formal definition too much (you can find a lot of great articles on the topic like this one). Instead, I prefer to show you a working example, so let’s go for it.

Practical Example

Let’s start with the builder. In this example, I want a way to configure a button with some defaults, so I can rely on these defaults to simplify further and accept modifications for specific cases.

Applying the Builder Pattern to UIKit

Let’s see how we can use the Builder Pattern to create and configure a UIButton in UIKit.

In a Storyboard project let’s create a new file ButtonBuilder.swift and add the following code.

class ButtonBuilder {
    private var button = UIButton(type: .system)
    
    func setTamic(_ active: Bool) -> Self {
        button.translatesAutoresizingMaskIntoConstraints = active
        return self
    }

    func setTitle(_ title: String) -> Self {
        button.setTitle(title, for: .normal)
        return self
    }

    func setTitleColor(_ color: UIColor) -> Self {
        button.setTitleColor(color, for: .normal)
        return self
    }

    func setBackgroundColor(_ color: UIColor) -> Self {
        button.backgroundColor = color
        return self
    }

    func setCornerRadius(_ radius: CGFloat) -> Self {
        button.layer.cornerRadius = radius
        return self
    }

    func setAction(_ action: @escaping () -> Void) -> Self {
        button.addAction(UIAction {_ in
            action()
        }, for: .touchUpInside)
        return self
    }

    func build() -> UIButton {
        return button
    }
}

They key point to implement a builder is that we have configuration functions that return the builder itself. These functions can be chained with other configuration functions as needed. Once we are done with the configuration, we call the build function to return the actual object configured with the selected options.

Using the builder inside a ViewController

To use our builder let’s create a new file called TestViewController.swift and add the following code.

import UIKit


class ExampleViewController: UIViewController {
    private lazy var button = ButtonBuilder()
        .setTamic(false)
        .setTitle("Example")
        .setAction {
            print("Button pressed")
        }
        .setBackgroundColor(.cyan)
        .build()
    
    override func viewDidLoad() {
        view.addSubview(button)
        NSLayoutConstraint.activate([
            button.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            button.centerYAnchor.constraint(equalTo: view.centerYAnchor)
        ])
    }
}

#Preview {
    ExampleVC()
}

The final result resembles the simple and declarative style of SwiftUI!

Remember to use [weak self] if you’re capturing self or any property of self in your button action.

Test the button action in the Canvas and enjoy!

Considerations

Sometimes the object cannot be created before we have all the properties or dependencies. In these cases, we can gather the dependencies or properties and only create the object in the build function, where we inject the desired properties.

Here is an example for a Label to demonstrate this.

class LabelBuilder {
    private var text: String = ""
    private var numberOfLines: Int = 0
    private var tamic: Bool = false
    
    func withText(_ text: String) -> Self {
        self.text = text
        return self
    }
    
    func withNumberOfLines(_ number: Int) -> Self {
        self.numberOfLines = number
        return self
    }
    
    func withAutoLayout(_ tamic: Bool) -> Self {
        self.tamic = tamic
        return self
    }
    
    func build() -> UILabel {
        let label = UILabel()
        label.text = text
        label.numberOfLines = numberOfLines
        label.translatesAutoresizingMaskIntoConstraints = tamic
        return label
    }
}

In this example, we define the properties beforehand and assign default values that make sense for our final object. Changes to these defaults are optional and can be made using the configuration methods.

Conclusion

By leveraging the Builder Pattern, we can streamline the process of creating and configuring UI elements in UIKit. This approach not only makes our codebase more manageable but also decouples the configuration from the views, enhancing maintainability and reusability. Whether you are setting up a simple button or a more complex object, the Builder Pattern provides a flexible and clean solution.

I hope this guide helps you simplify your UIKit development. Give it a try in your next project and see the difference it can make!

Creating an MVVM Counter In UIKit

Mon, 13 May 2024 22:55:14 +0000

One of the standout features of SwiftUI is its reactive paradigm, which seamlessly updates views as data changes. This powerful approach isn’t confined to SwiftUI alone; it can also be harnessed in UIKit through the use of the Combine framework, and starting with iOS 17, through the new Observation framework.

In this post, we’re going to explore using MVVM with UIKit, leveraging Combine to achieve reactive behaviors similar to SwiftUI. I hope you find this information useful and that it helps you improve the way you create and think about your applications. Join me as we dive into making your UIKit apps more responsive and robust.

What is MVVM?

MVVM (Model-View-ViewModel) is a popular architectural pattern that divides the application into three interconnected components. This separation aids in managing complexities and enhances the maintainability of the application.

The Model includes both the data and the business logic specific to the application. It represents the actual data content and the operations that can manipulate this data.
The ViewModel acts as an intermediary between the Model and the View. It handles most of the view logic, transforming data from the Model in a way that the View can easily present. The ViewModel also responds to user input and view-related logic, thus abstracting the View from the Model. A key component of the ViewModel is its reactivity; it notifies the View of changes to the data automatically, facilitating a dynamic user experience.
The View is responsible for presenting the data provided by the ViewModel in a user-friendly format. It focuses purely on the visual representation, relying on the ViewModel to manage any state or processing of data. The View interacts with the ViewModel through mechanisms like data binding, which ensures that changes in the ViewModel are automatically reflected in the View.

By separating concerns in this manner, MVVM facilitates a clear division of labor with respect to how data is managed, presented, and interacted with. This not only makes the application easier to maintain but also enhances its scalability and testability.

How to Obtain Reactivity?

To ensure that view controllers are aware of changes in the ViewModels, a mechanism for subscribing to and receiving notifications of these changes is necessary. One effective approach to achieve this in iOS development is through the use of Apple’s Combine framework.

Combine allows ViewModels to publish updates whenever their state changes. View controllers can subscribe to these publications and react accordingly. This setup ensures that the View layer remains responsive and up-to-date with the latest data. Here’s a basic example of how this might be implemented:

ViewModel publishes changes: The ViewModel includes properties marked with @Published, triggering the publisher whenever the property’s value changes.
View controller subscribes to changes: In the view controller, a subscriber is set up to listen to the ViewModel’s publishers. Using Combine’s sink(receiveValue:) method, the view controller can update its UI components whenever it receives new data.

This model promotes a reactive and efficient architecture where data flow and user interface updates are tightly coordinated.

Making an app: MVVM Counter

Let’s recreate a simple counter app using MVVM + Combine + UIKit. This app is a great first introduction to reactive programming since it shows the basic components and their interactions.

Where is the model?

This app is quite simple, the model is just an Int that will be updated every time we press the button. That’s why we aren’t creating an explicit model object. But remember with more complex models is a good idea to have a separate struct for them.

Creating the View Model

The View Model will contains the state and the methods to interact with the states, this object will relay on Combine to publish the changes to their subscribers.

Create a new file called ViewModel.swift and add the following code.

import Combine

class ViewModel: ObservableObject {
    @Published private(set) var counter = 0
    
    func addOne() {
        counter += 1
    }
}

Here is a brief description of the code:

class ViewModel: ObservableObject: We define a class ViewModel that conforms to the ObservableObject protocol. This protocol is part of the Combine framework and allows the properties of our ViewModel to be observed by the UI for changes.
@Published private(set) var counter = 0: Here, counter is a property that stores a numerical value, initialized to 0. The @Published attribute before counter makes it a published property, meaning any UI components observing this property can react to changes in its value. The private(set) modifier means that the value of counter can only be modified within the ViewModel class itself, enforcing encapsulation and control over how the value is changed.
func addOne(): This function defines the behavior to increment the counter by 1. Whenever addOne is called, the counter property is increased, and because it’s a @Published property, all observers (such as UI components) are notified of this change.

Creating the View

To create the View we are using a UIViewController, let’s create a new file and call it ViewController.swift.

First, let’s add the UI Elements to our controller. In this simple app we only need a UILabel and a UIButton.

import UIKit

class ViewController: UIViewController {
    
    private lazy var counterLabel: UILabel = {
        let label = UILabel()
        label.translatesAutoresizingMaskIntoConstraints = false
        label.text = "Button pressed 0"
        return label
    }()
    
    private lazy var counterButton: UIButton = {
        let button = UIButton()
        button.translatesAutoresizingMaskIntoConstraints = false
        button.configuration = UIButton.Configuration.filled()
        button.setTitle("Count", for: .normal)
        return button
    }()

    override func viewDidLoad() {
        super.viewDidLoad()
        configuration()
        addObjectsToView()
        addConstraintsToObjects()
        
    }
}

private extension ViewController {
    func configuration() {
        view.backgroundColor = .systemBackground
        
        counterButton.addAction(UIAction { [weak self] _ in print("Button tapped") }, for: .touchUpInside)
    }
    
    func addObjectsToView() {
        [counterLabel, counterButton].forEach {
            view.addSubview($0)
        }
    }
    
    func addConstraintsToObjects() {
        NSLayoutConstraint.activate([
            counterLabel.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            counterLabel.centerYAnchor.constraint(equalTo: view.centerYAnchor),
            counterButton.topAnchor.constraint(equalTo: counterLabel.bottomAnchor, constant: 32),
            counterButton.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -32),
            counterButton.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 32)
        ])
    }
}

So far nothing new, just a simple ViewController with some UI elements.

Adding Reactivity

Now comes the interesting part of the MVVM pattern, reacting to changes in the ViewModel.

The first step it to include Combine in the ViewController.

Next, let add a dependency to the ViewModel so that our ViewController can subscribe to the changes published by the view model.

Inside the ViewController class add the following properties

private let viewModel = ViewModel()
private var cancellables: Set<AnyCancellable> = []

The above code may become confusing because of the cancellables property, this is used to avoid memory leaks.

When you use the Combine framework to handle data flows in your applications, you often set up subscriptions where your UI components or other parts of your app listen to changes in your data. These subscriptions create what are known as “cancellables,” which are objects that represent the life of a subscription. To manage these effectively and avoid memory leaks, we use AnyCancellable.

By adding these AnyCancellable instances to a set called cancellables, you keep a reference to each active subscription. Storing them in a set is convenient because it ensures that each subscription is kept alive as long as you need it and is automatically cancelled and removed from memory when no longer needed or when the containing object (like a view model or view controller) is deallocated.

Next we need to subscribe to the published property of the view model.

Go to the configuration function and add the following at the bottom.

viewModel.$counter
            .sink { [weak self] value in
                self?.counterLabel.text = "Button Pressed \(value)"
            }.store(in: &cancellables)

The code snippet demonstrates how to update a user interface component in response to changes in a ViewModel property using Combine. Here’s how it works:

**viewModel.$counter**: This line begins observing changes to the counter property in the ViewModel. The $ prefix is a shorthand in Combine that provides a publisher for the property, which emits a new value each time the property changes.
.sink: The sink method is used to subscribe to the publisher and handle new data as it arrives. This method takes a closure that defines what to do with the emitted values. In this case, whenever counter updates, the closure receives the new counter value.
[weak self] value in: The closure captures self weakly to prevent retain cycles, which can lead to memory leaks. value is the latest value of counter emitted by the publisher.
self?.counterLabel.text = “Button Pressed (value)”: Inside the closure, the text of counterLabel (a UI label) is updated to display the number of times a button has been pressed, as indicated by the counter value.
.store(in: &cancellables): This part of the code is crucial for managing the subscription’s lifecycle. It adds the subscription to a set of cancellables (explained in the previous part about AnyCancellable). This ensures that the subscription remains active as long as needed and gets properly disposed of to prevent memory leaks.

This pattern is commonly used in iOS development with UIKit to dynamically update the UI in response to data changes in the ViewModel, enhancing the app’s reactivity and user experience.

Finally let’s update the button action to call the method that will triggers the View Model updates, in the configuration method, change the button action to the following.

counterButton.addAction(UIAction { [weak self] _ in self?.viewModel.addOne() }, for: .touchUpInside)

This will change the value in the view model each time we press the button, by changing the value we will trigger the notification in the published property, making the view controller to react to the change and update the value in the label automatically.

Here is the final form of the ViewController.

import UIKit
import Combine

class ViewController: UIViewController {
    
    private let viewModel = ViewModel()
    private var cancellables: Set<AnyCancellable> = []
    
    private lazy var counterLabel: UILabel = {
        let label = UILabel()
        label.translatesAutoresizingMaskIntoConstraints = false
        label.text = "Button pressed 0"
        return label
    }()
    
    private lazy var counterButton: UIButton = {
        let button = UIButton()
        button.translatesAutoresizingMaskIntoConstraints = false
        button.configuration = UIButton.Configuration.filled()
        button.setTitle("Count", for: .normal)
        return button
    }()

    override func viewDidLoad() {
        super.viewDidLoad()
        configuration()
        addObjectsToView()
        addConstraintsToObjects()
        
    }
}

private extension ViewController {
    func configuration() {
        view.backgroundColor = .systemBackground
        
        counterButton.addAction(UIAction { [weak self] _ in self?.viewModel.addOne() }, for: .touchUpInside)
        
        viewModel.$counter
            .sink { [weak self] value in
                self?.counterLabel.text = "Button Pressed \(value)"
            }.store(in: &cancellables)
    }
    
    func addObjectsToView() {
        [counterLabel, counterButton].forEach {
            view.addSubview($0)
        }
    }
    
    func addConstraintsToObjects() {
        NSLayoutConstraint.activate([
            counterLabel.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            counterLabel.centerYAnchor.constraint(equalTo: view.centerYAnchor),
            counterButton.topAnchor.constraint(equalTo: counterLabel.bottomAnchor, constant: 32),
            counterButton.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -32),
            counterButton.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 32)
        ])
    }
}

Running the app

As simple as this you’ve implemented MVVM with Combine and UIKit. This example is a great way to observe the simplicity and power of reactive programming.

Here is the final result.

Conclusion

Throughout this post, we’ve explored how the MVVM architectural pattern can be effectively implemented in UIKit applications using the Combine framework to create reactive behaviors similar to those found in SwiftUI. By integrating MVVM with Combine, we’ve demonstrated that UIKit is far from obsolete in the era of modern, reactive iOS applications. Instead, it offers a robust platform for adopting reactive programming paradigms that can make your apps more responsive and easier to maintain.

The MVVM pattern not only separates concerns, enhancing the maintainability and testability of your applications, but also leverages the power of Combine to keep your UI in perfect sync with the underlying data model. As we have seen with our simple counter app example, even traditional UIKit apps can benefit immensely from the clarity and efficiency that reactive programming brings.

I hope this walkthrough has provided you with a clear understanding and practical knowledge on integrating MVVM with UIKit using Combine, and inspires you to apply these concepts to your own iOS projects. Reactive programming might seem daunting at first, but with practice, it becomes an indispensable part of crafting elegant and efficient iOS applications.

Thank you for joining me on this journey through reactive programming with UIKit and MVVM. Happy coding!

Working With Xibs And Storyboards

Sun, 05 May 2024 05:40:28 +0000

In this entry, I’d like to explore the different ways we can interact with Xibs and Storyboards in our programmatic code. These files are present in many projects, so it’s important to understand the basics of how to work with them.

Let’s start with some definitions!

Definitions

What are Storyboards

Storyboards are like a big visual map in Xcode that lets you design your app’s screens. You can drag and drop things like buttons, labels, and images onto these screens to see how they’ll look. Plus, you can easily set up how the screens connect and move between each other. It’s like drawing out your app’s flow and layout so you can get a good idea of how it’ll all work together without needing to write too much code right away.

What are Xibs/Nibs

Xibs, short for “XML Interface Builder,” are individual files in Xcode that help you design a specific screen or component of your app. Think of them as blueprints for smaller, reusable parts of your app’s user interface. Unlike Storyboards, which give you a big-picture view of your entire app, Xibs are focused on one screen or view at a time. You can visually arrange buttons, labels, and other UI elements in a Xib file, then load that design in your app to get a custom layout exactly how you want it. It’s a handy way to build specific UI pieces without touching too much code.

On the other hand, Nibs (short for “NeXT Interface Builder”) are essentially compiled versions of Xibs. When you design a user interface in Xcode using a Xib file, it gets converted into a more optimized format called a Nib file that the app can load at runtime. This makes the interface ready to use more quickly. In short, Nibs are pre-packaged user interface designs created from Xibs, enabling the app to load and use them efficiently when needed.

So, while you work on Xibs during development, your app uses Nibs when it runs!

Working with Storyboards

Creating a new Storyboard

When we create a new app with Storyboard, Xcode automatically will create a Main Storyboard. We can also create these files, here is how:

Inside an Xcode project let’s press CMD + N and select storyboard in the presented window.

Add a name for the new Storyboard, remember to add it to the correct Group and Target.

The new Storyboard is ready to use in our project, add the elements you need inside the Storyboard graphically, no code is needed here.

Adding constraints to the Storyboard

By default, new UI elements added to the Storyboard doesn’t know where they will be placed on the screen. To alleviate this we can add constraints to the elements in the screen.

UI elements can be seen as rectangles on the screen and the constraints tells these sides how to relate to other elements in the screen.

If the UI element is affected by the language orientation you should use leading and trailing.

One key difference between programmatic constraints and visual constraints (those added in the Xcode Interface Builder) is that the latter are added to the closest element to the selected UI element.

In this example, the Label bottom is constrained to the top side of the button because that is the closest element to the Label, the other sides are related to the container view sides because this is the the closest element in relation to this UI object.

To add constraints using the Interface Builder we use the buttons at the bottom right.

These are called:

Update frames
Align
Add new constraints
Resolve Autolayout Issues

We can use Add new constraints to add constrains to the selected view. Remember that this constrains will be in relation to the closest object for the selected side of the object.

to center elements with respect to the super view, we can use Align.

Once these constraints are set, we can modify them by open the right panel and select Show the size inspector.

In this panel we can also modify the Hugging and Compression.

Hugging and Compression

When working with auto layout, there are two important concepts:

Content Hugging Priority: This controls how much a view likes to stick to its natural size. Higher priority = less likely to grow bigger than its content.
Content Compression Resistance Priority: This controls how much a view resists shrinking below its natural size. Higher priority = less likely to be squished.

Simply put, hugging stops a view from stretching too much, and compression resistance prevents it from getting squished too much.

Adjusting Priorities and Values

Priority Values: Default values are 250 for content hugging and 750 for compression resistance. Adjusting these values can help achieve the desired behaviors in your UI.
Intrinsic Content Size: Some elements, like labels and buttons, have a natural size based on their content. Hugging and compression resistance help these elements maintain that size whenever possible. For example, a label with high compression resistance won’t shrink and cut off the text, while low compression resistance allows it to shrink and potentially truncate the text. A low content hugging priority allows the label to expand beyond the text’s size, while high content hugging priority keeps the label close to its content and prevents unnecessary expansion.

Handling Ambiguity and Conflicts

Ambiguous Layouts: When auto layout can’t determine the final position or size of a view, you may see a warning about ambiguous layouts. To fix this, ensure all views have enough constraints to define their positions fully.
Conflicting Constraints: Conflicting constraints happen when two or more constraints contradict each other. For instance, a button cannot be both centered and anchored to a side. Resolve these by removing or adjusting constraints to eliminate conflicts.

Use Cases and Best Practices

Adjusting Priorities: If you have a flexible view like a label next to a fixed-size view like an image, increase the label’s hugging priority to prevent unwanted expansion.
Avoiding Common Mistakes: Be careful not to over-constrain views. Over-constraint can lead to conflicts or unexpected resizing, so it’s best to only apply necessary constraints.

Assigning a ViewController to the Storyboard

Having the storyboard is great, but we need to add code to make it function logically within our app. One way to do this is by associating a view controller with the storyboard.

Open the right panel in Xcode (CMD + OPT + 0) and the Storyboard file.
Select the View Controller Scene in the inner left panel.
On the right panel select Show Identity Inspector, here you will see a section called Custom Class, you add your reference in the Class section. Select any UIViewController class you want to connect to the storyboard and assign a Storyboard ID.

After adding the ViewController, you will end up with this. Now you can connect your elements in the storyboard to your ViewController and access their attributes and add actions as needed.

Don’t forget to add a Storyboard ID, we need this to reference it from objects in our code.

Linking Storyboard elements to ViewController

There are several ways of linking the UI elements in the Storyboard to a particular View Controller.

Here is one simple approach with CONTROL + Drag.

CONTROL + Drag means you should move your cursor (using your mouse, trackpad, or other input device) to the file on the right while you’re pressing the CONTROL key on your keyboard.

Open the Storyboard file.
On the up right side click on Adjust Editor Options.
Select Assistant Layout (CONTROL + OPTION + CMD + ENTER).
CONTROL + Drag the UI elements to the code.

Here is a video showing the whole process.

Finally you can add the logic in the View Controller. For this example we have a button that changes the background color and updates the label with the selected color.

import UIKit

class ExampleViewController: UIViewController {

    @IBOutlet weak var colorLabel: UILabel!
    
    override func viewDidLoad() {
        super.viewDidLoad()
    }
    
    private func updateScreen(with color: UIColor) {
        view.backgroundColor = color
        colorLabel.text = color.accessibilityName
    }
    
    @IBAction func whiteAction(_ sender: Any) {
        updateScreen(with: .white)
    }
    
    @IBAction func redAction(_ sender: Any) {
        updateScreen(with: .red)
    }
    
    @IBAction func greenAction(_ sender: Any) {
        updateScreen(with: .green)
        
    }
    
    @IBAction func blueAction(_ sender: Any) {
        updateScreen(with: .blue)
    }
}

Accessing the UI element in the View Controller

Interactive Elements

To access interactive UI elements declared in the storyboard from the view controller, we have two options:

Using an IBOutlet reference.
Using an associated IBAction.

If we want to use the associated action, we can cast the received sender to the appropriate UI type. Here’s an example with a button.

@IBAction func greenAction(_ sender: Any) {
        guard let button = sender as? UIButton else { return }
        print(button.titleLabel?.text ?? "No title label found")
        updateScreen(with: .green)
        
    }

We can do this with all UI elements that support interactivity via @IBAction.

The IBAction mechanism is designed specifically to handle user-triggered events, which usually means interactive controls like buttons, sliders, switches, etc.

List of interactive UIElements

UIButton: Supports touch events like tapping and can be connected to IBAction for touchUpInside, touchDown, etc.
UISwitch: Can trigger an IBAction when its on/off state changes.
UISlider: Sends an action when its value changes due to user interaction.
UISegmentedControl: Triggers an action when the selected segment changes.
UIDatePicker: Triggers an action when the selected date changes.
UITextField: Supports actions like editingDidEnd or editingChanged.
UIPageControl: Triggers an action when the current page index changes.
UIRefreshControl: Triggers an action when the user initiates a refresh in a scroll view.
UINavigationItem and UIBarButtonItem: Both can have actions assigned via IBAction to handle navigation or toolbar events.

Non interactive element

To access non-interactive elements, we need to use their IBOutlet reference inside the view controller.

To add actions for these elements, we can use a UITapGestureRecognizer.

In this example, the view controller has a reference to a label in the storyboard via IBOutlet, and we can add the following code to enable interactivity.

class ExampleViewController: UIViewController {

    @IBOutlet weak var colorLabel: UILabel!
    
    override func viewDidLoad() {
        super.viewDidLoad()
        addTapActionToLabel() // Add this function call
    }

    // More code

    // Add this function
    private func addTapActionToLabel() {
        let tapGesture = UITapGestureRecognizer(target: self, action: #selector(labelTapped))
        colorLabel.addGestureRecognizer(tapGesture)
        colorLabel.isUserInteractionEnabled = true
    }
    
    // Add this function
    @objc func labelTapped() {
        print("Label tapped!")
    }

    // More code
}

The IBOutlet mechanism is designed specifically to link UI elements, such as labels, buttons, and image views, to properties in your code, enabling you to access and modify these components programmatically after connecting them via a storyboard or Xib file.

List of non interactive UI elements

UILabel: Displays static or dynamic text but doesn’t respond to user interactions on its own.
UIImageView: Shows images but isn’t designed to respond to taps or other gestures directly.
UIView: A base view class that serves as a container for other elements and doesn’t have direct user interaction methods.
UIStackView: Arranges child views in a horizontal or vertical stack but doesn’t have built-in user-triggered events.
UITableViewCell: The individual cells in a table view that respond to user interaction only through their parent table view.
UICollectionViewCell: Similar to table view cells, these collection view cells interact through the parent collection view.

Instantiating Storyboards from another View Controller

To instantiate programmatically a storyboard from another class we can follow the next approach.

To achieve this we need two pieces of information, the name of the storyboard file and the Storyboard ID. We use the first element in UIStoryboard and the second element in storyboard.instantiateViewController.

We can present or push the final object, in this example we are pushing the storyboard as a modal.

// A different view controller that will instantiate the storyboard
class ViewController: UIViewController {

    // More code

    override func viewDidAppear(_ animated: Bool) {
        presentStoryboard()
    }

    func presentStoryboard() {
        let storyboard = UIStoryboard(name: "ExampleStoryboard", bundle: nil)
        if let exampleViewController = storyboard.instantiateViewController(withIdentifier: "ExampleSB") as? ExampleViewController {
            present(exampleViewController, animated: true, completion: nil)
        }
    }

    // More code

}

Here is a small example of the resulting presentation.

Working with Xibs

Working with Xibs is similar to working with Storyboards, so this section will feel familiar to the Storyboard section.

Creating Xibs

With an associated View Controller

One simple way to create a Xib is during the creation of a View Controller.

Inside an open Xcode project press CMD + N to open the template window.

Then give it a name and check the box Also create XIB file.

After pressing Next, select a directory to create the files and check the target and group are correct.

Now two files will be created, the Xib and the View Controller class.

These two files are now linked by default, so you can add IBActions and IBOutlets in your custom controller class to add some logic to the Xib.

Simple example to control the Xib objects from code

Let’s add and connect the following elements to the Xib. You can add the constrains as you like.

Then let’s add some IBOutlet to the preconfigured UIViewController subclass (this process is the same as with the Storyboard, you can refer it here).

class ExampleXibViewController: UIViewController {
    @IBOutlet weak var titleLabel: UILabel!
    @IBOutlet weak var subheadingLabel: UILabel!
    
    override func viewDidLoad() {
        super.viewDidLoad()
        titleLabel.text = "Awesome Xib Example"
        subheadingLabel.numberOfLines = 0
        subheadingLabel.text = "Learning how to integrate Xibs on your programmatic projects."
    }

}

#Preview(traits: .sizeThatFitsLayout) {
    ExampleXibViewController()
}

Now you can see how the Xib is loaded automagically (this works because both files have the same name and the Xib was autoconfigured to have this class as its file owner) and thanks to the IBOutlet you can manage their state and actions using the references in the code.

Individually

To create an individual Xib file, press CMD + N and select either View or Empty.

Finally, we give a name, check the correct group and target, and press Create.

Change Xib visual interface to freeform

By default Xib interface resembles an iPhone screen, sometimes we are creating a View that will act as a component, in these cases having the iPhone layout is not the best idea.

To change to a freeform layout we can do the following

Open the right bar CMD + OPC + 0.
In the right bar, select Show the attribute inspector.
Under Simulated metrics select size.
In the size menu select Freeform.
Optional, change the dimensions of your Xib to your liking.

Disable Safe Area for Freeform Xibs

If we are using our Xibs as a component to the final screen, we may not want to have Safe area on by default, to turn it off we can do the following:

Open the right bar CMD + OPC + 0.
In the right bar, select Show the size inspector.
Under Layout Guides untick Safe Area.

Adding constraints to Xibs

This works the same as adding constraints to Storyboards, you can refer to that section here.

Connecting Xibs to Classes

Individual Xibs can be connected to Classes to add some logic to them.

We are covering these cases:

Connecting to UIView subclass.
Connecting to UIViewController subclass.
Connecting to UITableViewCell or UICollectionViewCell subclasses.

Connecting to `UIView` subclass

We can bind a Xib with a UIView subclass, this process is a tad complicated than binding with UIViewControllers.

First, let’s create the UIView subclass we are going to bind to the Xib.

Press CMD + N and select Swift File.

Give it a name and be sure to add it to the right group and target, press create.

Create the class by adding the following code to the new created file.

import UIKit

class SimpleXibView: UIView {
    
    override init(frame: CGRect) {
        super.init(frame: frame)
    }
    
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
}

#Preview(traits: .sizeThatFitsLayout) {
    SimpleXibView(frame: CGRect(x: 0, y: 0, width: 100, height: 100))
}

Assign this class as the File's Owner

Add the nib load method to the UIView custom class.

We use this method to load the Xib with the same name as our UIView class, if your Xib has a different name update the method accordingly.

private func loadFromNib() {
        guard let view = Bundle(for: type(of: self)).loadNibNamed(String(describing: type(of: self)), owner: self, options: nil)?.first as? UIView else { return }
        view.frame = self.bounds
        view.autoresizingMask = [.flexibleWidth, .flexibleHeight]
        self.addSubview(view)
    }

Call the method in the init to load the Nib, your class should look like this.

import UIKit

class SimpleXibView: UIView {
    
    override init(frame: CGRect) {
        super.init(frame: frame)
        loadFromNib()
    }
    
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    private func loadFromNib() {
        guard let view = Bundle(for: type(of: self)).loadNibNamed(String(describing: type(of: self)), owner: self, options: nil)?.first as? UIView else { return }
        view.frame = self.bounds
        view.autoresizingMask = [.flexibleWidth, .flexibleHeight]
        self.addSubview(view)
    }
   
}

#Preview(traits: .sizeThatFitsLayout) {
    SimpleXibView(frame: CGRect(x: 0, y: 0, width: 100, height: 100))
}

Preview the Nib on the Canvas!

Now you have linked your Xib with a custom UIView subclass.

You can add IBOutlet or IBAction to manage the logic of your View. This mechanism doesn’t change from how we did it with Storyboards, here you can find out more.

Connecting to `UIViewController` subclass

Xibs are easy to connect to UIViewController.

Assign the File's Owner to the desire custom class.
CONTROL + CLICK on File's Owner and drag view to the view object on screen.

The view property of the File's Owner only appear if the assigned class is a subclass of UIViewController.

Here is a video showing the process.

Connecting to `UITableViewCell` or `UICollectionViewCell` subclasses

Working with tables deserves a separate entry, but to finish Xibs let’s give the steps needed to create and link cells.

Create the Xib File: In Xcode, right-click on the project navigator, select “New File…”, choose “View” under the User Interface section, and name the Xib after the cell it represents, like CustomTableViewCell.xib.
Design the Interface: Open the Xib file, drag a UITableViewCell or UICollectionViewCell from the object library onto the canvas, and add UI elements like labels, images, buttons, etc.
Create the Cell Subclass: Create a new Cocoa Touch Class, subclass UITableViewCell or UICollectionViewCell as CustomTableViewCell, then go back to your Xib file, select the cell, and set the class to CustomTableViewCell in the Identity Inspector.
Connect Outlets: With the Xib file and the Assistant Editor open (showing CustomTableViewCell.swift), Ctrl-drag from the UI elements in the Xib to the class file to create outlets and actions.
Register the Xib with the Table or Collection View: In your view controller’s viewDidLoad() method, register the Xib with let nib = UINib(nibName: "CustomTableViewCell", bundle: nil) and tableView.register(nib, forCellReuseIdentifier: "CustomCellIdentifier") for UITableView, or similar steps for UICollectionView.

Conclusion

In this blog entry, we’ve embarked on a comprehensive exploration of Xibs and Storyboards within Xcode, unraveling their functionalities and best practices to enhance our iOS development skills. By dissecting their definitions and diving into practical implementation scenarios, we’ve equipped ourselves with the knowledge to effectively utilize these tools in creating both complex and component-specific user interfaces.

The step-by-step guides provided will serve as a valuable reference for integrating Xibs and Storyboards into your projects, ensuring you can confidently handle layout constraints, link UI elements to code, and streamline your development process. Whether you’re crafting a single view or orchestrating an entire app’s flow, the insights shared here aim to bolster your proficiency and creativity in using these powerful features of Xcode.

As we continue to evolve our skills in the iOS development landscape, let’s leverage the flexibility and functionality of Xibs and Storyboards to create more dynamic, efficient, and visually compelling applications when working with UIKit.

Introduction to Programmatic UIKit

Tue, 16 Apr 2024 01:27:55 +0000

Hello world, I’m back with a new entry on UIKit. In iOS 17 Apple added the ability to preview our views and ViewControllers using the SwiftUI canvas. This brings the possibility of faster programmatic UIKir programming. Let’s make a small project that illustrates how to leverage this new functionality and revising how we can create an app in UIKit 100% programmatically. 🚀

The app

We will be coding an app that will ask for user information and then send it back to the main ViewController, this will showing us a simple way to pass information between views, a small introduction intro programmatic navigation and view reusability.

Configuring the project to work without Storyboard

Deleting storyboard files and references

UIKit only works on iOS and iPadOS, so you’ll need to create an iOS app in Xcode and select Storyboard, but don’t worry we’re going to delete all the stuff related to it. We’re going full code this time.

Select iOS App and Storyboard for the interface, remember Storyboard means UIKit under the hood.

Once Xcode is open with our project we need to delete all the stuff related to storyboard configuration.

First, let’s delete the Storyboard by moving it to the trash (you can leave the LaunchScreen).

Now let’s delete the references for the deleted Storyboard, follow the images and delete the selected sections.

Congratulations, you have deleted storyboards from your UIKit project. Now run the app and see a cool black screen.

Now it’s time to instantiate and show our first screen!

Open SceneDelegate.swift and locate the function func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions), next replace the code inside the function with this.

guard let windowScene = (scene as? UIWindowScene) else { return }
let viewController = ViewController()
let navigationController = UINavigationController(rootViewController: viewController)
window = UIWindow(windowScene: windowScene)
window?.rootViewController = navigationController
window?.makeKeyAndVisible()

Here is an explanation of the code above:

Scene Detection and Guard Clause: guard let windowScene = (scene as? UIWindowScene) else { return }
This line ensures the scene parameter is of type UIWindowScene. If not, it exits the block of code to prevent errors. This is essential for apps supporting multiple scenes in iOS 13 and later.
View Controller Initialization: let viewController = ViewController()
Creates a new instance of ViewController, which should be a subclass of UIViewController. This controller will manage the app’s initial view.
Navigation Controller Setup: let navigationController = UINavigationController(rootViewController: viewController)
Initializes a UINavigationController with the viewController as its root. This setup provides a navigation bar and a stack-based navigation mechanism.
Window Initialization: window = UIWindow(windowScene: windowScene)
Creates a new UIWindow using the windowScene from the first line, setting up the environment where the app’s content will be displayed.
Setting the Root View Controller: window?.rootViewController = navigationController
Assigns the navigationController as the window’s root view controller, making viewController the first visible view.
Making the Window Key and Visible: window?.makeKeyAndVisible()
This method sets the window as the key window and ensures it is visible, making it the main focus for user interactions.

Each ViewController has an associated optional NavigationController, this object is used to manage the push and pop of different ViewControllers, some architectures like to manage this navigation using a coordinator.

Congratulations on having the basic components to navigate your app and show your first screen.

Creating the Model

The app is quite simple, the model just consist of two Strings that will be change according to what the user inputs in the form.

To create a Model we just need to create a struct with the fields we need. Create a new file called TrainerInfo.swift and add the following code.

import Foundation

struct TrainerInfo: Identifiable {
    let id: UUID
    var name: String
    var favoritePokemon: String
}

extension TrainerInfo: CustomStringConvertible {
    var description: String {
        "Trainer \(name) likes \(favoritePokemon)"
    }
}

This model will store the trainer’s name and their favorite Pokémon. The extension is a good way to get a string representation of the object, we will use this string later in our views.

Creating reusable components

Our app is quite simple, yet we are using several repeated components in our Views, to avoid repeating code and ensure the UI elements behave the same way through the app we are going to create simple reusable components. To do this we are going to extend the class element of the component we need and add a function that will create the component configured for our use.

Let’s start by creating a new Group called Extensions by pressing CMD + OPC + A, inside this new group let’s create a new file called UIExtensions.swift and add the following code:

import UIKit

extension UIButton {
    static func makeSimpleButton(title: String, action: UIAction) -> UIButton {
        let button = UIButton()
        button.setTitle(title, for: .normal)
        button.addAction(action, for: .touchUpInside)
        button.configuration = UIButton.Configuration.filled()
        button.translatesAutoresizingMaskIntoConstraints = false
        return button
    }
}

extension UILabel {
    static func makeSimpleLabel(
        text: String = "",
        textAlignment: NSTextAlignment = .center,
        font: UIFont = .preferredFont(forTextStyle: .body)
    ) -> UILabel {
        let label = UILabel()
        label.textAlignment = textAlignment
        label.text = text
        label.font = font
        label.translatesAutoresizingMaskIntoConstraints = false
        return label
    }
}

extension UIStackView {
    static func makeSimpleStack(axis: NSLayoutConstraint.Axis ) -> UIStackView {
        let stack = UIStackView()
        stack.axis = axis
        stack.translatesAutoresizingMaskIntoConstraints = false
        return stack
    }
}

extension UITextField {
    static func makeSimpleTextField(delegate: (any UITextFieldDelegate)?) -> UITextField {
        let textField = UITextField()
        textField.borderStyle = .roundedRect
        // Don't forget to add delegate to call the function that sends data back
        textField.delegate = delegate
        textField.translatesAutoresizingMaskIntoConstraints = false
        return textField
    }
}

Done, now we can use these methods to create preconfigured UI elements, we can configure further to tailor our needs, if the systems grows quite complex we could even implement Factories. This is a great way to avoid repeating code and ensuring UI uniformity for our app.

Creating our first screen

Now that we have all the needed code in place, it’s time to see some changes in our phone’s screen. Let’s open ViewController.swift and let’s start adding our UI elements!

For this screen we are going to use a UILabel and a UIButton, it’s time to use our handy make methods we defined in our previous step.

In the body class, let’s add the following properties that will contain the references to the UI elements.

private lazy var button: UIButton = .makeSimpleButton(title: "Add Trainer Data", action: buttonAction)
private lazy var label: UILabel = .makeSimpleLabel()

Now you will get an error because buttonAction is not defined, let’s fix that now!

Create a private extension of your ViewController class and add the missing method there.

private extension ViewController {
    
    var buttonAction: UIAction {
        UIAction { [weak self] action in
            print("Button pressed")
        }
    }
}

This should fix the error. Later on, we will add the logic for the pressed button.

Previewing your ViewController

iOS 17 allow us to see in the Canvas the current state of our ViewController. This addition makes creating UIKit code easier and faster since we can preview in realtime our changes.

To use this new feature we just need to add the following at the bottom of our ViewController.swift file. This uses the new macro features to creates a preview canvas that instantiate a copy of our view controller

#Preview {
    ViewController()
}

Now you will have this white iPhone on your right.

But wait, we just added two UI components to our ViewController, why aren’t they visible? This is because we need to tell the view controller where we want to place them in the View. to achieve this we need to use a nifty tool called Auto Layout.

Adding constraints to our UI elements

We have to elements loaded on memory now it’s time to define where in the view they will be and add them to the current View.

To make our process of adding these elements to the current view lets create a simple extension, place it in the UIExtensions file.

extension UIStackView {
    func addArrangedSubviews(_ views: [UIView]) {
        views.forEach {
            self.addArrangedSubview($0)
        }
    }
}

To make Auto Layout to work on our UI elements we need to remember to set translatesAutoresizingMaskIntoConstraints to false.

Now it’s time to add and configure how the UI will be displayed on the View.

To make this process easy, let’s make a method that will do this for us. Inside the ViewController class we need to add the following functions.

func configureView() {
        view.backgroundColor = .systemBackground
        view.addSubviews([button, label])
        configureConstraints()
    }
    
    func configureConstraints() {
        let buttonConstraints = [
            button.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            button.centerYAnchor.constraint(equalTo: view.centerYAnchor),
            label.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor, constant: 64),
            label.leadingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.leadingAnchor, constant: 16),
            label.trailingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.trailingAnchor, constant: -16)
        ]
        NSLayoutConstraint.activate(buttonConstraints)
    }

Understanding Auto Layout

When creating user interfaces in iOS under UIKit, Auto Layout is used to calculate the size and position of views based on the constraints we specify.

The code above establishes rules for placing a button and a label within their container view, centering the button and positioning the label near the top and stretching it from side to side. These constraints ensure that the UI elements are correctly laid out across different devices and orientations.

Setting Up the Scene

Here is a small analogy that I hope can help you to understand better the Auto Layout code:

Imagine you’re arranging furniture in a room (the view), with a chair (button) and a painting (label). You want these items to be placed according to specific rules:

Centering the Chair:
- button.centerXAnchor.constraint(equalTo: view.centerXAnchor):
  - Align the chair’s center with the room’s horizontal center.
- button.centerYAnchor.constraint(equalTo: view.centerYAnchor):
  - Align the chair’s center with the room’s vertical center.
Positioning the Painting:
- label.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor, constant: 64):
  - Place the top of the painting slightly below the top of the safe area (like giving it some space from the ceiling).
- label.leadingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.leadingAnchor, constant: 16):
  - Set the painting’s left edge a bit away from the room’s left wall.
- label.trailingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.trailingAnchor, constant: -16):
  - Set the painting’s right edge a bit away from the room’s right wall.

Applying the Rules

NSLayoutConstraint.activate(buttonConstraints):
- This activates the constraints, like finalizing the arrangement and instructing the system to place the furniture accordingly.

Remeber to call configureView() inside viewDidLoad or this code will never execute!

Now you can get your UI in the Canvas, congratulations!

If run the app and try to press the button nothing interesting will happen, let’s fix that next!.

Creating the Second Screen

The second screen will contain a Form that will ask for certain date to the user, this form is a great way to introduce reusable UIView

Creating the Reusable Field View

To make our reusable view we need to create a UIView.

Create a new Swift file and call it FormSectionView.swift, inside that file let’s create our class that inherit from UIView (all views in UIKit inherit from this class).

final class FormSectionView: UIView {
    // Our code will be here
}

Our View needs a way to communicate internal information outward and to receive information from the outside. To solve this problem we have several common methods in UIKit:

Delegation
Closures
Notification Center

In this example let’s explore using closures.

Creating the communication path

To receive information we need a closure that returns the information from the outside when this changes.

To send information we need to send the information as the closure parameter so the outside world can get and manipulate this information.

For our app we are receiving and sending text from this View.

Let’s define the communication path, inside FormSectionView class define the following variables.

var textDidChange: ((String) -> Void)?
    
var sectionTitle: (() -> String)? {
    didSet {
        sectionLabel.text = sectionTitle?()
    }
}

Here is what the code is doing:

Understanding the `textDidChange` Closure

Purpose: This property is a closure that takes a string as input and performs an action with no return value (Void). It’s designed to execute when text data changes, allowing for dynamic responses to user input or programmatic changes.
Usage: You use textDidChange to update other components of your application when the user modifies the text in a UITextField. This closure provides a way to react immediately to changes, facilitating actions like validation, interface updates, or data transformations without needing additional delegation or observation mechanisms.

Dynamic Title Setting with `sectionTitle`

Purpose: sectionTitle is a closure that, when called, returns a String representing the title of a section. It’s used to dynamically provide text for UI labels.
Behavior on Change (didSet): The didSet observer attached to sectionTitle automatically updates the sectionLabel.text each time the closure’s value is set or updated. The safe call sectionTitle?() ensures that the closure is only called if it’s not nil, preventing runtime errors.
Practical Use: This property can be particularly useful in adaptive UIs where the section title might change based on user interactions or other application logic. By tying the label text directly to a closure, you maintain flexibility and reduce the need for explicit refresh or update calls throughout your codebase.

Creating the UI elements

You may have noticed that the code inside the didSet failed because we didn’t add any UI to our UIView. Let’s fix that by adding the UI elements from this View.

As you remember, we extended some UI elements to create some preconnfigured objects, this will come handy in this class too.

Inside FormSectionView class add the following elements.

private lazy var sectionLabel: UILabel = .makeSimpleLabel(
        text: "No Text Received, sectionTitle not set.",
        textAlignment: .natural,
        font: .systemFont(ofSize: 24, weight: .semibold)
    )
    
    private lazy var sectionTextField: UITextField = .makeSimpleTextField(delegate: self)

These are the two elements we need to make our view, as before we also need to use Auto Layout to position them on the screen and add the elements so the View knows about them, to do that add this code at the bottom of the file.

private extension FormSectionView {
    func configureView() {
        addSubviews([sectionLabel, sectionTextField])
        configureConstraints()
    }
    
    func configureConstraints() {
        let sectionLabelConstraints = [
            sectionLabel.topAnchor.constraint(equalTo: topAnchor),
            sectionLabel.leadingAnchor.constraint(equalTo: leadingAnchor),
            sectionLabel.trailingAnchor.constraint(equalTo: trailingAnchor)
        ]
        
        let sectionTextFieldConstraints = [
            sectionTextField.topAnchor.constraint(equalTo: sectionLabel.bottomAnchor),
            sectionTextField.leadingAnchor.constraint(equalTo: leadingAnchor),
            sectionTextField.trailingAnchor.constraint(equalTo: trailingAnchor),
            sectionTextField.bottomAnchor.constraint(equalTo: bottomAnchor)
        ]
        
        let constraints = sectionLabelConstraints + sectionTextFieldConstraints
        
        NSLayoutConstraint.activate(constraints)
        
    }
    
}

In ViewControllers we usually place the configuration in viewDidLoad but since this is a View, we don’t have that life cycle so we need to use a normal init. Add the following code to the class.

override init(frame: CGRect) {
    super.init(frame: frame)
    configureView()
}

required init?(coder: NSCoder) {
    fatalError("init(coder:) has not been implemented")
}

In UIKit, the required init?(coder: NSCoder) initializer is a crucial component of the view and view controller initialization process when they are being instantiated from storyboards or XIB files.

To finalize our view we need a way to know when the text in the UITextField change, to achieve this we can use a delegate of this class. This is way we set this View as the delegate of the custom UITextField.

Add the following extension at the end of the file.

extension FormSectionView: UITextFieldDelegate {
    func textField(_ textField: UITextField, shouldChangeCharactersIn range: NSRange, replacementString string: String) -> Bool {
        guard let currentText = textField.text,
              let textRange = Range(range, in: currentText) else { return false }
        
        let updatedText = currentText.replacingCharacters(in: textRange, with: string)
        textDidChange?(updatedText)
        return true
    }
}

Function textField(_:shouldChangeCharactersIn:replacementString:): This delegate method is called whenever the user types a character, deletes a character, or pastes content into the text field. It asks the delegate (in this case, FormSectionView) if the specified text should be changed.

Inside the Function

Parameters:

textField: The text field containing the text.
range: The range of characters to be replaced.
string: The replacement string that is typed or pasted into the text field.

Guard Statement:

Checks if it can obtain the current text of the text field and convert the NSRange to a Range<String.Index> suitable for Swift string operations.
If it can’t, it returns false, preventing the change to the text field’s content.

Updating Text:

updatedText: A new string is created by replacing the characters within the specified range with the new string.
This is done using replacingCharacters(in:with:), which handles the text replacement safely, considering character encoding and composition.

Closure Call:

textDidChange?(updatedText): If the textDidChange closure is set, it’s called with the updatedText. This allows the class to react to text changes, potentially updating models, views, or triggering other logic.

Return Value:

Returns true to allow the text change to proceed. If you return false, the text field would not update its display to reflect the new text.

Previewing the View

As before, we can preview our View thanks to the canvas.

Add the following code at the end of the file to activate the Preview.

#Preview(traits: .sizeThatFitsLayout) {
    FormSectionView()
}

Here is our view!

Creating the Form View using the Reusable View component

It’s time to create the Form View that will be present in the view controller, thanks to the reusable view we can simplify the creation of this view.

Create a new Swift file called TrainerFormView.swift and add the following code.

import UIKit

final class TrainerFormView: UIView {

}

Next, let’s add the UI elements we need for this.

Add the following inside the class.

private lazy var headerTitle: UILabel = .makeSimpleLabel(
        text: "Trainer Form",
        font: .preferredFont(forTextStyle: .extraLargeTitle)
    )
    
    private lazy var formStack: UIStackView = .makeSimpleStack(axis: .vertical)
    
    private lazy var saveButton: UIButton = .makeSimpleButton(
        title: "Save Trainer Data",
        action: saveAction
    )

The button’s action saveAction will mark an error, we need to define this action. As before let’s create a private extension and add the action.

private extension TrainerFormView {
    var saveAction: UIAction {
        UIAction { [weak self] action in
            guard let self else { return }
            self.saveButtonAction?(self.trainerData)
        }
}

And add the following property inside the class, we are using this tuple as a way to store the current state of the entered data, this represents an instance of our model.

private var trainerData: TrainerInfo = .init(id: UUID(), name: "Name", favoritePokemon: "Pokemon")

Adding the custom fields to the stack

Stacks are a great way to add elements in a ordered way. In our case we are using them to store the custom text fields.

Let’s configure the stack with the UI we need.

Inside private extension TrainerFormView add the following function.

func configureStack() {
    let nameSection = FormSectionView()
    nameSection.sectionTitle = { "Trainer Name" }
    nameSection.textDidChange = { [weak self] text in
        self?.trainerData.name = text
    }
    
    let pokemonSection = FormSectionView()
    pokemonSection.sectionTitle = { "Favorite Pokémon"}
    pokemonSection.textDidChange = { [weak self] text in
        self?.trainerData.favoritePokemon = text
    }
    
    formStack.addArrangedSubviews([nameSection, pokemonSection])
    
    formStack.spacing = 16
}

Here we are setting the closure for communication, passing the text name and receiving the input data to then store it the tuple we have in this View.

Adding constraints

So far our elements cannot be rendered in the View because we still need to add them. As usual we need to set the Auto Layout for these elements, add the following function inside private extension TrainerFormView.

func configureConstraints() {
    let headerTitleConstraints = [
        headerTitle.topAnchor.constraint(equalTo: topAnchor),
        headerTitle.leadingAnchor.constraint(equalTo: leadingAnchor),
        headerTitle.trailingAnchor.constraint(equalTo: trailingAnchor)
    ]   
    
    let formStackConstraints = [
        formStack.topAnchor.constraint(equalTo: headerTitle.bottomAnchor, constant: 32),
        formStack.leadingAnchor.constraint(equalTo: leadingAnchor),
        formStack.trailingAnchor.constraint(equalTo: trailingAnchor)
    ]
    
    let saveButtonConstraints = [
        saveButton.topAnchor.constraint(equalTo: formStack.bottomAnchor, constant: 32),
        saveButton.heightAnchor.constraint(equalToConstant: 48),
        saveButton.leadingAnchor.constraint(equalTo: leadingAnchor),
        saveButton.trailingAnchor.constraint(equalTo: trailingAnchor)
    ]
    
    let viewConstraints = headerTitleConstraints + formStackConstraints + saveButtonConstraints
    
    NSLayoutConstraint.activate(viewConstraints)
}

Adding the init

To make all this work we need to add the init and call the configuration functions, like in the previous UIView we need to add the following to the class.

override init(frame: CGRect) {
    super.init(frame: frame)
    addSubviews([headerTitle, formStack, saveButton])
    configureConstraints()
    configureStack()
}

required init?(coder: NSCoder) {
    fatalError("init(coder:) has not been implemented")
}

If you don’t add the subviews before the constraints the simulator will crash.

Previewing the result

As normal, we can preview the view by using the canvas. Add the following code at the end of the file.

#Preview(traits: .sizeThatFitsLayout) {
    TrainerFormView()
}

Here is the final View!

Creating the FormViewController

The View Form is read, now we need a Controller that manages it!, it’s time to create our FormViewController.

Add a new file called FormViewController.swift and add the following code.

import UIKit

class FormViewController: UIViewController {

}

Adding the View

We could create a factory that help us to create the Views but this time let’s use a simple closure that returns the View.

inside the class add the following UI element (the view we just created).

lazy var trainerForm: TrainerFormView = {
        let form = TrainerFormView()
        return form
    }()

We also need a way to communicate the result of our View Form to any parent view controller, to achieve this we are using again a closure with the data received from the view.

Add this to the class.

var saveAction: ((TrainerInfo) -> Void)?

As always we need to add the view (we could override the default view also) and set the constraints, here we are also setting the closure that will receive the data from the View.

This closure will call the closure of our ViewController and send the information to the next object that needs this information.

The dismiss is used to pop this view from the screen.

Usually we have two way of presenting screens in iOS:

With a Push

With a Modal

To do that add this function to the class.

private func configureView() {
    trainerForm.translatesAutoresizingMaskIntoConstraints = false
    
    trainerForm.saveButtonAction = { [weak self] trainerData in
        self?.saveAction?(trainerData)
        self?.dismiss(animated: true)
    }
    
    view.addSubview(trainerForm)
    
    NSLayoutConstraint.activate([
        trainerForm.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor, constant: 16),
        trainerForm.leadingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.leadingAnchor, constant: 16),
        trainerForm.trailingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.trailingAnchor, constant: -16),
        trainerForm.bottomAnchor.constraint(equalTo: view.safeAreaLayoutGuide.bottomAnchor, constant: -16)
    ])
}

Wiring up the ViewController

To finish this ViewController just call the functions inside the viewDidLoad.

override func viewDidLoad() {
    super.viewDidLoad()
    view.backgroundColor = .systemBackground
    configureView()
}

As always you can also add a Preview, add at the end of the file.

#Preview {
    FormViewController()
}

Congratulations, you have the second view controller ready to use!

Next step is to present it from the first view controller and setting up the communication path.

Presenting the form

Open ViewController.swift and let’s modify the button action. Locate the var buttonAction: UIAction computed proerty and let’s modify it to have this code instead.

var buttonAction: UIAction {
        UIAction { [weak self] action in
            let formViewController = FormViewController()
            formViewController.saveAction = { [weak self] trainerData in
                self?.label.text = trainerData.description
            }
            self?.present(formViewController, animated: true)
        }
    }

Here, we are updating the UIAction, we are creating the controller we want to present and configure its closure. then we use the present() method to present modally the view controller.

In the closure we are receiving the data every time we press the button Save Trainer Data in the FormViewController. We are using this data to update the label in this ViewController.

By doing this change the app is ready.

Press run and let’s test it!

Testing the final app

Here is a video of the resulting app.

Congratulations, you made it to the end!

Conclusion

In this blog post, we’ve explored the benefits of programmatic UIKit development in iOS 17, showcasing the power and flexibility of bypassing storyboards to create dynamic user interfaces directly in code. By delving into practical examples—from configuring the project environment to creating reusable components and leveraging the SwiftUI canvas for real-time previews—we have demonstrated how a UIKit app can be constructed from the ground up with clarity and precision.

The ability to preview UIViews and ViewControllers within Xcode enhances development by providing immediate visual feedback, a feature that significantly streamlines the process of building and refining user interfaces. Moreover, our dive into the creation of reusable components not only promotes cleaner, more maintainable code but also fosters a modular approach to UI development that can be easily adapted or expanded upon.

By the end of our project, we effectively utilized closures and extensions to keep our codebase efficient and readable, and demonstrated the seamless flow of data between views, emphasizing the robustness of UIKit in handling complex user interactions.

As iOS continues to evolve, embracing these programmatic techniques provides a solid foundation for both new and experienced developers to build sophisticated and responsive apps. Whether you are transitioning from storyboards or enhancing your existing skills, the insights from this tutorial will undoubtedly aid in your journey towards mastering programmatic UIKit development. Happy coding! 🚀

Appendix

Here are the full code separated by files:

Controllers

`ViewController`

final class ViewController: UIViewController {
    
    // MARK: - UI Elements
    private lazy var button: UIButton = .makeSimpleButton(title: "Add Trainer Data", action: buttonAction)
    private lazy var label: UILabel = .makeSimpleLabel()

    // MARK: - ViewController Life Cycle
    override func viewDidLoad() {
        super.viewDidLoad()
        // To show the title I need a navigation controller initialized
        title = "Trainer Log"
        configureView()
    }


}

// MARK: - Private Methods
private extension ViewController {
    
    var buttonAction: UIAction {
        UIAction { [weak self] action in
            let formViewController = FormViewController()
            formViewController.saveAction = { [weak self] trainerData in
                self?.label.text = trainerData.description
            }
            self?.present(formViewController, animated: true)
        }
    }
    
    func configureView() {
        view.backgroundColor = .systemBackground
        view.addSubviews([button, label])
        configureConstraints()
    }
    
    func configureConstraints() {
        let buttonConstraints = [
            button.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            button.centerYAnchor.constraint(equalTo: view.centerYAnchor),
            label.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor, constant: 64),
            label.leadingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.leadingAnchor, constant: 16),
            label.trailingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.trailingAnchor, constant: -16)
        ]
        NSLayoutConstraint.activate(buttonConstraints)
    }
}

`FormViewController`

class FormViewController: UIViewController {
    
    var saveAction: ((TrainerInfo) -> Void)?
    
    private lazy var trainerForm: TrainerFormView = {
        let form = TrainerFormView()
        return form
    }()

    override func viewDidLoad() {
        super.viewDidLoad()
        view.backgroundColor = .systemBackground
        configureView()
    }
    
    private func configureView() {
        trainerForm.translatesAutoresizingMaskIntoConstraints = false
        
        trainerForm.saveButtonAction = { [weak self] trainerData in
            self?.saveAction?(trainerData)
            self?.dismiss(animated: true)
        }
        
        view.addSubview(trainerForm)
        
        NSLayoutConstraint.activate([
            trainerForm.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor, constant: 16),
            trainerForm.leadingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.leadingAnchor, constant: 16),
            trainerForm.trailingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.trailingAnchor, constant: -16),
            trainerForm.bottomAnchor.constraint(equalTo: view.safeAreaLayoutGuide.bottomAnchor, constant: -16)
        ])
    }

}

Extensions

import UIKit

extension UIView {
    /// Add the array of subviews to the current View
    /// - Parameter views: The views to add
    func addSubviews(_ views: [UIView]) {
        views.forEach {
            self.addSubview($0)
        }
    }
}

extension UIStackView {
    func addArrangedSubviews(_ views: [UIView]) {
        views.forEach {
            self.addArrangedSubview($0)
        }
    }
}

extension UIButton {
    static func makeSimpleButton(title: String, action: UIAction) -> UIButton {
        let button = UIButton()
        button.setTitle(title, for: .normal)
        button.addAction(action, for: .touchUpInside)
        button.configuration = UIButton.Configuration.filled()
        button.translatesAutoresizingMaskIntoConstraints = false
        return button
    }
}

extension UILabel {
    static func makeSimpleLabel(
        text: String = "",
        textAlignment: NSTextAlignment = .center,
        font: UIFont = .preferredFont(forTextStyle: .body)
    ) -> UILabel {
        let label = UILabel()
        label.textAlignment = textAlignment
        label.text = text
        label.font = font
        label.translatesAutoresizingMaskIntoConstraints = false
        return label
    }
}

extension UIStackView {
    static func makeSimpleStack(axis: NSLayoutConstraint.Axis ) -> UIStackView {
        let stack = UIStackView()
        stack.axis = axis
        stack.translatesAutoresizingMaskIntoConstraints = false
        return stack
    }
}

extension UITextField {
    static func makeSimpleTextField(delegate: (any UITextFieldDelegate)?) -> UITextField {
        let textField = UITextField()
        textField.borderStyle = .roundedRect
        // Don't forget to add delegate to call the function that sends data back
        textField.delegate = delegate
        textField.translatesAutoresizingMaskIntoConstraints = false
        return textField
    }
}

Views

`TrainerFormView`

import UIKit

final class TrainerFormView: UIView {
    
    private var trainerData: TrainerInfo = .init(id: UUID(), name: "Name", favoritePokemon: "Pokemon")
    
    var saveButtonAction: ((TrainerInfo) -> Void)?
    
    private lazy var headerTitle: UILabel = .makeSimpleLabel(
        text: "Trainer Form",
        font: .preferredFont(forTextStyle: .extraLargeTitle)
    )
    
    private lazy var formStack: UIStackView = .makeSimpleStack(axis: .vertical)
    
    private lazy var saveButton: UIButton = .makeSimpleButton(
        title: "Save Trainer Data",
        action: saveAction
    )

    override init(frame: CGRect) {
        super.init(frame: frame)
        // If you don't add the subviews before the constraints the simulator will crash
        addSubviews([headerTitle, formStack, saveButton])
        configureConstraints()
        configureStack()
    }
    
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
}

private extension TrainerFormView {
    
    func configureConstraints() {
        let headerTitleConstraints = [
            headerTitle.topAnchor.constraint(equalTo: topAnchor),
            headerTitle.leadingAnchor.constraint(equalTo: leadingAnchor),
            headerTitle.trailingAnchor.constraint(equalTo: trailingAnchor)
        ]
        
        let formStackConstraints = [
            formStack.topAnchor.constraint(equalTo: headerTitle.bottomAnchor, constant: 32),
            formStack.leadingAnchor.constraint(equalTo: leadingAnchor),
            formStack.trailingAnchor.constraint(equalTo: trailingAnchor)
        ]
        
        let saveButtonConstraints = [
            saveButton.topAnchor.constraint(equalTo: formStack.bottomAnchor, constant: 32),
            saveButton.heightAnchor.constraint(equalToConstant: 48),
            saveButton.leadingAnchor.constraint(equalTo: leadingAnchor),
            saveButton.trailingAnchor.constraint(equalTo: trailingAnchor)
        ]
        
        let viewConstraints = headerTitleConstraints + formStackConstraints + saveButtonConstraints
        
        NSLayoutConstraint.activate(viewConstraints)
    }
    
    var saveAction: UIAction {
        UIAction { [weak self] action in
            // If I don't safe unwrap self this wont work because trainerData despite not being optional
            // by the weak self it becomes optional when accessing via self?. .
            guard let self else { return }
            self.saveButtonAction?(self.trainerData)
        }
    }
    
    func configureStack() {
        let nameSection = FormSectionView()
        nameSection.sectionTitle = { "Trainer Name" }
        nameSection.textDidChange = { [weak self] text in
            self?.trainerData.name = text
        }
        
        let pokemonSection = FormSectionView()
        pokemonSection.sectionTitle = { "Favorite Pokémon"}
        pokemonSection.textDidChange = { [weak self] text in
            self?.trainerData.favoritePokemon = text
        }
        
        formStack.addArrangedSubviews([nameSection, pokemonSection])
        
        formStack.spacing = 16
    }
}

#Preview(traits: .sizeThatFitsLayout) {
    TrainerFormView()
}

`FormSectionView`

import UIKit

final class FormSectionView: UIView {
    
    var textDidChange: ((String) -> Void)?
    
    var sectionTitle: (() -> String)? {
        didSet {
            sectionLabel.text = sectionTitle?()
        }
    }
    
    private lazy var sectionLabel: UILabel = .makeSimpleLabel(
        text: "No Text Received, sectionTitle not set.",
        textAlignment: .natural,
        font: .systemFont(ofSize: 24, weight: .semibold)
    )
    
    private lazy var sectionTextField: UITextField = .makeSimpleTextField(delegate: self)
    
    override init(frame: CGRect) {
        super.init(frame: frame)
        configureView()
    }
    
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
}

private extension FormSectionView {
    func configureView() {
        addSubviews([sectionLabel, sectionTextField])
        configureConstraints()
    }
    
    func configureConstraints() {
        let sectionLabelConstraints = [
            sectionLabel.topAnchor.constraint(equalTo: topAnchor),
            sectionLabel.leadingAnchor.constraint(equalTo: leadingAnchor),
            sectionLabel.trailingAnchor.constraint(equalTo: trailingAnchor)
        ]
        
        let sectionTextFieldConstraints = [
            sectionTextField.topAnchor.constraint(equalTo: sectionLabel.bottomAnchor),
            sectionTextField.leadingAnchor.constraint(equalTo: leadingAnchor),
            sectionTextField.trailingAnchor.constraint(equalTo: trailingAnchor),
            sectionTextField.bottomAnchor.constraint(equalTo: bottomAnchor)
        ]
        
        let constraints = sectionLabelConstraints + sectionTextFieldConstraints
        
        NSLayoutConstraint.activate(constraints)
        
    }
    
}

extension FormSectionView: UITextFieldDelegate {
    func textField(_ textField: UITextField, shouldChangeCharactersIn range: NSRange, replacementString string: String) -> Bool {
        guard let currentText = textField.text,
              let textRange = Range(range, in: currentText) else { return false }
        
        let updatedText = currentText.replacingCharacters(in: textRange, with: string)
        textDidChange?(updatedText)
        return true
    }
}

#Preview(traits: .sizeThatFitsLayout) {
    FormSectionView()
}

Model

`TrainerInfo`

import Foundation

struct TrainerInfo: Identifiable {
    let id: UUID
    var name: String
    var favoritePokemon: String
}

extension TrainerInfo: CustomStringConvertible {
    var description: String {
        "Trainer \(name) likes \(favoritePokemon)"
    }
}

SceneDelegate modified function

func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        guard let windowScene = (scene as? UIWindowScene) else { return }
        let viewController = ViewController()
        let navigationController = UINavigationController(rootViewController: viewController)
        window = UIWindow(windowScene: windowScene)
        window?.rootViewController = navigationController
        window?.makeKeyAndVisible()
    }

An Introductory Example of Deeplinking in iOS

Sat, 13 Jan 2024 16:22:55 +0000

Hello everyone. Lately, I’ve been experimenting with deep links and SwiftUI.

In the realm of iOS development, deep linking emerges as a powerful and indispensable tool, offering developers the means to seamlessly connect users to specific content or features within their applications.

At its core, deep linking allows for the precise navigation to a particular section of an app, rather than merely launching the app’s home screen.

Understanding the fundamentals of iOS deep linking is pivotal for enhancing user experience, promoting user engagement, and, ultimately, unlocking the full potential of your mobile applications.

In today’s tutorial, we’re going to create a simple iOS app with several screens and configure the deeplinking mechanism to access and send data to those parts of our app.

So, grab your coding gear, fire up Xcode, and let’s create a new iOS project!

Deeplinking App Example

Configuring our project to handle deep links

The first step is related to some configuration that will allow deep links to work in our app. To do this configuration, follow the steps below:

Open your Xcode project file.
Select your target.
Select the Info tab.
Expand URL Types section.
Press the + button to add a new URL Type
Fill in the Identifier and Schema

The Identifier is used to uniquely identify your app in the system, so it’s a good idea to use your reverse domain and the name of your app. The URL Schema is the url used to access your app from other parts of the system, normally we use it as yourschema://action?param1=val1&param2=val2.

Creating the Data Model

Let’s continue with the creation of an enum that will handle the shape of our data. In this app we have 3 Views that are coordinated with a TabView, so we could define 3 possible states for each one and use the power of enums to define the data state for each view.

Let’s create a file called DeepLink.swift and inside add the following code:

import Foundation

// define the deep link options and associated tag value for each view in the tab view
enum DeepLink {
    case first
    case second
    case third
    
    var tag: Int {
        switch self {
        case .first: 1
        case .second: 2
        case .third: 3
        }
    }
    
    var action: String {
        switch self {
        case .first: "first"
        case .second: "second"
        case .third: "third"
        }
    }
    
    var icon: String {
        switch self {
        case .first: "1.lane"
        case .second: "2.lane"
        case .third: "3.lane"
        }
    }
    
    var title: String {
        self.action.capitalized
    }
}

extension DeepLink {
    static let scheme = "deeplink"
}

The enum contains the three cases we discussed earlier and returns the specific data needed for each view in each computed property. Finally, we’re adding a static property to store the scheme we will be accepting in our app. By doing this we can avoid problems when typing the different strings, and it also serve us as a single source of truth for our data.

Creating the Views

Let’s continue working on the Views we are going to access via deep links. These are simple views that will display a text, the last one will accept data from outside.

Create the files FirstView.swift, SecondView.swift, ThirdView.swift, then add the following code to each file respectively:

// Add this to FirstView.swift
import SwiftUI

struct FirstView: View {
    var body: some View {
        ZStack {
            Color.green
                .ignoresSafeArea()
            Text("First")
                .font(.largeTitle)
                .fontWeight(.bold)
        }
    }
}

#Preview {
    FirstView()
}

// Add this to SecondView.swift
import SwiftUI

struct SecondView: View {
    var body: some View {
        ZStack {
            Color.yellow
                .ignoresSafeArea()
            Text("Second")
                .font(.largeTitle)
                .fontWeight(.bold)
        }
    }
}

#Preview {
    SecondView()
}

// Add this to ThirdView.swift
import SwiftUI

struct ThirdView: View {
    let message: String?
    
    var body: some View {
        ZStack {
            Color.orange
                .ignoresSafeArea()
            VStack {
                Text("Third")
                    .font(.largeTitle)
                    .fontWeight(.bold)
                Text(message ?? "No message")
                    .font(.headline)
            }
        }
    }
}

#Preview {
    ThirdView(message: "Hello World")
}

Now let’s add the TabView that will handle the navigation between the three views. We are going to reuse the ContentView.swift file to do this. Open it and replace the code inside with this:

/*
 To test the deep links you can use Safari and enter the url with the schema and action defined here
 
 example:
 
 [Schema]   [Action]  [query variables]
 deeplink://first
 deeplink://second
 deeplink://third
 deeplink://third?msg=Hello%20from%20Safari
 */

import SwiftUI

struct ContentView: View {
    // our deep link will change this variable
    @State private var selectedTab: Int = DeepLink.first.tag
    // Stores the message sent from the deep link
    @State private var message: String? = nil
    
    var body: some View {
        TabView(selection: $selectedTab) {
            FirstView()
                .tabItem { Label(DeepLink.first.title, systemImage: DeepLink.first.icon) }
                .tag(DeepLink.first.tag) // we use the tag to navigate in the TabView
            SecondView()
                .tabItem { Label(DeepLink.second.title, systemImage: DeepLink.second.icon) }
                .tag(DeepLink.second.tag)
            ThirdView(message: message)
                .tabItem { Label(DeepLink.third.title, systemImage: DeepLink.third.icon) }
                .tag(DeepLink.third.tag)
        }
        .tint(.black)
        .onAppear { // Styling the TabBar
            let appearance = UITabBarAppearance()
            appearance.backgroundEffect = UIBlurEffect(style: .systemUltraThinMaterial)
            appearance.backgroundColor = UIColor(.white.opacity(0.6))
            UITabBar.appearance().standardAppearance = appearance
            UITabBar.appearance().scrollEdgeAppearance = appearance
        }
        .onOpenURL { url in // handling the deep link
            print("URL: \(url)")
            handleIncomingURL(url)
        }
    }
}

private extension ContentView {
    /// Handles the incoming URL and performs validations before acknowledging.
    private func handleIncomingURL(_ url: URL) {
        // Check that the scheme is the one for our app.
        guard url.scheme == DeepLink.scheme else {
            return
        }
        
        // Checking the URL contains valid components and saving them in a new variable.
        guard let components = URLComponents(url: url, resolvingAgainstBaseURL: true) else {
            print("Invalid URL")
            return
        }
        
        // From the components we are getting the URL host, in our case this equals the actions for our deep links.
        guard let action = components.host else {
            print("No action found")
            return
        }
        
        // Setting the data for the given action
        switch action {
        case DeepLink.first.action:
            selectedTab = DeepLink.first.tag
        case DeepLink.second.action:
            selectedTab = DeepLink.second.tag
        case DeepLink.third.action:
            selectedTab = DeepLink.third.tag
            // For the 3rd View we can accept data, we are getting all the data from the query's first element,
            // we could check for specific variable if needed.
            if let messageValue = components.queryItems?.first?.value {
                message = messageValue
            }
        default:
            print("Invalid action")
        }
    }
}

#Preview {
    ContentView()
}

The focus point of the above code is in the modifier .onOpenURL, we are using it to handle the upcoming URL from the deeplink. To handle this url we are defining a function that extracts the information and sets the appropriate data state for our views.

We may want to create a ViewModel for handling the data update and retrieval and make our Views reusable.

Testing the App

To test the deep links we could use different approaches, from using the terminal to third party apps. To keep this simple let’s use Safari inside the iOS simulator.

Open Safari and in the search bar enter the deeplink URL, we have three valid states:

deeplink://first
deeplink://second
deeplink://third?msg=Hello%20from%20Safari, here the msg query is optional, and you could send any data here.

Here is the app running:

Conclusion

And that’s a wrap on our introduction into iOS deep linking with SwiftUI! We’ve covered the ins and outs, from setting up the project to creating views and handling deep links seamlessly. Now armed with this knowledge, we’re ready to level up our iOS app game. So, dive in, experiment, and enjoy implementing deep linking for a more engaging user experience! Happy coding!

A Simple Full-Stack iOS App Example

Tue, 09 Jan 2024 18:04:28 -0800

One of the benefits of using Swift is its excellent performance and low memory footprint. This is a key point when doing backend programming.

The future of Swift in Linux looks promising. With Swift 5.9, there will be better error logging, and Apple is developing a new open-source cross-platform testing framework with swift-testing that will replace XCTest and works on Linux too.

Let’s hope this encourages more backend systems to be written in Swift.

In this tutorial, we’ll explore how to code a backend in Vapor and establish its connection to a simple iOS app. I hope this example serves as a good starting point for learning about the interaction between mobile and backend systems.

Getting Started: Tech Stack Overview

Backend

Some mobile developers prefer using auto-managed backend solutions like Firebase and may not pay much attention to the server side. Nevertheless, I believe that understanding the basic programming and concepts used in the backend can enhance your comprehension of the entire system. This understanding enables us to create solutions that are not only more efficient but also better integrated.

Framework

Backend programming is a complex topic with various frameworks in the market. In the Swift world, the most widely used backend framework is Vapor.

Vapor is an excellent solution for building backend systems. It utilizes a non-blocking, event-driven architecture built on top of Apple’s SwiftNIO. This offers us great performance, allowing us to create complex systems that scale well.

Keep in mind that some third-party services may not have a ready-to-use Swift/Vapor API. This can introduce additional complexity when integrating these services.

Database

For the database, we are using PostgreSQL. This database is an open-source relational database and offers great performance with a lot of useful features for any needs we could have.

To install and run our database, we are going to use Docker with a docker-compose file. This is great because we can start a database in seconds and allows us to replicate our configuration in different environments.

App

We use SwiftUI with modern concurrency (async/await), implementing a Network layer to manage requests, and follow the MVVM architecture to organize our code.

This approach enables us to delve into modern iOS development, providing insights into how all elements interconnect and respond to changes.

Coding the Backend

Installing docker

Let’s start our project by installing docker, we need it to create the database and the container for our vapor app.

We can use Homebrew to install it via the terminal, or just get it from the Docker site.

If you decide to use Homebrew, we need to have brew installed and run the following command on the terminal:

brew install --cask docker

Open Docker and let’s continue.

Creating and running the database

To set up our PostgreSQL database, we’ll need to create a docker-compose.yml file and define its configuration. Follow these steps:

Create a file named docker-compose.yml in your project directory.
Add the following configuration to the docker-compose.yml file:

version: '3'

services:
  postgres:
    image: postgres:latest
    container_name: postgres
    restart: always
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: postgres
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
    ports:
      - '5432:5432'
    networks:
      - fullstack-ios-net

volumes:
  postgres_data:

  networks:
    fullstack-ios-net:
        driver: bridge

volumes will tell Docker to create the persistance layer with the given name for us, so we don’t need to specify any directory.

Open a terminal in the directory containing the docker-compose.yml file.
Run the following command to start the database container:

docker-compose -p database-vapor up -d

You can change the container name by replacing database-test with your preferred name. The -d flag runs the container in detached mode, freeing up the terminal.

This will create a running database locally, ready for us to use in our backend.

To confirm that the database is running, execute the command docker ps in your terminal. Alternatively, you can check Docker Desktop if it is installed on your system.

Since we are running separate containers for the database and the vapor app, we need to get the network in which the database is attached, to do so let’s run:

docker network ls

In my case, the network created for this container is called database-vapor_fullstack-ios-net. We’ll use this network for the vapor app, so keeps your network name saved.

To check the containers attached to a network run: docker network inspect <network_name/ID>.

To delete a network run the command: docker network rm <network_name/ID>.

Here’s an example of the resulting database running on my system:

Creating the Vapor Container

Let’s move on to the exciting part – building our Vapor app. For this process, we’ll leverage a development container with VSCode, a fantastic tool that helps maintain a clean local environment and ensures reproducibility for every project.

Feel free to adjust this according to your style and preferences!

Follow these steps to create your empty vapor container:

Create a root directory for the vapor container.
Inside the root directory, create a new directory called .devcontainer.
Inside .devcontainer, create a new file called devcontainer.json and add the following:

{
    "name": "Vapor",
    "image": "swift:latest",
    "runArgs": [
        "--name=vapor-local-devcontainer",
        "--network=database-vapor_fullstack-ios-net"
    ],
    "postCreateCommand": "bash .devcontainer/vaporinstall.sh",
    "customizations": {
        "vscode": {
            "extensions": [
                "sswg.swift-lang",
                "streetsidesoftware.code-spell-checker"
            ]
        }
    }
}

We are adding this container to the same network as the database, this will allow communication between the two containers.

Create the Vapor installation script vaporinstall.sh file inside the .devcontainer directory.
Add the following to vaporinstall.sh:

#!/bin/bash

echo "Vapor installation is starting"

# Updating and installing packages
apt update && apt upgrade -y
apt install -y make

# Installing Vapor
git clone https://github.com/vapor/toolbox.git
cd toolbox
make install
cd ..
rm -rf toolbox

echo "Vapor installation was successful"

Open the project in VSCode and then select the option Reopen in Container.

To check Vapor is installed, run in a terminal vapor --version.

This will create the container and install vapor inside, you’re ready to code the backend in Vapor!

Finally, let’s check that both containers are under the same network, run this command in the host terminal:

docker network inspect database-vapor_fullstack-ios-net | grep -A 20 "Containers"

There you can check that our two containers are listed in the output under "Containers", we’re good to continue.

Creating a barebone Vapor App

It’s time to create our app inside the container, this is a simple task thanks to the integrated vapor tools:

Run in the container’s terminal the following:

vapor new temperature-api -n

-n will create a barebone project

Enter the new directory cd temperature-api
Run the project swift run

Congratulations, now your Vapor app is up and running. To verify that it works as expected you can check the root endpoint / in the URL mentioned in the terminal, usually http://127.0.0.1:8080/

Creating the Model for the Database

Let’s start by codding the Model that will represent our table!

This step is crucial because we are modeling our problem and it’s important that we discuss this thoroughly to get a model that efficiently defines our data and allow us to have a simple and performant representation of the problem’s data.

This is a really simple app, so we are just storing a given temperature and a related date. Since this is simple to model we’re going to use a simple table containing these values and a unique identifier for each new value.

Installing `Fluent` and `Postgres Driver`

We’re going to use an ORM to communicate with our database, this is a great tool that allow us to stay in Swift when making queries, models and relationships. In our case we decided to use Fluent and a Postgres Driver.

To install them, follow the next steps:

Open Package.swift
Add the following lines in the dependencies array:

  .package(url: "https://github.com/vapor/fluent.git", from: "4.8.0"),
  .package(url: "https://github.com/vapor/fluent-postgres-driver.git", from: "2.8.0"),

Add the following inside the second dependencies array, nested inside targets:

.product(name: "Fluent", package: "fluent"),
.product(name: "FluentPostgresDriver", package: "fluent-postgres-driver"),

If you’re using a different database look into Fluent documentation to find an appropriate driver.

Your Package.swift should look similar to this:

// swift-tools-version:5.9
import PackageDescription

let package = Package(
    name: "temperature-logger",
    platforms: [
       .macOS(.v13)
    ],
    dependencies: [
        // 💧 A server-side Swift web framework.
        .package(url: "https://github.com/vapor/vapor.git", from: "4.83.1"),
        .package(url: "https://github.com/vapor/fluent.git", from: "4.8.0"), // added
        .package(url: "https://github.com/vapor/fluent-postgres-driver.git", from: "2.8.0"), //added
    ],
    targets: [
        .executableTarget(
            name: "App",
            dependencies: [
                .product(name: "Vapor", package: "vapor"),
                .product(name: "Fluent", package: "fluent"), // added
                .product(name: "FluentPostgresDriver", package: "fluent-postgres-driver") //added
            ]
        ),
        .testTarget(name: "AppTests", dependencies: [
            .target(name: "App"),
            .product(name: "XCTVapor", package: "vapor"),

            // Workaround for https://github.com/apple/swift-package-manager/issues/6940
            .product(name: "Vapor", package: "vapor"),
        ])
    ]
)

These new packages will be automatically added to our project.

Creating our Temperature model

The models we define in this step will be used to create the tables in our database.

Create a new file called Temperature.swift in the following path: Sources/App/Models/
Add the following code:

import Vapor
import Fluent

final class Temperature: Model, Content {
    static let schema: String = "temperatures"

    @ID
    var id: UUID?

    @Field(key: "temperature")
    var temperature: String

    @Field(key: "date")
    var date: String

    init() { }

    init(id: UUID? = nil, temperature: String, date: String) {
        self.id = id
        self.temperature = temperature
        self.date = date
    }
}

The property wrappers are defined in Fluent and let us mark the different roles for our database, the names inside @Field are used to represent the name of the columns in the table. The schema at the top will be used as the table name in our database.

Excellent, we have our schema defined.

Connecting the Postgres Database to our Vapor App

Oru next goal is to connect our database to our vapor app and create the schema for our system.

Creating the Migration file

Migrations serve the purpose of defining and applying changes to the database schema. A migration is essentially a set of instructions that describe how to evolve the database structure, creating or modifying tables and their columns.

To create our own migration file follow the next steps:

Create the file CreateTemperature.swift in the path: Sources/App/Migrations/
Add the following code:

// To run migrations, call `swift run App migrate` from the command line

import Fluent

struct CreateTemperature: AsyncMigration {
    func prepare(on database: Database) async throws {
        try await database.schema("temperatures")
            .id()
            .field("temperature", .string, .required)
            .field("date", .string, .required)
            .create()
    }
    
    func revert(on database: Database) async throws {
        try await database.schema("temperatures")
            .delete()
    }
}

The prepare function is part of the migration and specifies what changes to make to the database when applying the migration. In simple terms, it says:

Create a new table named ’temperatures'.
Add an ‘id’ column (which is typically an identifier for each row in the table).
Add a ’temperature’ column of type ‘string’ that is required.
Add a ‘date’ column of type ‘string’ that is also required.
Ensure that all these changes are applied to the database.

The revert function is part of the migration and specifies how to undo the changes made by the prepare function. In simple terms, it says:

Delete the ’temperatures’ table from the database.

Setting-up the Postgres Database

We need to configure the credentials for our Postgres database. To do this we need to open the file configure.swift inside the path: Sources/App/.

Add the packages needed at the top of the file:

import Fluent
import FluentPostgresDriver

Add the following code at the top inside the configure function:

The data for these credentials are defined in the docker-file of the database. If you’re hosting your database in a system other than localhost, use your URL in place of localhost.

// defining the postgres configuration object
let databaseConfiguration = SQLPostgresConfiguration(
    hostname: "localhost",
    username: "user",
    password: "password",
    database: "postgres",
    tls: .disable
)

// applying the configuration
app.databases.use(
    .postgres(configuration: databaseConfiguration), as: .psql
)

// Adding our migration object
app.migrations.add(CreateTemperature())

// Optional, make the logger more verbose
app.logger.logLevel = .debug

Your configuration.swift should look similar to this:

import Vapor
import Fluent
import FluentPostgresDriver

// configures your application
public func configure(_ app: Application) async throws {
    // uncomment to serve files from /Public folder
    // app.middleware.use(FileMiddleware(publicDirectory: app.directory.publicDirectory))

    // defining the postgres configuration object
    let databaseConfiguration = SQLPostgresConfiguration(
        hostname: "localhost",
        username: "user",
        password: "password",
        database: "postgres",
        tls: .disable
    )

    // applying the configuration
    app.databases.use(
        .postgres(configuration: databaseConfiguration), as: .psql
    )

    // Adding our migration object
    app.migrations.add(CreateTemperature())

    // Optional, make the logger more verbose
    app.logger.logLevel = .debug


    // register routes
    try routes(app)
}

Now stop the app and run the following commands to apply the migrations and get the database connected.

# Stop the project by pressing CTRL + C
swift run App migrate # to start migration

Creating the endpoints

We’re about to finish the backend for our iOS app. This backend is quite simple, it will expose a GET method that will return all the stored temperatures in the database and a post method that will allow us to save a temperature sent from our iOS app.

Since we are only using two endpoints we can add this logic to the file routes.swift, found in the path temperature-api/Sources/App/.

Open the file and add the following modules:

import Fluent
import FluentPostgresDriver

Next, inside the routes function, delete all its body and add this:

 app.get("temperatures") { req async throws in
    app.logger.info("Temperatures GET received.")
    return try await Temperature.query(on: req.db).all()
}

app.post("temperatures") { req async throws -> Temperature in
app.logger.info("Temperature POST request received.")
    let temperature = try req.content.decode(Temperature.self)
    try await temperature.create(on: req.db)
    return temperature
}

Your routes.swift file should look like this:

import Vapor
import Fluent
import FluentPostgresDriver


func routes(_ app: Application) throws {
     app.get("temperatures") { req async throws in
        app.logger.info("Temperatures GET received.")
        try await Temperature.query(on: req.db).all()
    }

    app.post("temperatures") { req async throws -> Temperature in
        app.logger.info("Temperature POST request received.")
        let temperature = try req.content.decode(Temperature.self)
        try await temperature.create(on: req.db)
        return temperature
    }
}

GET Route for “temperatures”:

When the server receives a GET request at the path "/temperatures", it logs an informational message saying "Temperatures GET received.".
It then attempts to retrieve all temperature records from the database asynchronously using try await Temperature.query(on: req.db).all().

POST Route for “temperatures”:

When the server receives a POST request at the path "/temperatures", it logs an informational message saying "Temperature POST request received.".
It then tries to decode the request’s content into a Temperature model object using let temperature = try req.content.decode(Temperature.self).
After decoding, it attempts to create a new temperature record in the database asynchronously with try await temperature.create(on: req.db).
Finally, it returns the created Temperature object as a response.

Congratulations, you’ve finished your backend using Vapor!

Run it with swift run and let’s test it!

Testing our backend

For testing our backend I’m using Postman.

First let’s try the GET, since the database is empty it should return an empty array [].

Now let’s test the POST by adding some data.

Finally, let’s check GET again to verify we get the new stored data from the DB.

Great, our backend is working as expected.

Let’s continue with the iOS app, great work!

Coding the iOS App

Let’s start our iOS app that will connect to our vapor backend.

One of the most used design patters for SwiftUI is MVVM, this stands for Model, View and ViewModel.

Model: Represents the application’s data and business logic. It is responsible for managing and manipulating the data, as well as enforcing business rules.

View: Represents the user interface and is responsible for displaying data to the user. It observes changes in the ViewModel and updates accordingly. In some implementations, the View may also handle user input and pass it to the ViewModel.

ViewModel: Acts as an intermediary between the Model and the View. It contains the presentation logic and transforms the data from the Model into a form that can be easily displayed by the View. The ViewModel often exposes properties and commands that the View can bind to.

The key point is that the ViewModel doesn’t tell the view what to do; it just receives queries from the view. When the data is ready, it notifies the subscribers, mostly views, about the changes. Then, the views that get the notifications can act accordingly with the new data received.

Let’s create a new iOS SwiftUI project in Xcode to continue, we could name it Temperatures App or anything you like.

Creating the Model

Let’s start with the Model, this model would be quite similar to the one in our backend.

Let’s create a new Group called Models and inside this group create a new file called Temperature.swift.

import Foundation

struct Temperature: Codable, Identifiable {
    var id: UUID = UUID()
    var temperature: String = ""
    var date: String = ""
}

This is the model our app will use when creating new temperatures locally. The code acts similarly to the one in the backend; we define a new ID for each new temperature and store the temperature and date for that measurement.

We use Identifiable to make every temperature object uniquely identifiable. This is useful in the SwiftUI ForEach view.

The Codable protocol guarantees that our data can be encoded and decoded, in our case, to and from JSON.

Creating the Network Layer

The network layer is next; this layer will handle the communication with the server.

Creating the Request Protocol

Let’s start by defining a protocol that will tell us the public API for a network request. The network request will handle all the information needed by the network service to perform its work.

Create a new group called Networking and inside create a new file called NetworkRequestProtocol.swift. Then add this code:

import Foundation

protocol NetworkRequestProtocol {
    var url: URL { get }
    var method: String { get }
    var headers: [String: String]? { get }
    var body: Data? { get }
}

As mentioned before, these are the elements we will need to pass to the network manager to be able to send requests to our backend:

The URL of our backend.
The type of HTTP method we want to use.
The headers for our requests.
The body of our request in case of POST.

Creating the Temperature Request

Now let’s conform to this protocol. Create a new file called TemperatureRequest.swift in the Networking group and add the following code:

import Foundation

enum TemperatureRequest: NetworkRequestProtocol {
    case post(temperature: Temperature)
    case get

    var url: URL {
        switch self {
        case .get: URL(string: "http://localhost:8080/temperatures") ?? URL(string: "https://apple.com")!
        case .post: URL(string: "http://localhost:8080/temperatures") ?? URL(string: "https://apple.com")!
        }
    }

    var method: String {
        switch self {
        case .get: "GET"
        case .post: "POST"
        }
    }

    // no matter the selected case we always return the same header
    var headers: [String : String]? {
        ["Content-Type": "application/json"]
    }

    var body: Data? {
        switch self {
        case .get: nil
        case .post(let temperature): try? JSONEncoder().encode(temperature)
        }
    }

}

We’re making this app simple, so we are not defining custom errors.

enums are great for handling our network request parameters. Here, TemperatureRequest conforms to NetworkRequestProtocol. This is great because we can change our request object with a different one by only conforming to the same protocol. This helps to lower code coupling and improves testability.

The code itself configures the GET and POST method data. In the case of POST, we send the Temperature object and convert it into a proper JSON type for our backend. The rest of the code is self-explanatory.

Creating the Network Service Protocol

As mentioned before, protocols are a great way to lower coupling in code and help with testability because we can create mock objects that can simplify our tests for different parts of the code.

Let’s create a new file called NetworkServiceProtocol.swift in the Networking group and add this code:

import Foundation

protocol NetworkServiceProtocol {
    func execute(request: NetworkRequestProtocol) async throws -> Data
}

As before, we are defining the public API for this object. In this case, we only have one function that will execute the request using the request data we pass.

Creating the Network Service

The Network service is the final component we need to implement in our Network layer. This object is responsible for doing the actual communication with the backend. To configure our request, we pass a TemperatureRequest object with the parameters we need.

In the same Networking group, create a new file called NetworkService and add the following code:

import Foundation

struct NetworkService: NetworkServiceProtocol {
    func execute(request: NetworkRequestProtocol) async throws -> Data {
        // configuring the request
        var urlRequest = URLRequest(url: request.url)
        urlRequest.httpMethod = request.method
        urlRequest.allHTTPHeaderFields = request.headers
        urlRequest.httpBody = request.body

        // performing the request, we wait for the server response
        let (data, _) = try await URLSession.shared.data(for: urlRequest)
        
        // returning the data from the server
        return data
    }
}

In simpler terms the code above does the following:

Implementing the protocol NetworkServiceProtocol
execute function: takes a NetworkRequestProtocol as a parameter and performs a network request to our backend.
URLRequest setup: Inside the execute function, a URLRequest is created using information from the provided NetworkRequestProtocol, such as the URL, HTTP method, headers, and request body.
Network request: The function then uses URLSession.shared to perform an asynchronous network request based on the constructed URLRequest. It awaits the response and extracts the obtained data.
Return data: Finally, the obtained data is returned from the function.

Notice that this layer is not responsible of converting the json data to the proper type for our app.

Creating the View Model

To create the View Model, we need to create a new group called ViewModels and inside this new group create a new file called TemperaturesViewModel.swift. Add the following code to this file:

import Foundation

@MainActor // Runs this code in the main thread to avoid updating the UI outside of it.
final class TemperatureViewModel: ObservableObject {
    @Published private(set) var temperatures: [Temperature]
    private let networkService: NetworkServiceProtocol
    
    // Injecting dependencies
    init(temperatures: [Temperature] = [], networkService: NetworkServiceProtocol) {
        self.temperatures = temperatures
        self.networkService = networkService
    }
    
    /// POST a new temperature to the backend.
    func addTemperature(temperature: String, date: String) async {
        let newTemperature = Temperature(temperature: temperature, date: date)
        let request = TemperatureRequest.post(temperature: newTemperature)
        do {
            let _ = try await networkService.execute(request: request)
        } catch {
            print("Error adding temperature")
        }
    }
    
    /// GET all stored temperatures in the backend.
    func getTemperatures() async {
        let request = TemperatureRequest.get

        // perform request
        do {
            let data = try await networkService.execute(request: request)

            // decode data
            guard let decodedData = decodeData(data: data) else { return }
            print(decodedData)
            // saving data on published var
            temperatures = decodedData
        } catch {
            print("Some error in get")
        }
    }
}

// MARK: - Helper private functions
private extension TemperatureViewModel {
    func decodeData(data: Data) -> [Temperature]? {
        do {
            return try JSONDecoder().decode([Temperature].self, from: data)
        } catch {
            print("Error decoding temperatures")
            return nil
        }
    }
}

This code may seem complex, but in reality, it is just doing two things: sending data back to the server and getting data from the server. This happens in the methods addTemperature and getTemperatures.

Then we are publishing the values with @Published private(set) var temperatures: [Temperature], so any object that subscribes to updates can get a notification for changes in this variable. Notice the private(set), this allows read-only access to the value.

All of this is handled in the main thread to avoid updating the UI in a different thread by marking the object with @MainActor.

addTemperature function: This function is responsible for sending a new temperature to the backend using a POST request:

It creates a new Temperature object with the provided temperature and date.
It creates a TemperatureRequest for a POST request, encapsulating the new temperature data.
It tries to execute the request asynchronously using the networkService.
If an error occurs during the request execution, it catches the error and prints an error message.

getTemperatures function: This function is responsible for fetching all stored temperatures from the backend using a GET request:

It creates a TemperatureRequest for a GET request.
It tries to execute the request asynchronously using the networkService.
If the request is successful, it decodes the received data into an array of Temperature objects using the decodeData function.
It prints the decoded data and assigns it to the temperatures property, which is likely a @Published property that updates the UI when changed.
If an error occurs during the request execution, it catches the error and prints an error message.

Creating the Views

Now it’s time to see something on our phone’s screen. Let’s create a new group called Views. Here, we are going to add all the views for our app.

The system will have two views: one for creating new temps and the other for viewing the current temperatures stored in our system. To manage the navigation of these two views, we are going to use a tab navigation style. Since the tab view doesn’t have a title, we’re going to use a title view that will help us to name our screens. This also allows us to customize the screens to our liking.

So, let’s create these three SwiftUI files inside Views. Let’s call them:

RootView.swift: Our tab view will be here.
PostTemperaturesView.swift: It will display a simple UI to send the data to the server.
GetTemperaturesView.swift: It will display a simple table with the temperatures from the server.
TitleView.swift: A helper view that will display the title of the current view.

Creating `TitleView`

The easiest view for this app is the TitleView. It will be a simple view that displays formatted text on the screen.

Add this code to TitleView.swift:

import SwiftUI

struct TitleView: View {
    let title: String

    var body: some View {
        Text(title)
            .font(.largeTitle)
            .fontWeight(.bold)
            .padding()
    }
}

#Preview(traits: .sizeThatFitsLayout) {
    TitleView(title: "Custom Title")
}

In this view we are just applying some font styles to the given title.

Creating `PostTemperaturesView`

This view will present the user with a button and two fields for the temperature and date. We are implementing some extremely basic validation that will disable the button if both text fields are empty. In a production app, we should validate against edge cases and be more thoughtful.

Add the following code to PostTemperaturesView.swift:

import SwiftUI

struct PostTemperaturesView: View {
    @State private var temperature = Temperature()
    @EnvironmentObject private var temperatureViewModel: TemperatureViewModel

    var body: some View {
        ZStack {
            VStack {
                TitleView(title: "Post your temperature")
                Divider()
                Spacer()
            }
            VStack {
                inputSection()
                    .padding()
                buttonSection()
            }
        }
    }
}

#Preview {
    PostTemperaturesView()
}

private extension PostTemperaturesView {
    
    /// Checks if the temperature components are empty or not.
    var invalidTemperatureData: Bool {
        temperature.date.isEmpty || temperature.temperature.isEmpty ? true : false
    }
    
    /// Based on the validity of the temperature object, it returns a specific color.
    var buttonBackground: Color {
        invalidTemperatureData ? .gray : .red
    }
    
    func inputSection() -> some View {
        VStack(spacing: 20) {
            TextField("Temperature", text: $temperature.temperature)
                .padding()
                .background(.gray.opacity(0.2))
                .clipShape(RoundedRectangle(cornerRadius: 15.0))
            TextField("Date", text: $temperature.date)
                .padding()
                .background(.gray.opacity(0.2))
                .clipShape(RoundedRectangle(cornerRadius: 15.0))
        }
        .frame(width: 130, height: 120)
        .padding()
        .overlay(
            RoundedRectangle(cornerRadius: 25.0)
                .stroke(.red, lineWidth: 3)
        )
    }

    func buttonSection() -> some View {
        Button {
            Task {
                await temperatureViewModel.addTemperature(
                    temperature: temperature.temperature,
                    date: temperature.date
                )
            }

        } label: {
            Text("POST Temperature")
                .foregroundStyle(.white)
                .frame(maxWidth: .infinity, maxHeight: .infinity)
        }
        .disabled(invalidTemperatureData)
        .frame(width: 230, height: 60)
        .background(buttonBackground)
        .clipShape(RoundedRectangle(cornerRadius: 25.0))
    }
}

Since we are not reusing any of the sub-views, I decided to implement them in private functions. This helps to lower the code complexity since all sub-views will have direct access to the parent view properties.

To call async functions in our views, we need to create an asynchronous context. To do that, we use Task { ... }. Inside a task, we can call our async functions from the view model. The main advantage of this is that we don’t block our UI by waiting for the response.

The rest of the code is self-descriptive thanks to the declarative aspect of SwiftUI.

Creating `GetTemperaturesView`

Since we need to get the current data from the server, I’m attaching a .task action that executes every time the view is rendered. This will download the most up-to-date data from the server. Then we will display this information in a formatted table.

In production apps, it’s important to manage possible errors and inform the users visually about the current state of the task. For this small app, we are not managing that aspect.

import SwiftUI

struct GetTemperaturesView: View {
    @EnvironmentObject private var temperatureViewModel: TemperatureViewModel

    var body: some View {
        VStack {
            TitleView(title: "Recorded Temperatures")
            Divider()
            List {
                ForEach(temperatureViewModel.temperatures) { temp in
                    row(temperature: temp)
                }
            }
            .listStyle(.plain)
            .task {
                await temperatureViewModel.getTemperatures()
            }
        }
    }
}

#Preview {
    GetTemperaturesView()
        .environmentObject(TemperatureViewModel(networkService: NetworkService())) // needed for the preview not to crash
}

private extension GetTemperaturesView {
    func row(temperature: Temperature) -> some View {
        VStack {
            Text("Date: \(temperature.date)")
            Text("Temperature: \(temperature.temperature) \u{2103}")
        }
    }
}

As before, thanks to the declarative nature of SwiftUI, the code is self-explanatory.

Creating `RootView`

Finally, let’s piece together all the views and complete our UI.

This last part is quite simple to implement, thanks to the way SwiftUI works. Add the following code to the file RootView.swift:

import SwiftUI

struct RootView: View {
    var body: some View {
        TabView {
            PostTemperaturesView()
                .tabItem { Label("POST", systemImage: "square.and.arrow.up") }
            GetTemperaturesView()
                .tabItem { Label("GET", systemImage: "square.and.arrow.down") }
        }
        .tint(.red) // change button color in tab
    }
}

#Preview {
    RootView()
        .environmentObject(TemperatureViewModel( networkService: NetworkService()))
}

Here we are creating the tab view and assigning the post and get views we created early in this tutorial.

Configuring the Environment Object

You may have noticed that some of our views need an Environment object. In the preview, the app works well, but if you try to run it, the app will crash because we are only injecting this object into the preview context. Let’s fix that now.

Open the entry point app file. It’s the one named as your app and contains the attribute @main.

Inside the struct, let’s add the view model we will be observing:

@StateObject private var temperatureViewModel = TemperatureViewModel(networkService: NetworkService())

Next let’s change our View entry point to the RootView we just created, and inject the environment object. This will allow access to the ViewModel to RootView and all of its sub-views.

We’re also attaching an initial get to our backend, this will get us an up to date temperatures each time our app starts.

WindowGroup {
            RootView() // change to our RootView
                .environmentObject(temperatureViewModel) // inject the ViewModel
                .task { // When open the app, perform an initial GET to the server.
                    await temperatureViewModel.getTemperatures()
                }
        }

Your file should look like something like this, (your struct may have a different name):

import SwiftUI

@main
struct temperature_logger_App: App {
    @StateObject private var temperatureViewModel = TemperatureViewModel(networkService: NetworkService())

    var body: some Scene {
        WindowGroup {
            RootView()
                .environmentObject(temperatureViewModel)
                .task {
                    await temperatureViewModel.getTemperatures()
                }
        }
    }
}

Congratulations! You just finished the app!

Testing the App

To test the app, you need to have the Vapor app and the database containers running. Verify that they are up and running.

Now, let’s run the app on the simulator and add some temperatures. Then, check the list to see how they update in real-time!

You can also view the logs in our Vapor app to see the requests we are receiving from our app.

Conclusion

In concluding our exploration of building a full-stack iOS application, the versatility of Swift has truly shone through. Swift not only excels in crafting engaging iOS applications but also seamlessly extends its capabilities to backend development, as demonstrated by the integration with the Vapor framework.

The collaboration between the iOS app and the Vapor backend illustrates the straightforward nature of Swift in the development landscape. The use of Docker for containerization further streamlined the setup, enabling a hassle-free configuration of a PostgreSQL database synchronized with the Vapor app. This amalgamation of Swift, Docker, and Vapor reflects the smooth interplay of modern development tools.

This experience emphasizes Swift’s adaptability, not just in the iOS environment but also in Linux setups, where it effortlessly integrates and collaborates with container technologies like Docker. Swift emerges as a pragmatic choice for end-to-end development.

As we wrap up the journey of creating a full-stack iOS application, it’s worth acknowledging Swift’s role in orchestrating various technologies. It showcases how Swift fosters a developer-friendly environment, encouraging innovation and blurring the lines between frontend and backend development. Here’s to the practicality of Swift and the possibilities it unlocks in the ever-evolving landscape of software development!

Fully Reload Websites in Safari

Fri, 22 Dec 2023 01:40:53 +0000

One common challenge encountered during frontend development is the persistence of cached data in web browsers.

While browser caches efficiently save time by storing assets and eliminating the need to download them on every website visit, they can pose problems during development when changes are made to the code.

How to Force a Full Reload in Safari with All Assets

In Safari, resolving this issue is a straightforward process.

Ensure that Developer Tools are enabled by pressing CMD + ,. Next, navigate to the Advanced tab, and at the bottom of the window, select Show features for web developers. Now you can close this settings window.

To perform a full reload, simply press CMD + OPT + R (Safari 11+). This action reloads the current page, bypassing any cached data present in Safari.

Conclusion

By incorporating this simple tip into our workflow, we can enhance efficiency in frontend development, particularly when dealing with assets.

It can be frustrating not to see updated images, leading us to question our code. However, in many cases, it’s just the cache doing its job.

I trust this brief post proves helpful in resolving such issues.

Until next time!

Deleting Duplicates Subdirectories and Content

Fri, 22 Dec 2023 01:13:31 +0000

The other day, I encountered an issue involving three directories, and two of them contained a subdirectory with the same name (target).

My goal is to delete the target subdirectories in all places with a single command, and here’s the solution I found.

Using the terminal to delete multiple directories.

There is an useful command called find, this command is used to traverse nested directories and evaluate an expression for each element.

We can use find to delete files or directories, here is the command:

find . -type d -name "target" -exec rm -rf {} +

Understanding the command

This command is easy to grasp, first we have ., this is telling find to start traversing in the current directory.

Next we have -type, this argument allows to select a a specific valid type.

The valid types are listed below:

b: block special
c: character special
d: directory
f: regular file
l: symbolic link
p: FIFO
s: socket

Since we need to find an specific directory we use d.

Next it’s -name, we need to give the string that contains the name we are searching for. In our case we are looking for the directories named "target".

The last part of the command, -exec, is telling what to do once we find a valid element. In this case we want to delete all the found occurrences, so we’re passing rm -rf.

The {} is just telling that we need to use the current element’s name, and + is used to terminate the -exec part.

Conclusion

By using this simple command we can find and delete subdirectories in an easy and convenient way, which I find to be faster than using the GUI.

I hope this simple tutorial can help you to solve these kind of problems.

Containerize Haskell

Thu, 21 Dec 2023 11:43:00 +0000

Let’s continue our exploration of the wonders of local development with containers.

This time, we’ll delve into the world of Haskell programming. Instead of burdening your local environment with the entire toolchain, we’ll opt for a more streamlined approach: creating a dev container. This example will illustrate how effortlessly you can integrate new tools and programming languages without causing any disruptions to your local system.

What is Haskell

Haskell, a pure functional programming language, though not as commonly used in the industry, is a powerful language whose fundamentals can significantly enhance your programming skills.

However, Haskell comes with a complex toolchain and numerous dependencies, potentially posing challenges for some systems. If you’re not a professional Haskell developer, the process of installing all these tools may not be worthwhile.

This is where dev containers come to the rescue, allowing you to sidestep these issues while still enabling you to experiment with Haskell. Let’s get started.

Personally, I find Haskell to be a fascinating language that offers valuable insights into novel techniques and encourages a different perspective on problem-solving. Experimenting with Haskell has been particularly enjoyable for me, providing a unique opportunity to broaden my understanding and approach to coding challenges.

Creating the Haskell dev container

As usual, we start by creating our local directory with a child directory called .devcontainer, inside this dir let’s create a new file called devcontainer.json, then add this code.

{
    "name": "Haskell Base",
    "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
    "customizations": {
        "vscode": {
            "extensions": [
                "haskell.haskell",
                "visualstudioexptteam.vscodeintellicode",
                "visualstudioexptteam.intellicode-api-usage-examples",
                "streetsidesoftware.code-spell-checker"
            ]
        }
    },
    "postCreateCommand": "zsh .devcontainer/installation.sh",
    "runArgs": ["--name", "haskell_devcontainer"]
}

Let’s break down its key elements:

The name field is set to “Haskell Base,” providing a recognizable identifier for this development environment.

The image field points to the Docker image “mcr.microsoft.com/devcontainers/base:ubuntu.” This image serves as the foundation for the development environment.

Within the customizations section, various Visual Studio Code extensions are specified. These extensions enhance the Haskell development experience.

The postCreateCommand field designates a post-creation command that runs after the dev container is set up.

Finally, the runArgs field supplies extra arguments for the docker run command when initiating the dev container. It assigns the name “haskell_devcontainer” to the container for easy identification.

As you may have noticed, we need to create a script to install Haskell in our container. To craft this file, we follow the instructions provided by the Haskell page. This shows us how we can easily configure our container as if it were a standard local installation. This shows the power and simplicity of working with local containers.

Within the .devcontainer directory, create a new file named configuration.sh and insert the following code into this newly created file.

#!/bin/zsh

sudo apt update
sudo apt install -y build-essential curl libffi-dev libffi8ubuntu1 libgmp-dev libgmp10 libncurses-dev libncurses5 libtinfo5

curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org | sh

echo 'export PATH="$PATH:$HOME/.ghcup/bin"' >> ~/.zshrc
source ~/.zshrc

echo 'export PATH="$PATH:$HOME/.ghcup/bin"' >> ~/.bashrc
source ~/.bashrc

echo "IMPORTANT: If bash doesn't find cmds, run: source ~/.bashrc"

In this script, we’re simply adhering to the installation recommendations provided by the official Haskell documentation for Linux. no extra steps or magic is needed for the container; we can treat it just like a local installation.

After preparing this, open your project in a dev container, go through the setup process (simply respond with ‘Y’ to all questions), and you’re all set to delve into Haskell on your machine.

Testing Haskell

Let’s create a simple program to test our envirment. Create a new file called “main.hs” and add the following code.

main = do
    putStrLn "What is 2 + 2?"
    x <- readLn
    if x == 4
        then putStrLn "You're right!"
        else putStrLn "You're wrong"

Now let’s run it by importing it to the interpreter

ghci main.hs

The ghci REPEL will open, now let’s run our function by just calling its name inside ghci

main

This will ask you for an input and will print the result

What is 2 + 2?
4
You're right!

Congratulation, your Haskell environment is working correctly!

Conclusion

In this exploration of local development with containers, we’ve ventured into Haskell programming, sidestepping the complexities of the language’s toolchain by creating a streamlined dev container. Despite Haskell’s relative industry underuse, its power for skill enhancement remains evident.

Dev containers prove invaluable, allowing us to experiment freely with Haskell without the hassle of extensive toolchain installations. Crafting a Haskell dev container is straightforward, following the official documentation to seamlessly configure it as a standard local installation.

Our simple program confirms that our setup is working correctly. With this, your Haskell environment is ready for exploration. Happy coding!

LeetCode – Two Sum II

Tue, 19 Dec 2023 09:05:39 +0000

Hey there! Today, let’s dive back into the world of LeetCode problems with Swift.

After successfully conquering the Two Sum problem, we’re geared up to take on the next challenge: Two Sum II.

To make things interesting, let’s explore this problem using a two pointers technique. Ready to tackle it together?

Problem

We are given an array of numbers sorted in non-decreasing order (this means each element is greater or equal to the preceding one) and a target value.

We are asked to find two numbers in the array such that the sum of them is equal to the target value and return those indices.

Here is an example:

Input: numbers = [2,7,11,15], target = 9
Output: [1,2]

Note: The index count specified in the problem starts at 1, not 0.

In this case, the values at indices 1 and 2 sum up to 9. Therefore, the expected output is the array [1,2] representing these indices.

Note: There is always exactly one solution, elements cannot be repeated, and the solution must be achieved using constant extra space.

Solution

For my solution, I opted to leverage the ordered nature of the list by employing a two-pointer approach. With the assurance that the list is already sorted, I establish two pointers. These pointers dynamically adjust based on whether the sum of the elements they point to is smaller or greater than the target. This strategy proves effective in navigating the sorted array efficiently.

func twoSum(_ numbers: [Int], _ target: Int) -> [Int] {
    var left = 0 // pointer at the beginning of the list
    var right = numbers.count - 1 // pointer at the end of the list
    
    // iterating till both pointers are side by side
    while left < right {
        let sum = numbers[left] + numbers[right]
        if sum  > target {
            // since sum is bigger than target we need to make the sum smaller
            right -= 1
        } else if sum < target {
            // since sum is smaller than target we need to make the sum bigger
            left += 1
        } else {
            // we found the two indices, return them
            return [left + 1, right + 1]
        }
    }
    // no indices found, return nothing
    return []
    }

This code efficiently identifies the two indices by employing two pointers initialized at the end of the list. Leveraging the sorted nature of the list, the pointers are strategically moved as needed until a valid solution is found.

The code is well-commented to elucidate each step, and given its straightforward nature, additional explanation may not be necessary.

Conclusion

Wrapping up our exploration of the Two Sum II problem in Swift, we utilized a handy technique known as ’two pointers.’ The inherent order of the list allowed us to smartly navigate through elements, efficiently narrowing down potential pairs that add up to the target value.

Swift’s simplicity and expressiveness played well with this approach, allowing us to implement a clean and concise solution. The language’s array handling, combined with the straightforward syntax, offered a seamless experience in dealing with the intricacies of the problem.

No need for any Swift promotional banner here—just appreciating how the language’s features naturally complemented our strategy. Swift or not, exploring these algorithmic challenges keeps our coding skills sharp and our problem-solving toolkit diverse. Ready for the next challenge?

Programming inside a Developer Container

Mon, 18 Dec 2023 09:00:30 +0000

Hello devs,

I’ve recently been exploring the synergy between Docker and VSCode for local development. The concept of consolidating code and dependencies into containers has caught my attention. This approach not only establishes a clean slate for each project but also promotes a stateless system, a goal that aligns seamlessly with my coding environment.

To explore these ideas further, let’s create a small project: containerizing an installation of Hugo. This way, we can run our own dev blog anywhere without worrying about configuration and compatibility issues. It sounds great, so let’s dive into the code and make it happen!

What are Dev Containers?

Dev containers, a feature in VSCode, empower us to use local containers for programming, seamlessly configured with both our dependencies and code. This operates under the hood, allowing us to open our projects within these containers and easily push changes to platforms like GitHub.

In essence, we work as if we were coding locally, avoiding any impact on our real system. Once our work is complete, we can delete these containers from our system without any repercussions. The magic doesn’t stop there—having a reproducible environment enhances teamwork among developers. Now, we can ensure the same environment, regardless of the system in use, eliminating the classic “it works on my machine” scenario.

It’s truly magical.

Prerequisites

To make this project, we only need two tools installed in our system:

Docker (local or remote works, in this tutorial we assume it’s installed locally)
Visual Studio Code

I assume you’re familiar with containers, how Docker operates, and have a basic understanding of using Hugo

Creating the Initial Configuration

Let’s kick things off by establishing the working directory for our Hugo blog. Just as we would with any other project, we create a directory to store our code. This directory can be uploaded to GitHub, and you can manage it with Git as usual.

mkdir hugo_blog
code hugo_blog # opens our project in VSCode; if this doesn't work, add the 'code' command to your system

Once our directory is set up, let’s initialize Git to track our changes.

git init

Creating the Configuration for Our Dev Container

After preparing our base project, let’s set up the configuration files for dev containers. These files will be stored in a hidden directory named .devcontainer. Let’s start by creating it.

# Inside our project directory
mkdir .devcontainer

Now, let’s generate the JSON file that VSCode will utilize to configure and create the container for us. This file must be named devcontainer.json and should reside within the .devcontainer directory.

Configuring the Creation of the Container with Hugo

Now, let’s dive into the exciting part: configuring the container creation process with the Hugo toolchain. This step automates the installation of all the necessary components for our project. By doing this, we eliminate the need to worry about configuration and can seamlessly dive into our actual work.

To begin, let’s select a base image for our container. No need to fret about writing any docker-compose or Dockerfile. Everything is taken care of by the dev container.

Microsoft already offers several base images for our dev containers, let’s use their image for our project.

With devcontainer.json, we can specify the VSCode extensions we want installed in our container. Given that we are configuring a Hugo blog, let’s include a spell checker extension.

I’ve opted for alpine, a compact Linux system ideal for containers due to its small memory footprint. Now, let’s incorporate this configuration into our devcontainer.json.

{
    // The name for our Dev Container; note that this is not the actual Docker container name
    "name": "Entangled Dev Blog",
    // We can use any other image as a base, but let's stick with Alpine for this tutorial
	"image": "mcr.microsoft.com/devcontainers/base:alpine",
    // Configure tool-specific properties.
	"customizations": {
		"vscode": {
			"extensions": ["streetsidesoftware.code-spell-checker"]
		}
	},
    // runArgs can execute various commands; here, we use --name to assign a name to our Docker container
    "runArgs": ["--name", "entangleddev_devcontainer"],
}

Great job! Now, to run and work in our dev container, make sure you have the ms-vscode-remote.remote-containers extension installed. Once installed, click on the small >< icon at the bottom left of VSCode and select Reopen in container.

While this approach works, setting up everything manually each time can be tedious. Let’s add some automation to streamline the process. Additionally, we don’t have Hugo installed yet, so there’s a bit more work to be done.

At this point, consider pushing your changes to GitHub. Now, every time you clone your project and open it with VSCode, you can replicate this environment on any computer with Docker.

Installing Hugo

Our devcontainer.json still has some cool tricks up its sleeve—it can run commands once the container is created. This comes in handy for installing the needed dependencies and configuring our environment. To achieve this, we use "postCreateCommand". Unfortunately, this command only accepts a string with all the commands we want to execute in the terminal. Therefore, we’ll create a script to handle all the necessary configurations for us.

Before proceeding, we need to incorporate instructions in our devcontainer.json that will run once the container is created. To do this, replace the existing code in our JSON file with the following updated version:

{
    // The name for our Dev Container; note that this is not the actual Docker container name
    "name": "Entangled Dev Blog",
    // We can use any other image as a base, but let's stick with Alpine for this tutorial
	"image": "mcr.microsoft.com/devcontainers/base:alpine",
    // Configure tool-specific properties.
	"customizations": {
		"vscode": {
			"extensions": ["streetsidesoftware.code-spell-checker"]
		}
	},
    // runArgs can execute various commands; here, we use --name to assign a name to our Docker container
    "runArgs": ["--name", "entangleddev_devcontainer"],
    // Use 'postCreateCommand' to run commands after the container is created.
	"postCreateCommand": "ash .devcontainer/configuration.sh"
}

To install Hugo on Linux, we have several options. For Ubuntu, we could use a Snap (though it might not work inside containers), but we’ll opt for getting a precompiled program from its official GitHub page and configuring it. We’ll be going with the latter.

Let’s start by creating a shell script to handle our configuration. Within the .devcontainer directory, create a new file named configuration.sh and insert the following code:

#!/bin/ash
echo "==> Starting container post-installation"
sudo apk update
sudo apk add --no-cache python3 py3-pip wget git tar
pip3 install requests
python3 .devcontainer/download.py
echo "==> Finished container post-installation"

Here’s a breakdown of what the code accomplishes:

Alpine employs apk instead of apt.
Given Alpine’s minimalist nature, we include the necessary dependencies for our container.
To simplify data retrieval from the GitHub server, we’ll create a Python script named download.py.

Continuing, let’s create our Python script that will handle the download and unpacking of Hugo. Within the .devcontainer directory, create a new file name download.py and insert the following code:

import json
import requests
import os

class HugoInstaller:
    def __init__(self):
        self.response = None
        self.asset_url = ""
        self.keyword = "arm64.tar.gz"
        self.package_name = ""
        self.dir = "/usr/local/bin/hugo_data"


    def start_installation(self):
        self._configure_git()
        self._download_hugo()
        self._unzip_installer()
        self._install_hugo_theme()  


    def _configure_git(self):
        os.system('git config --global user.name "Docker Container"')
        os.system('git config --global user.email "docker-container@local.com"')


    def _download_hugo(self):
        url = "https://api.github.com/repos/gohugoio/hugo/releases/latest"

        self.response = requests.get(url)

        if self.response.status_code == 200:
            json_data = self.response.json()

            assets = json_data["assets"]
            self.asset_url = ""
            
            for asset in assets:
                file_name = asset["name"]
                if self.keyword in file_name:
                    self.asset_url = asset["browser_download_url"]
                    self.package_name = asset["name"]
                    break
            os.system(f"sudo mkdir {self.dir}")
            os.system(f"sudo wget -P {self.dir} {self.asset_url}")
        else:
            print(f"Failed to fetch data. Status code: {self.response.status_code}")


    def _install_hugo_theme(self):
        '''Skip this function if you don't have a theme selected for your Hugo site'''
        os.system("sudo git submodule update --init --recursive")
    

    def _unzip_installer(self):
        hugo_file_path = f"{self.dir}/{self.package_name}"
        os.system(f"sudo tar -xzvf {hugo_file_path} -C {self.dir}")
        os.system(f"sudo mv {self.dir}/hugo /usr/local/bin")
        os.system(f"sudo rm -r {self.dir}")


if __name__ == "__main__":
    installer = HugoInstaller()
    installer.start_installation()

Here’s a breakdown of what the code accomplishes:

HugoInstaller Class Initialization:
- Initializes the HugoInstaller class with default values for properties like response, asset_url, keyword, package_name, and dir.
start_installation Method:
- Calls private methods in sequence to initiate the installation process.
_configure_git Method:
- Configures global Git settings within the container to set user name and email.
_download_hugo Method:
- Fetches the latest release information for Hugo from the GitHub API.
- Parses the JSON response to extract the URL of the Hugo release asset containing the keyword “arm64.tar.gz.”
- Creates a directory (/usr/local/bin/hugo_data) for storing downloaded Hugo assets.
- Downloads the Hugo release asset and saves it in the designated directory.
_install_hugo_theme Method: (warning: call this method with your own theme or skip it altogether)
- Initializes and updates Git submodules, specifically used for installing Hugo themes.
_unzip_installer Method:
- Extracts the downloaded Hugo release asset from its tar.gz format.
- Moves the extracted hugo executable to /usr/local/bin for system-wide access.
- Removes the temporary directory used for the installation process.
__main__ Block:
- Instantiates the HugoInstaller class.
- Invokes the start_installation method to commence the installation process.

Now rebuild your container, and Hugo will be installed. Now, you can start working on your blog inside a container. Commit your changes, and you’re done.

Phew, this was a bit of code, but now you’ve containerized your blog with Hugo. You can clone and start your dev container on any machine you want and begin writing about your awesome development journey.

More Resources

To get more pre-configured images for your dev containers you can check out this GitHub repo by Microsoft here.

Conclusion

This straightforward example serves as a foundation for creating your custom development environment tailored to different purposes. The versatility extends to running docker-compose files for more intricate configurations.

I firmly believe that this stateless approach to local programming will gain increasing significance in the future. It addresses common issues encountered in team collaborations and personal projects by providing a clean system free from pollution. This enables experimentation with diverse tools and languages without compromising our actual systems.

While it’s worth noting a potential drawback of being tied to using VSCode, given its widespread adoption, most developers may find this limitation negligible compared to the considerable benefits.

I hope this inspires you to reconsider your approach to the local programming environment, offering new ways to enhance efficiency and safety in your work or hobby.

Thanks for reading, and happy coding!

Comparing Files in Vscode

Tue, 07 Nov 2023 16:58:58 -0600

Today, I’d like to share a simple trick for comparing the states of files using both the terminal and VSCode.

Comparing files

Typically, when we need to check for differences between two files, we can use git diff if the files are within a Git repository or simply diff if the files are local.

However, these commands lack a user-friendly interface for comparing files, which is where VSCode’s file comparison feature comes in handy.

Steps 👍

First, we need to obtain the file paths of the files we want to compare.
Open your terminal and run the following command: code --diff /path/fileA /path/fileB, then press Enter.

VSCode will open, displaying the differences between both files in a clear and user-friendly manner.

Additionally, any changes you make to the files during this comparison can be conveniently saved back to the original files.

Conclusion

For swift and efficient file comparison, VSCode provides a valuable graphical user interface (GUI). This nifty trick can save time and help prevent mistakes, as you can instantly see how your changes impact the differences between the files.

Balanced Parentheses in Strings

Wed, 25 Oct 2023 21:26:45 -0600

Today, I’d like to present a small algorithmic problem and some solutions I have come up with.

The problem is as follows: Given a string, determine if the parentheses are balanced.

Balanced parentheses mean that for every ( found, there must be a corresponding ) to balance it.

Input and output

It is guarantee that any given string will contain at least one parenthesis.

in: "(hello"
out: false

in: "(hello()world)()"
out: true

in: "hello()(())"
out: true

in: "()"
out: true

in: "("
out: false

Solutions

Using a Hash Table (Dictionary)

Let’s try a simple approach using a hash table.

We know that we need to have the same number of left and right parentheses at the end of a string traversal. If this doesn’t happen, then we can be sure that the string doesn’t have balanced parentheses.

We could use a hash table to count the occurrences of the left and right parentheses in the given string. Then we compare both results.

With this idea let’s implement a solution:

func balancedParentheses(_ str: String) -> Bool {
    var dic = [String: Int]()
    
    str.forEach { char in
        if char == "(" || char == ")" {
            // What does default do?
            // If the key doesn't exist add the key with an initial default value
            dic[String(char), default: 0] += 1
        }
    }
    
    return dic["("] == dic[")"]
}

This solution has a time complexity of $O(n)$.

The spatial complexity is $O(1)$, because we are always storing only two key-value pairs.

Discarding the hash table

The previous solution works for the given problem but we are creating an extra data structure that can add unwanted complexity, maybe using a hash table for this specific problem is overkill.

Let’s try a simpler approach.

func balancedParentheses(_ str: String) -> Bool {
    var counter = 0
    
    str.forEach { char in
        if char == "("  {
            counter += 1
        } else if char == ")" {
            counter -= 1
        }
    }
    
    return counter == 0
}

Now we are using an Int to keep a count of the parentheses. We add 1 for a left one and subtract 1 for the right one. If the number of left and right parentheses is equal, then we can be sure that the parentheses are balanced and the final count should be 0.

By eliminating the hash table, we archive a code that is simpler to reason about by avoiding unnecessary layers.

The time and space complexity remains the same.

Using Stacks

Another solution involves the use of Stacks, which can help us explore more advanced algorithmic techniques like backtracking.

Stacks are a common and useful data structure but are not implemented by default in Swift. They are typically implemented using an Array by restricting the insertion and deletion operations to the end of the structure.

To solve the given problem, we can use the Stack to store the left parentheses and popping only when a right parenthesis is found. As before, if the Stack finishes empty, then the parentheses in the string are balanced.

Let’s start by implementing the Stack.

struct Stack<T> {
    private var storage: [T] = []

    var isEmpty: Bool {
        storage.isEmpty
    }

    mutating func push(_ element: T) {
        storage.append(element)
    }

    @discardableResult
    mutating func pop() -> T? {
        storage.popLast()
    }
}

We mark pop with @discardableResult because we want to tell the program that we don’t care for the returned value and this can be discarded safely if we don’t assign it to any variable.

Now let’s implement the solution.

func balancedParentheses(_ str: String) -> Bool {
    var stack = Stack<Character>()
    
    for char in str {
        if char == "("  {
            stack.push(char)
        } else if char == ")" {
            if stack.isEmpty {
                return false
            } else {
                stack.pop()
            }
        }
    }
    
    return stack.isEmpty
}

We are using Character instead of String because the for in returns a single char when traversing the string.

Let’s explain in more detail our solution.

As mentioned before we add to the Stack all ( found.

If we find a ) two possibilities can arise:

The Stack state is empty.
The Stack state is not empty.

In the first case we didn’t find a matching parenthesis so we can be certain that the parentheses in the string are not balanced.

In the second case, we can pop the previous right parenthesis and continue looking for the next parentheses.

Now let’s focus on the last return, we are checking for the state of the Stack because the case of the Stack containing orphaned ( can occur, in that case the parentheses in the string are also not balanced.

The time complexity is $O(n)$ because we traverse the array only once.

The space complexity is $O(n)$ because in the worse case we would get a string containing only (, creating a stack with the same length as the string.

Conclusion

In this small problem, we’ve observed that using stacks can lead to an increase in memory consumption without providing significant benefits. In the case of hash tables, the complexity is similar to the counting approach.

For problems that are straightforward and don’t involve complex matching, a simpler approach often yields better results.

It’s essential to understand the constraints of the problem to weigh the advantages and disadvantages of our solutions and ensure that we select the most suitable option for the task at hand.

This way of thinking can help us avoid overengineering solutions that add unnecessary complexity without providing real benefits.

Working With Git Submodules

Wed, 25 Oct 2023 00:03:41 -0600

The other day, I was working on a project that had a Git submodule. Initially, I found it a bit tricky to make it work, so I decided to create a short tutorial on this.

What is a Git submodule

Essentially, a Git submodule is a way to include one Git repository inside another Git repository. This creates a nested structure.

So, in simple words, a Git submodule is like a mini Git repository that you can include in your main Git repository to use and update external code or resources without actually putting all of their files directly in your project.

The crucial point to note is that, by default, the code of the submodule is not added to your Git repository when performing the initial git clone.

How to check the ulr of the git submodule

To check the linked URLs of submodules we can use this command.

git config --file .gitmodules --get-regexp 'submodule\..*\.url'

How to clone a submodule

There could be three situations:

You want to clone the git project with all its submodules for the first time.
You’ve cloned the git project but didn’t fetch the submodules.
You want to update the submodules in your project.

Cloning a project with all submodules for the first time

If you want to clone a project for the first time with all its submodules, you can run the following command.

With Git version 2.13 or newer.

git clone --recurse-submodules -j8 https://github.com/your/repo.git

-j8 is an optional performance optimization that became available in version 2.8, and fetches up to 8 submodules at a time in parallel

Before Git 2.12.

git clone --recursive https://github.com/your/repo.git

Cloning the submodules only

If you’ve downloaded the project but forgot to fetch the submodules, you can use this command.

git submodule update --init --recursive

If you’ve cloned only the main Git repository, you’ll be missing the submodule files, potentially causing your project to fail.

Updating the submodules

If you want to update the code of the submodules, you need to run this command.

git submodule update --recursive --remote

This will only update the branch registered in the .gitmodule, and by default, you will end up with a detached HEAD, unless –rebase or –merge is specified or the key submodule.$name.update is set to rebase, merge or none.

Adding a submodule to a git repository

To add another remote Git repository as a submodule to your current Git repository, you can use this command.

git submodule add https://github.com/your/repo.git path/to_save/in_repo

The provided code allows you to specify the remote URL for the repository you want to use as a submodule, as well as the path within your project where you want to save the cloned code.

Delete a Git submodule from your project

This process is common but not that straightforward, here are the steps you need to do.

The files mentioned in the following steps are located in the root directory of your project, which is the default location for the Git files.

Delete the relevant line from the .gitmodules file.
Delete the relevant section from .git/config.
Run git rm --cached path_to_submodule (no trailing slash).
Commit and delete the now untracked submodule files.

A trailing slash is the slash that can be added to the end of the path. submodules/my_submodule/ has a trailing slash while submodules/my_submodule doesn’t have one.

Conclusion

Git submodules are a powerful feature for managing dependencies in your projects. They allow you to include external Git repositories within your main repository without cluttering it with their files. This can be especially handy when you’re working on projects that rely on external code or resources.

We’ve covered some essential aspects of working with Git submodules in this tutorial. You’ve learned what a Git submodule is and how to check the URLs of linked submodules. You also know how to clone a project with all its submodules, how to retrieve submodules if you’ve forgotten them, and how to keep them updated. Furthermore, we discussed adding and deleting a submodule from your Git repository.

With this knowledge, you’ll be better equipped to manage complex projects with Git submodules and streamline your workflow. So, don’t shy away from using them in your projects when they can help you manage external code more efficiently.

Happy coding 🚀!

Replacing Elements in a String

Mon, 09 Oct 2023 19:15:49 -0600

One of the most common problems we face when working with strings is modifying certain characters in the string.

This problem can be easily solved with the use of regular expressions (regex).

Before Swift 5.7

If you can’t uae the newest Swift you can achieve this by using the method replacingOccurrences(of:with:options).

Here is an example of its use:

let s = "12abc34"
let t = ss.replacingOccurrences(
    of: "[a-z]", // regex
    with: "",
    options: .regularExpression
)
// output: "1234"

If we want to do the opposite (i.e., to keep everything but lowercase letters), we can use the symbol ^ to invert the expression set.

let s = "12abc34"
let t = ss.replacingOccurrences(
   of: "[^a-z]", // regex
   with: "",
   options: .regularExpression
)
// output: "abc"

After Swift 5.7

If we have access to a newer version of swift, you can use a simpler method to achieve the same result: replacing(_:with:maxReplacements:).

let s = "12abc34"
let t = s.replacing(/[a-z]/, with: "")
// output: "1234"

As before, we can use ^ to obtain the inverse result:

let s = "12abc34"
let t = s.replacing(/[^a-z]/, with: "")
// output: "abc"

Conclusion

Regular expressions are quite powerful and can help us to solve problems with a simple predicate that describes what the want to obtain.

Regex may seems hard to grasp at first, but we can start with little examples like these to gain experience with this useful tool.

SwiftUI – Horizontal Pages Carousel

Wed, 27 Sep 2023 01:44:33 -0600

Horizontal page carousels are a common element in iOS interfaces for presenting pages in a horizontal, swipeable format.

They are particularly useful for showcasing views with varying content.

Code

In SwiftUI, creating such elements is straightforward.

Let’s define a SwiftUIView and use the following code:

import SwiftUI

struct PageSliderView: View {
    
    // the data we want to present in each page,
    // this can be as simple as an array of string or as complex as an array of compound views.
    let pages = ["One", "Two", "Three"]
    
    var body: some View {
        TabView {
            ForEach(pages, id: \.self) {
                Text("Page \($0)")
                    .font(.title)
            }
        }
        .tabViewStyle(PageTabViewStyle()) // set the tab view behaviour to page
        .indexViewStyle(PageIndexViewStyle(backgroundDisplayMode: .always)) // set the dot indicator to be visible
    }
}

#Preview {
    PageSliderView()
}

The code above showcases one of the advantages of declarative UI frameworks, where you describe what you want instead of instructing the computer how to do it.

This approach results in expressive and concise code.

Result

The outcome is impressive, especially when you consider the minimal code required.

Conclusion

SwiftUI is a powerful tool that enables us to focus on describing the UI. With just a few lines of code, we can achieve results that would necessitate significantly more code in UIKit.

Swift copy-on-write

Mon, 25 Sep 2023 01:30:20 -0600

To understand what copy-on-write means we need to delve into Swift’s type classification.

Objects in Swift can be divided into two type groups: value types and reference types.

The main difference between the two is how they are managed in memory. Theoretically, Value types create a new copy on memory each time they are assigned to a new variable, conversely reference types share the same reference amongst all variables.

What is copy-on-write?

This is a technique used to manage the copy of objects efficiently.

When we create a new assignment of a variable that holds a type supporting copy-on-write, the actual duplication of the data only occurs when there is a modification to the data through its references (data mutation).

This mechanism also occurs when we initialize or pass them as arguments.

This technique allow us to improve performance and reduce the use of costly copy operations.

In essence, we are postponing the allocation and copying of data in memory until we actually need it.

How does this affect Swift?

We mentioned that, in Swift, value types are copied to a new memory region when we assign them to variables (copy semantics). This is partially true for built-in value-types and for custom types where we implement this functionality.

The whole process involves the extra step of copy-on-write mechanism that allows us to reduce unnecessary memory allocations, making the entire process more efficient and performant.

Copy and move semantics is a complex topic and it’s out of the scope of this post, in simple terms here are some definitions of them:

Copy semantics means that when you pass or assign an object, you create a new copy of that object’s data.

Move semantics means that when you pass or assign an object, you transfer the ownership of that object’s data to another object.

This means that every time we make a new assignment, the copy allocation is delayed until we modify the actual data (mutation). This implies that at certain times, our value types can refer to the same memory region, behaving as reference types.

Does all value types uses copy-on-write in Swift?

We have this behaviour for free in Collection types: Arrays, Sets, Dictionaries, and Strings.

For custom value types, we need to manually implement it using the function isKnownUniquelyReferenced(_:). Apple provides guidance on how to apply this mechanism here.

Code example

To demonstrate this functionality let’s use an Array collection:

/// Prints the address of the given array
/// - Parameter bytes: the array pointer
func printAddress(_ bytes: UnsafeRawBufferPointer) {
    print(NSString(format: "%p", Int(bitPattern: bytes.baseAddress)))
}

var nums1 = [1,2,3]
var nums2 = nums1 // copying

nums1.withUnsafeBytes(printAddress) // 0x60000170c0e0
nums2.withUnsafeBytes(printAddress) // 0x60000170c0e0

nums2.append(4)

nums1.withUnsafeBytes(printAddress) // 0x60000170c0e0
nums2.withUnsafeBytes(printAddress) // 0x60000210c6b0 (copy-on-write happens)

In the above code we can observe how the copy-on-write delays the duplication on a different memory location until we made some changes to the underlying data.

Warning: There was a change in the Swift 5.3 compiler that made the withUnsafeBytes (_:) method of String internal, meaning that it can only be accessed within the same module as the String type. Meaning this way of printing addresses won’t work for Strings.

Another example: Passing collections to functions

Let’s explore passing collections as arguments in functions.

By default, when we pass a type to a function this is immutable by default (it cannot be changed). This improves the predictability and safety of our code.

Another consequence of this immutability in function’s parameters is the use of copy-on-write. Since we cannot mutate our value types, no memory copy occurs and we get a reference to the same value. This helps to avoid unnecessary cpu and memory work.

Let’s demonstrate this fact with the following code.

/// Prints the address of the given array
/// - Parameter bytes: the array pointer
func printAddress(_ bytes: UnsafeRawBufferPointer) {
    print(NSString(format: "%p", Int(bitPattern: bytes.baseAddress)))
}

/// A functions that receives an array as argument and prints its memory address and content.
/// - Parameter array: the array being passed.
func foo(_ array: [Int]) {
    array.withUnsafeBytes(printAddress)
    print(array)
}

var nums = [1, 2, 3]

nums.withUnsafeBytes(printAddress) // 0x6000017001a0

foo(nums) // 0x6000017001a0 (same memory address)

The previous code shows that the data we get inside the function is the same as the one being passed. This indicates the use of copy-on-write.

This is great from a performance point of view because we don’t need to optimize the memory copy for built-in types.

In the case of custom value types, the copy does occur if we don’t add the copy-on-write functionality manually.

Advantages and disadvantages

The use of copy-on-write can be a great way to reduce memory usage by having several references to the same object in memory, this also helps with performance when we use it in data that rarely change and is shared across several parts.

Conversely, it can be hard to implement for our custom types, specially if our types are complex. This can limit the applicability of this technique by adding complexity to our code.

Conclusion

Copy-on-write is a great way to improve memory management and boost performance of our value types. Despite some complexities involved in its manual implementation for custom types, it’s a great tool that we need to understand to be able to write performant code when implementing low level abstractions.

How to Create Databases Using Docker

Mon, 18 Sep 2023 19:47:33 -0600

The other day, I needed to set up a PostgreSQL database, and after considering various solutions, I decided to use Docker. In this tutorial, I’ll share the solution that worked for my problem.

Creating a PostgreSQL Database Using Docker Compose

Docker Compose is a powerful tool that allows us to manage multiple containers from a single central point. You might think it’s a bit much for setting up a database, but I found it surprisingly easy to set up and use.

Let’s start!

Creating the docker-compose.yml File

Docker Compose requires a configuration file named docker-compose.yml where we define and configure our containers. Writing this file is straightforward; here’s the one I used for my database:

version: '3'
services:
  postgres-db:
    image: postgres:latest
    container_name: postgres_container
    volumes:
      - "/path_to_local_storage:/var/lib/postgresql/data"
    environment:
      - POSTGRES_DB=my_db
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=password
    ports:
      - '5433:5432'

In the above file:

We define a service named postgres-db containing the PostgreSQL database image.
You can customize the container_name to your preference.
To ensure data persistence and choose a custom storage location, define your preferred local path in the ‘volumes’ section.
Set your database credentials (user, password) and the default database name in the environment section.
The port mapping is configured to use the default PostgreSQL ports. You can adjust this mapping if necessary; the format is local_machine_port:docker port.

Starting the database

To start your database, open a terminal in the directory where your docker-compose.yml is located (or specify a relative path to the file) and run this command (assuming you’re using Docker Compose 2):

docker compose -p example up -d

This command creates the containers defined in the compose file. You can customize the project name with the -p property.

Stopping the database

To stop your database, use this command:

docker compose down

Connecting locally to the database

Connecting to the database locally on your computer is simple. Access http://localhost:5433 using your chosen username and password. While I use DataGrip to connect, any database software can connect to it.

Troubleshooting

During the container creation process, I encountered some common issues, along with their solutions.

Issue: The image exited with code 1.

If your container exits immediately when launched, check the container logs by running:

docker logs my_container_name

I discovered that my data directory contained hidden files that caused this issue. Deleting these hidden files allowed the database to start and function as expected.

Issue: The mounting point is not valid.

If you encounter issues starting the image, it may be related to the local path name. If your path contains spaces, a simple workaround is to enclose the path in double quotes.

Conclusion

By utilizing docker-compose, we can easily start and manage data persistence for our databases. This method provides a straightforward and quick way to create databases with data persistence. I hope this tutorial proves as helpful to you as it was to me.

Happy coding!

LeetCode – Two Sum

Thu, 14 Sep 2023 14:32:44 -0600

Let’s continue working with more LeetCode problems, this time focusing on an easy one.

We need to find if, in a given array, we can find two numbers such that they can be added up to a certain target value. We can be certain that there will be only one solution.

Solution

Brute force

As with other problems, one first approach would be to compare all possible combinations to find the two numbers that adds to the target. This solution is easy to implement but it has a bad time performance of $O(n^2)$.

func twoSum(_ nums: [Int], _ target: Int) -> [Int] {
    var indices = [Int]()
    for i in nums.indices {
        for j in (i + 1)..<nums.count {
            if nums[i] + nums[j] == target {
                indices.append(contentsOf: [i, j])
            }
        }
    }
    return indices
}

You may be wondering why we have (i + 1) in the inner loop. This is to avoid comparing the same value with itself, if we do that we may get a wrong solutions to certain inputs (one example: [3, 2, 4] and 6).

This solutions solves the problem, but it’s slow with a time complexity of $O(n^2)$. Let’s try to find another approach to improve this.

Using a Hash Table

Let’s try to think of the problem as a math equation, we want two values that add up to a certain third value.

This can be represented as the following simple equation.

$$ a + b = target $$

How can this help us? Notice that we already have two of three values of the equation for any given iteration. So we are searching for the third value, this is the value $b$ that can solve the previous equation.

$$ b = target - a $$

This missing value $b$ is just the difference between the target and the current value.

By knowing this, we can store somehow the values and indices of the array and check if some $b$ that can solves the equation is presented in our storing objet. When that happens we are done, and we can return the indices for the current value and the one stored for $b$.

We need an object able to save a value with its index, this is a perfect use for a Hash table. In Swift we have one already build-in, it’s called a Dictionary.

This data structure saves a key-value pair, like a real dictionary do. It’s also important to know that insertion and retrieval takes $O(1)$ time complexity, which make it ideal for this problem.

Here is the solution using this approach.

func twoSum(_ nums: [Int], _ target: Int) -> [Int] {
    // Storing key: number, value: index in array
    var dic = [Int:Int]()
    
    for (currentNumberIndex, value) in nums.enumerated() {
        let diff = target - value
        
        if let missingNumberIndex = dic[diff] {
            return [missingNumberIndex, currentNumberIndex]
        }
        
        dic[value] = currentNumberIndex
    }

    return [-1,-1]
}

This solution is easy to read and quite efficient because we only check each element once. The time complexity is $O(n)$ and since we are storing each element in a dictionary, the space complexity is also $O(n)$.

Here we are using some cool Swift features:

.enumerated(): returns a tuple containing the current index and value.
Checking for optionals in dictionaries: we are using a if let statement to check whether the value we are missing is already on the dictionary.

Conclusion

This problem provides valuable insights into the efficient use of dictionaries in Swift. We started with a brute force approach that had a time complexity of $O(n^2)$, but then we optimized our solution using a hash table (Dictionary) to achieve a linear time complexity of $O(n)$. By employing the concept of key-value pairs and leveraging Swift’s features like .enumerated(), we were able to find a more elegant and efficient solution.

Exploring different approaches and understanding when to use data structures like dictionaries can greatly enhance our problem-solving skills as developers. Happy coding!

LeetCode – Contains Duplicates

Sun, 10 Sep 2023 07:40:04 -0600

Hello everyone, in this post I want to explore a solution to the Contains Duplicates LeetCode problem using Swift. Most solutions use Python and I think it would be a good idea to try to use Swift to explore how well it behaves for the LeetCode style questions.

The Problem

This problem states that we have an array of integers and it may contain some values that are duplicated, so we need to write a function that check if the given array contains any element more than once.

Here are some examples of valid inputs and outputs:

# Example 1
Input: nums = [1,2,3,1]
Output: true

# Example 2
Input: nums = [1,2,3,4]
Output: false

Solution

To solve this problem we need to find a way to count for at least one duplicity in the array, if this condition happens we can be sure that there are duplicates.

There are several approaches to solve this.

Brute force

We could think that if we select each element and compare with each other we would end up finding the duplicate, this solution involves the use of two nested for.

As we can observe in the image, when we compare each element with every other element, we create a scalability problem as our data set grows.

As an example, in a worse case nested comparison, if we have $30$ elements, we would perform $900$ operations; for $900$ elements, it would be $810,000$. This is why $O(n^2)$ time solutions are problematic when dealing with large data sets. To achieve scalability, we need to optimize our solutions for faster algorithms.

func containsDuplicateBruteForce(_ nums: [Int]) -> Bool {
    for n in 0..<nums.count {
        for m in (n + 1)..<nums.count {
            if nums[n] == nums[m] { return true }
        }
    }
    return false
}

Our solution works but, as we mentioned before, it is not ideal due to its time complexity, resulting in $O(n^2)$. The problem here is that we are doing inefficient comparisons, we can do better.

Sets

We are looking for duplicates, so one possible approach for this problem is to store somehow the elements in a new container that doesn’t allow duplicates, then we can add them and if some element was not able to be inserted we can be sure that there are duplicates.

What data structure have the property of not allowing duplicates? It’s the Set!

Lucky us, Swift already comes with a build-in Set data structure.

Sets are data structures that don’t allow duplicates. We can iterate over the array and insert each element into a new Set. If the insertion fails (i.e., the element already exists in the Set), we return true. Sounds easy enough, let’s code it!.

func containsDuplicate(_ nums: [Int]) -> Bool {
    // Define the Set of integers
    var set = Set<Int>()
        
    // Iterate over the array to generate the Set, if the set returns false we found a duplicate
    for num in nums where !set.insert(num).inserted {
        return true
    }

    // if all elements were inserted then there is no duplicated value
     return false
}

According to some pages, inserting into a Set in Swift uses internally a hash map, this mean that the insertion takes in average $O(1)$, making this solution $O(n)$.

This solution is already quite efficient because we are only iterating over all elements only once, but can we do a simpler code that express the same idea in a more concise way?

We are iterating over the elements to create a new container with its own copy of values, at the end we will end up with two objects. We can take advantage of this in the following manner: if the number of elements on both containers is not the same, then we can assume there are duplicates, in case that both contains the same number of elements we can be sure that there are no duplicates. This solution may lead us to a more expressive and concise code, so let explore it.

func containsDuplicate(_ nums: [Int]) -> Bool {
    // Define the Set of integers
    var set = Set<Int>()
        
    // Iterate over the array to generate the Set, if the set returns false we found a duplicate
    for num in nums {
        set.insert(num)
    }

    // if both containers have the same number of elements, they are equal and no duplicates were found, conversely there are duplicates 
     return set.count < nums.count
}

This is looking simpler to read, but there is one last thing. Set constructors can accept Arrays to instantiate them, we could use this handy property to make a one line solution!.

func containsDuplicate(_ nums: [Int]) -> Bool {
    // If the count of unique elements in the Set is less than the total count, there are duplicates
    Set(nums).count < nums.count
}

This simple line of code solves the problem in an elegant and concise way, we are creating a new set and then calling .count on it, then we use that value to compare it to the size of the original array and returning the result.

The final time complexity of this solution is $O(n)$, because we are implicitly iterating over the array when we create the Set.

Conclusion

I hope this post helps you understand how Swift features can be used to create elegant and efficient solutions. Thanks for reading, and until next time!

Hello World

Sun, 10 Sep 2023 06:58:41 -0600

Hey there, tech enthusiasts! 📱, this is my first time blogging 🥳.

I decided to create this blog to register all of my learning in the world of programming. I’m so exited to share what I’m learning in this cool journey.

I’m bad for making intros, so if something new comes to my mind I’ll update this post. 😅

While my main focus right now is iOS development, that doesn’t mean I’m not intrigued by the myriad of options technology has to offer. I’m open to exploring and writing about various tech topics.

Cheers to learning and growing together in the world of code! 🥳💻"

entangledDEV

Git How-Tos I Reach For Daily Work

Squash Multiple Commits Into One

Force Push After Squashing

Create a Local Repo and Wire Up a Remote

Track a Remote Branch Locally

Create a Branch and Push It Upstream

Sync With the Latest From Main Without Merge Commits

Rebase Onto the Remote Version of Your Branch

Cherry-Pick a Fix Onto Another Branch

Quick Patch From a File Diff

Merge Main Into Your Branch (Keep the Merge Commit)

See What Changed Between Two Branches

Undo the Last Commit (Keep Changes)

Recover Work You Thought Was Gone

Stash Selective Files

Clean Untracked Files Safely

Revert a Commit That Already Hit Main

Rename a Branch Locally and Remotely

Parsing JSON with Swift

Sample JSON Payload

Create a Codable Model

Decode with JSONDecoder

Configure a Shared Decoder

Handling Optional Data

Supplying Defaults Without Optionals

What Happens to init(from:)

Modeling Enumerated Values

1. Direct String Backing

2. Mapping Backend Slugs to Expressive Cases

3. Capturing Unknown Cases

Custom Decoding Logic

Decoding Polymorphic Payloads

Mapping Nested Collections

Integrating with Legacy [String: Any] Stores

Surface Decoding Errors Clearly

Decoding with Swift Concurrency

Testing Your Decoders

Wrap Up

Inspecting your network traffic in Apple Platforms

Prerequisites

Configure the Wi‑Fi proxy on the device

Install and trust the Charles SSL certificate

Verify the capture

Troubleshooting tips

Clean up when finished

Handling Touch Gestures in UIKit

Long Press Gesture

Gesture States

Example

Reactive Sous Vide Cooking

Sous Vide Is the Combine of Cooking (and It’s Not Just a Joke)

Traditional Cooking Is Imperative

Sous Vide Is Combine

Ingredients Are Data — The Bag Is the DI Container

Cooking Pipelines: Combine-Style Breakdown

Why This Actually Matters

Structuring Your Meal as Data

Conclusion

State Driven Enum Navigation

Navigating SwiftUI with an Enum Router (Cyclical A → B → C Flow) — A Simple example

Introduction

1. Defining the Router State

2. The Router Protocol & Default Implementation

3. The Navigation Container

4. The Three Views

5. How It Works

6. Pros and Cons

Pros:

Cons:

7. Conclusion

SwiftUI Generic Containers

💡 SwiftUI Tip: Wrapping Views with Generics and Closures

🚧 The Problem

🔍 The Fix: Use a Generic + Closure

🤯 But wait — doesn’t MyCoolView(param: 123) need a closure like (Int) -> some View?

🧠 What this unlocked for me

🧪 Bonus: Custom Layout Containers

📦 Usage

🤔 What’s up with where Footer == EmptyView?

What Happens to `init(from:)`

Integrating with Legacy `[String: Any]` Stores

🤯 But wait — doesn’t `MyCoolView(param: 123)` need a closure like `(Int) -> some View`?

🤔 What’s up with `where Footer == EmptyView`?

Why we need a `collectionViewLayout`