Swift From Scratch: Initialization and Initializer Delegation

In the previous lesson of Swift From Scratch, we created a functional to-do application. The data model could use some love, though. In this final lesson, we’re going to refactor the data model by implementing a custom model class.

1. The Data Model

The data model we’re about to implement includes two classes, a Task class and a ToDo class that inherits from the Task class. While we create and implement these model classes, we’ll continue our exploration of object-oriented programming in Swift. In this lesson, we’ll zoom in on the initialization of class instances and what role inheritance plays during initialization.

The Task Class

Let’s start with the implementation of the Task class. Create a new Swift file by selecting New > File… from Xcode’s File menu. Choose Swift File from the iOS > Source section. Name the file Task.swift and hit Create.

The basic implementation is short and simple. The Task class inherits from NSObject, defined in the Foundation framework, and has a variable property name of type String. The class defines two initializers, init() and init(name:). There are a few details that might trip you up, so let me explain what’s happening.

import Foundation

class Task: NSObject {

    var name: String

    convenience override init() {
        self.init(name: "New Task")
    }

    init(name: String) {
        self.name = name
    }

}

Because the init() method is also defined in the NSObject class, we need to prefix the initializer with the override keyword. We covered overriding methods earlier in this series. In the init() method, we invoke the init(name:) method, passing in "New Task" as the value for the name parameter.

The init(name:) method is another initializer, accepting a single parameter name of type String. In this initializer, the value of the name parameter is assigned to the name property. This is easy enough to understand. Right?

Designated and Convenience Initializers

What’s with the convenience keyword prefixing the init() method? Classes can have two types of initializers, designated initializers and convenience initializers. Convenience initializers are prefixed with the convenience keyword, which implies that init(name:) is a designated initializer. Why is that? What’s the difference between designated and convenience initializers?

Designated initializers fully initialize an instance of a class, meaning that every property of the instance has an initial value after initialization. Looking at the Task class, for example, we see that the name property is set with the value of the name parameter of the init(name:) initializer. The result after initialization is a fully initialized Task instance.

Convenience initializers, however, rely on a designated initializer to create a fully initialized instance of the class. That’s why the init() initializer of the Task class invokes the init(name:) initializer in its implementation. This is referred to as initializer delegation. The init() initializer delegates initialization to a designated initializer to create a fully initialized instance of the Task class.

Convenience initializers are optional. Not every class has a convenience initializer. Designated initializers are required, and a class needs to have at least one designated initializer to create a fully initialized instance of itself.

The NSCoding Protocol

The implementation of the Task class isn’t complete, though. Later in this lesson, we will write an array of ToDo instances to disk. This is only possible if instances of the ToDo class can be encoded and decoded.

Don’t worry, though—this isn’t rocket science. We only need to make the Task and ToDo classes conform to the NSCoding protocol. That’s why the Task class inherits from the NSObject class since the NSCoding protocol can only be implemented by classes inheriting—directly or indirectly—from NSObject. Like the NSObject class, the NSCoding protocol is defined in the Foundation framework.

Adopting a protocol is something we already covered in this series, but there are a few gotchas that I want to point out. Let’s start by telling the compiler that the Task class conforms to the NSCoding protocol.

import Foundation

class Task: NSObject, NSCoding {

    var name: String
    
    ...

}

Next, we need to implement the two methods declared in the NSCoding protocol, init?(coder:) and encode(with:). The implementation is straightforward if you’re familiar with the NSCoding protocol.

import Foundation

class Task: NSObject, NSCoding {

    var name: String

    @objc required init?(coder aDecoder: NSCoder) {
        name = aDecoder.decodeObject(forKey: "name") as! String
    }

    @objc func encode(with aCoder: NSCoder) {
        aCoder.encode(name, forKey: "name")
    }

    convenience override init() {
        self.init(name: "New Task")
    }

    init(name: String) {
        self.name = name
    }

}

The init?(coder:) initializer is a designated initializer that initializes a Task instance. Even though we implement the init?(coder:) method to conform to the NSCoding protocol, you won’t ever need to invoke this method directly. The same is true for encode(with:), which encodes an instance of the Task class.

The required keyword prefixing the init?(coder:) method indicates that every subclass of the Task class needs to implement this method. The required keyword only applies to initializers, which is why we don’t need to add it to the encode(with:) method.

Before we move on, we need to talk about the @objc attribute. Because the NSCoding protocol is an Objective-C protocol, protocol conformance can only be checked by adding the @objc attribute. In Swift, there’s no such thing as protocol conformance or optional protocol methods. In other words, if a class adheres to a particular protocol, the compiler verifies and expects that every method of the protocol is implemented.

