DEV Community: Alex Cruz

Write Less Convoluted ViewModels with Swift Subscripts

Alex Cruz — Thu, 15 Feb 2024 13:16:49 +0000

The Swift programming language provides many convenient language features to access data immediately—for instance, the built-in subscripts for arrays and dictionaries. But what about custom Swift objects? Today, you’ll learn how to access any property without relying on dot notation.

Why Subscripts
Subscripts can be particularly useful when working with multidimensional arrays or other complex data structures, as they provide you with a clean approach to accessing elements at specific indices or by key, exactly how you would access a value from an array or dictionary.

Visualizing the Problem
Let’s assume a scenario where you have a view that switches between four states. For each state, the requirements states (no pun intended) that the corresponding data should be fetched and presented to the end user. But, the corresponding objects are encapsulated within a parent object.

You immediately reach for your switch statement:

switch state {
case .state1:    
    var object = object.correspondingObject
case .state2:
    var object = object.correspondingObject
case .state3:
    var object = object.correspondingObject
case .state4:
    var object = object.correspondingObject
}

And you did it; you got the job done.

But you could have just done:

object[state]

And you’re done.

Important note
The return type of your subscript method should be a protocol that the encapsulated objects conform to.

Understanding Subscripts
Subscripts can make the code more readable and concise when accessing elements in a custom data structure, such as arrays, dictionaries, or custom classes. And like in the example above, they can be used to define custom access patterns for your types, allowing you to interact with your data in a natural and intuitive way.

Summary
In this exploration, we’ve dived into subscripts, a powerful feature in Swift that allows you to provide custom access to elements in your types, improving the clarity and usability of your code.

That’s all for now, fellow developers! I hope this post has shed light on the beauty of subscripts in Swift. If you have any questions or insights to share, feel free to leave a comment below. And don’t forget to connect with me on LinkedIn and Twitter for more insights and future posts. Happy coding!

Generics beyond Ints and Strings in Swift

Alex Cruz — Wed, 14 Feb 2024 02:29:25 +0000

Introduction:
In the Swift programming language, certain concepts may appear daunting at first but hold immense power once understood. Generics is one of those concepts. Today, we will simplify their purpose and explore the elegance and versatility of generics. By the end, you'll have a better understanding of generics and how to squeeze the most out of them.

The Overlooked Potential of Generics:
Generics are often underutilized or misunderstood by developers. However, they offer a powerful way to write flexible and reusable code. Whether you're working with collections, algorithms, or network services, generics can streamline your code and make it more adaptable to different types.

The Essence of Generics:
At its core, generics allow us to write functions, classes, and structures that can work with any type (known as polymorphism). Rather than specifying the type of data a function or data structure will take in as part of the signature, we use placeholders, or type parameters, to indicate that the code should operate on any type. Or any type that conforms to a protocol. Multiple protocols are also allowed: func printDescriptions(items: [T], minArea: Double) {}. This flexibility enables us to write more generic, yet still type-safe, code because Swift generics provide stronger type safety because the compiler enforces type constraints at compile time. This helps catch type-related errors early in the development.

Visualizing the Problem:
Let's consider a scenario where you have four identical types that represent the rounds in a poker hand: preflop, flop, turn, and river. The behavior is identical for each, so we create a protocol which each will conform to.

protocol Round {
  var openingPot: Int { get }
  var closingPot: Int { get }
  var players: [Players] { get }
  var round: String { get }
}

Now, our types will conform as such:

struct Preflop: Round {}
struct Flop: Round {}
struct Turn: Round {}
struct River: Round {}

The Generic Approach:
Here's a concise implementation of a generic function that accepts any of the 4 types:

func prepareTablePositions<T: Round>(_ round: T) {}

You could have just used the protocol:

func prepareTablePositions(_ round: Round) {}

But, you'll miss out on:

Flexibility: With generics, you can specify a specific type when calling the function (printDescriptions(items: shapes2)), allowing you to work with arrays of specific types rather than generic protocols.
Type Safety: Generics provide stronger type safety because the compiler enforces type constraints at compile time. This helps catch type-related errors early in the development process.
Code Reusability: Generics promotes code reusability by allowing functions and types to work with a wide range of types, reducing the need for duplication or specialized implementations.

While protocols alone offer ways to achieve polymorphism and code reuse, generics provide additional benefits such as increased flexibility and type safety, making them a powerful choice.

Understanding Flexibility:
With generics, we can write functions, structures, and classes that operate on a wide range of types while still ensuring type safety at compile time. This enables us to write cleaner, more concise code that is less prone to errors.

Summary:
In this exploration, we've delved into some of the nuances of generics in Swift. By understanding the essence of generics, visualizing the problem, and embracing the generic approach, you now have the tools to harness the power of generics in your own code.

That's all for now, fellow developers! I hope this post has shed light on the beauty of generics in Swift. If you have any questions or insights to share, feel free to leave a comment below. And don't forget to connect with me on LinkedIn and Twitter for more insights and future posts.
Happy coding!

