Design Patterns on entangledDEV

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!