The ToDo Class

With the Task class implemented, it’s time to implement the ToDo class. Create a new Swift file and name it ToDo.swift. Let’s look at the implementation of the ToDo class.

import Foundation

class ToDo: Task {

    var done: Bool

    @objc required init?(coder aDecoder: NSCoder) {
        self.done = aDecoder.decodeBool(forKey: "done")
        super.init(coder: aDecoder)
    }

    @objc override func encode(with aCoder: NSCoder) {
        aCoder.encode(done, forKey: "done")
        super.encode(with: aCoder)
    }

    init(name: String, done: Bool) {
        self.done = done
        super.init(name: name)
    }

}

The ToDo class inherits from the Task class and declares a variable property done of type Bool. In addition to the two required methods of the NSCoding protocol that it inherits from the Task class, it also declares a designated initializer, init(name:done:).

As in Objective-C, the super keyword refers to the superclass, the Task class in this example. There is one important detail that deserves attention. Before you invoke the init(name:) method on the superclass, every property declared by the ToDo class needs to be initialized. In other words, before the ToDo class delegates initialization to its superclass, every property defined by the ToDo class needs to have a valid initial value. You can verify this by switching the order of the statements and inspecting the error that pops up.

The same applies to the init?(coder:) method. We first initialize the done property before invoking init?(coder:) on the superclass.

Initializers and Inheritance

When dealing with inheritance and initialization, there are a few rules to keep in mind. The rule for designated initializers is simple.

• A designated initializer needs to invoke a designated initializer from its superclass. In the ToDo class, for example, the init?(coder:) method invokes the init?(coder:) method of its superclass. This is also referred to as delegating up.

The rules for convenience initializers are a bit more complex. There are two rules to keep in mind.

• A convenience initializer always needs to invoke another initializer of the class it’s defined in. In the Task class, for example, the init() method is a convenience initializer and delegates initialization to another initializer, init(name:) in the example. This is known as delegating across.
• Even though a convenience initializer doesn’t have to delegate initialization to a designated initializer, a convenience initializer needs to call a designated initializer at some point. This is necessary to fully initialize the instance that’s being initialized.

With both model classes implemented, it is time to refactor the ViewController and AddItemViewController classes. Let’s start with the latter.

2. Refactoring AddItemViewController

Step 1: Update the AddItemViewControllerDelegate Protocol

The only changes we need to make in the AddItemViewController class are related to the AddItemViewControllerDelegate protocol. In the protocol declaration, change the type of didAddItem from String to ToDo, the model class we implemented earlier.

protocol AddItemViewControllerDelegate {

    func controller(_ controller: AddItemViewController, didAddItem: ToDo)
    
}

Step 2: Update the create(_:) Action

This means that we also need to update the create(_:) action in which we invoke the delegate method. In the updated implementation, we create a ToDo instance, passing it to the delegate method.

@IBAction func create(_ sender: Any) {
    if let name = textField.text {
        // Create Item
        let item = ToDo(name: name, done: false)

        // Notify Delegate
        delegate?.controller(self, didAddItem: item)
    }
}

3. Refactoring ViewController

Step 1: Update the items Property

The ViewController class requires a bit more work. We first need to change the type of the items property to [ToDo], an array of ToDo instances.

var items: [ToDo] = [] {
    didSet(oldValue) {
        let hasItems = items.count > 0
        tableView.isHidden = !hasItems
        messageLabel.isHidden = hasItems
    }
}

Step 2: Table View Data Source Methods

This also means that we need to refactor a few other methods, such as the tableView(_:cellForRowAt:) method shown below. Because the items array now contains ToDo instances, checking if an item is marked as done is much simpler. We use Swift’s ternary conditional operator to update the table view cell’s accessory type.

func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    // Fetch Item
    let item = items[indexPath.row]

    // Dequeue Cell
    let cell = tableView.dequeueReusableCell(withIdentifier: "TableViewCell", for: indexPath)

    // Configure Cell
    cell.textLabel?.text = item.name
    cell.accessoryType = item.done ? .checkmark : .none

    return cell
}

When the user deletes an item, we only need to update the items property by removing the corresponding ToDo instance. This is reflected in the implementation of the tableView(_:commit:forRowAt:) method shown below.

func tableView(_ tableView: UITableView, commit editingStyle: UITableViewCellEditingStyle, forRowAt indexPath: IndexPath) {
    if editingStyle == .delete {
        // Update Items
        items.remove(at: indexPath.row)

        // Update Table View
        tableView.deleteRows(at: [indexPath], with: .right)

        // Save State
        saveItems()
    }
}