Why iOS Developers overlook the usefulness of unowned

Alex Cruz — Wed, 14 Feb 2024 01:23:47 +0000

Most iOS Developers I’ve talked to about unowned variables disregard its specific usefulness. Even worse, they just default to weak without a justified reason. I think this is because it’s not commonly used in our day-to-day development. But if you spend some time digging into Swift’s own documentation around the topic and doing your own hands-on tinkering, you’ll quickly notice what makes unowned important and realize the distinction between weak and owned.

What makes unowned important is that unlike weak variables, unowned variables can be declared as non-optionals. That means we are responsible for assigning them a value during initialization. Which tells us precisely their usefulness, that we must use unowned when we need to establish a tightly coupled relationship between two objects. For instance, when establishing relationships between a customer and a credit card object, we instinctively know that a customer may or may not own a credit card, but a credit card must always be tied to a customer. If it doesn’t have a customer, well, it’s not a credit card, is it? It’s just a piece of plastic.

Since all weak properties are optional, you can create a credit card without a customer, and this is precisely what you want to avoid. The way to avoid it is by using a non-optional unowned property that enforces the relationship safely.

Here’s an example to demonstrate visually unowned’s usefulness:

Weak:
As you can see, if we use weak, we can initialize a credit card with or without a customer. While this would still work, it’s not explicit and we should aim to be explicit when possible. I assume that is why the Swift creators included unowned in the first place.

class Customer {
    let name: String
    var card: CreditCard?
    init(name: String) {
        self.name = name
    }
    deinit { print("\(name) is being deinitialized") }
}
class CreditCard {
    let number: UInt64
    weak var customer: Customer?
    init(number: UInt64, customer: Customer) {
        self.number = number
        self.customer = customer
    }
    deinit { print("Card #\(number) is being deinitialized") }
}
var john: Customer?
john = Customer(name: "John Appleseed")
john!.card = CreditCard(number: 1234_5678_9012_3456, customer: john!)

Unowned:
Here, on the other hand, since we’re using a non-optional unowned, we are required to include the credit card in the initialization. Now by simply looking at this class init method, it’s clear that a credit card must always have a customer, since it’s not possible to create a credit card without one. That’s a level of clarity we can’t achieve if we use a weak variable.

class Customer {
    let name: String
    var card: CreditCard?
    init(name: String) {
        self.name = name
    }
    deinit { print("\(name) is being deinitialized") }
}
class CreditCard {
    let number: UInt64
    unowned var customer: Customer
    init(number: UInt64, customer: Customer) {
        self.number = number
        self.customer = customer
    }
    deinit { print("Card #\(number) is being deinitialized") }
}
var john: Customer?
john = Customer(name: "John Appleseed")
john!.card = CreditCard(number: 1234_5678_9012_3456, customer: john!)

Here’s a framework I use that helps me remember the functionality of each keyword, and helps me identify in which situations they’re most applicable.

Summary
Today we explored the specific difference between unowned and weak. We highlighted the usefulness of using unowned as “clarity” in establishing a reference back to the parent object while avoiding a strong reference cycle, which is the primary purpose of both weak and unowned.

Why You Should Use Async/Await Over Closures Moving Forward

Alex Cruz — Wed, 14 Feb 2024 01:16:57 +0000

Since Apple released Async/await in 2021, it has made writing asynchronous code amazingly pleasant for iOS developers. In addition to the out-of-the-box performance and safety benefits, writing asynchronous code with async/await feels like you’re writing synchronous code, which we write most of the time. Writing straightline code rather than nested closures allows us to better express our intent to others. Using the combination of async/await and throws also makes handling errors straightforward.

Async/await was designed to resemble code we write everyday. It removed many of the frictions that came with writing and maintaining closures. For example, rather than capturing the return values on the right (like with closures), the return value of an async/await function is assigned to a variable on the left. This makes it just like your most basic function. You also no longer need to concern yourself with capturing the outer scope to access those values from within the closure. Which, if you had simply forgotten to add the weak keyword in front of your variables or self, you would have had a memory leak in your app, which is never a good thing.

Being able to write code that’s idiomatic and easy to parse is beneficial in many facets. For instance, you’ll write less lines of code which means it’ll be easier to maintain. You’ll also find the intent of your logic easier to maintain in your head. And it’ll ultimately feel like the style of code you write the most often.

One of the features I find most useful is how easy it makes handling errors. Errors seamlessly propagate downstream and could be parsed by individual catch blocks that will execute additional code, such as triggering events and handling any unhappy path. Unlike with closures where you can accidentally leave out an vital completion call, using try await, Swift warns you if you leave out a throw, which makes our code safer.

Summary
This article introduces the core advancements that Swift has made in writing asynchronous code using Async/await. Async/await is here to stay, and iOS Developers should begin using it and advocating for its adoption in their organization if they aren’t already.