Step 3: Table View Delegate Methods

Updating the state of an item when the user taps a row is handled in the tableView(_:didSelectRowAt:) method. The implementation of this UITableViewDelegate method is much simpler thanks to the ToDo class.

func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
    tableView.deselectRow(at: indexPath, animated: true)

    // Fetch Item
    let item = items[indexPath.row]

    // Update Item
    item.done = !item.done

    // Fetch Cell
    let cell = tableView.cellForRow(at: indexPath)

    // Update Cell
    cell?.accessoryType = item.done ? .checkmark : .none

    // Save State
    saveItems()
}

The corresponding ToDo instance is updated, and this change is reflected by the table view. To save the state, we invoke saveItems() instead of saveCheckedItems().

Step 4: Add Item View Controller Delegate Methods

Because we updated the AddItemViewControllerDelegate protocol, we also need to update the ViewController‘s implementation of this protocol. The change, however, is simple. We only need to update the method signature.

func controller(_ controller: AddItemViewController, didAddItem: ToDo) {
    // Update Data Source
    items.append(didAddItem)

    // Save State
    saveItems()

    // Reload Table View
    tableView.reloadData()

    // Dismiss Add Item View Controller
    dismiss(animated: true)
}

Step 5: Save Items

The pathForItems() Method

Instead of storing the items in the user defaults database, we’re going to store them in the application’s documents directory. Before we update the loadItems() and saveItems() methods, we’re going to implement a helper method named pathForItems(). The method is private and returns a path, the location of the items in the documents directory.

private func pathForItems() -> String {
    guard let documentsDirectory = NSSearchPathForDirectoriesInDomains(.documentDirectory, .userDomainMask, true).first,
          let url = URL(string: documentsDirectory) else {
        fatalError("Documents Directory Not Found")
    }

    return url.appendingPathComponent("items").path
}

We first fetch the path to the documents directory in the application’s sandbox by invoking NSSearchPathForDirectoriesInDomains(_:_:_:). Because this method returns an array of strings, we grab the first item.

Notice that we use a guard statement to make sure the value returned by NSSearchPathForDirectoriesInDomains(_:_:_:) is valid. We throw a fatal error if this operation fails. This immediately terminates the application. Why do we do this? If the operating system is unable to hand us the path to the documents directory, we have bigger problems to worry about.

The value we return from pathForItems() is composed of the path to the documents directory with the string "items" appended to it.

The loadItems() Method

The loadItems method changes quite a bit. We first store the result of pathForItems() in a constant, path. We then unarchive the object archived at that path and downcast it to an optional array of ToDo instances. We use optional binding to unwrap the optional and assign it to a constant, items. In the if clause, we assign the value stored in items to the items property.

private func loadItems() {
    let path = pathForItems()

    if let items = NSKeyedUnarchiver.unarchiveObject(withFile: path) as? [ToDo] {
        self.items = items
    }
}

The saveItems() Method

The saveItems() method is short and simple. We store the result of pathForItems() in a constant, path, and invoke archiveRootObject(_:toFile:) on NSKeyedArchiver, passing in the items property and path. We print the result of the operation to the console.

private func saveItems() {
    let path = pathForItems()

    if NSKeyedArchiver.archiveRootObject(self.items, toFile: path) {
        print("Successfully Saved")
    } else {
        print("Saving Failed")
    }
}

Step 6: Clean Up

Let’s end with the fun part, deleting code. Start by removing the checkedItems property at the top since we no longer need it. As a result, we can also remove the loadCheckedItems() and saveCheckedItems() methods, and every reference to these methods in the ViewController class.

Build and run the application to see if everything is still working. The data model makes the application’s code much simpler and more reliable. Thanks to the ToDo class, managing the items in our list much is now easier and less error-prone.

Conclusion

In this lesson, we refactored the data model of our application. You learned more about object-oriented programming and inheritance. Instance initialization is an important concept in Swift, so make sure you understand what we’ve covered in this lesson. You can read more about initialization and initializer delegation in The Swift Programming Language.

In the meantime, check out some of our other courses and tutorials about Swift language iOS development!

• 
  Swift
  Create iOS Apps With Swift 3
  Markus Mühlberger
• 
  iOS
  Go Further With Swift: Animation, Networking, and Custom Controls
  Markus Mühlberger
• 
  Swift
  Code a Side-Scrolling Game With Swift 3 and SpriteKit
  Derek Jensen
• 
  iOS SDK
  The Right Way to Share State Between Swift View Controllers
  Matteo Manferdini