Why should the app delegate create instances for properties used in other viewControllers?

Question

I'm following a UITableView tutorial within the iOS Programming book from the Big Nerd Ranch. In the tutorial, the we assign a new property onto a UIViewController as follows:

class ItemsViewController: UITableViewController {

    var itemStore: ItemStore!  

}

However, in the AppDelegate of the application we instantiated this itemStore property in the AppDelegate as follows:

class AppDelegate: UIResponder, UIApplicationDelegate {

    var window: UIWindow?


    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
        // Override point for customization after application launch.


        let itemStore = ItemStore()


        let itemsController = window?.rootViewController as! ItemsViewController

        itemsController.itemStore = itemStore

        return true
    }

    func applicationWillResignActive(_ application: UIApplication) {
        // Sent when the application is about to move from active to inactive state. This can occur for certain types of temporary interruptions (such as an incoming phone call or SMS message) or when the user quits the application and it begins the transition to the background state.
        // Use this method to pause ongoing tasks, disable timers, and invalidate graphics rendering callbacks. Games should use this method to pause the game.
    }

    func applicationDidEnterBackground(_ application: UIApplication) {
        // Use this method to release shared resources, save user data, invalidate timers, and store enough application state information to restore your application to its current state in case it is terminated later.
        // If your application supports background execution, this method is called instead of applicationWillTerminate: when the user quits.
    }

    func applicationWillEnterForeground(_ application: UIApplication) {
        // Called as part of the transition from the background to the active state; here you can undo many of the changes made on entering the background.
    }

    func applicationDidBecomeActive(_ application: UIApplication) {
        // Restart any tasks that were paused (or not yet started) while the application was inactive. If the application was previously in the background, optionally refresh the user interface.
    }

    func applicationWillTerminate(_ application: UIApplication) {
        // Called when the application is about to terminate. Save data if appropriate. See also applicationDidEnterBackground:.
    }


}

My question is, why should the app delegate create instances for properties used in other viewControllers? Shouldn't this property be instantiated within the viewController that actually uses it or will by doing it this way, the itemStore object stays alive for the duration of the app?

Answer 1

Whether or not this was Big Nerd Ranch's intention, the best reason for passing the ItemStore instance into the view controller is for testability. This pattern is known as Dependency Injection.

The idea is that you could provide mocked ItemStore's to your view controller during unit testing. (This assumes you do unit testing, which you should! :)

With a mock, you could simulate how your view controller behaves when the ItemStore is nil, empty, or contains certain items.

Answer 2

In ItemsViewController class, itemStore is defined as

var itemStore: ItemStore!

Here itemStore is an unwrapped variable. So it does not accept nil value. Else it will cause Runtime crash. Unexpected nil.

That's why in AppDelegate we need to make sure itemStore object is not nil

let itemStore = ItemStore()
let itemsController = window?.rootViewController as! ItemsViewController
itemsController.itemStore = itemStore

Answer 3

Declaring itemStore like this doesn't mean it'll remain app life , it's a local variable inside didFinishLaunchingWithOptions , this out of class initalization style is useless if it can be initialized within ItemsViewController , it may because the data logic is inside Appdelegate that always happen with coredata , or it's item that will be initialized from a local/remote notification click from launchingOptions

Answer 4

It was done this way to make the ItemsViewController more reusable. The ItemsViewController doesn't need to know the details of the ItemStore object including which ItemStore subclass to instantiate. It only needs to know the interface that that object adheres to. By setting the ItemStore externally, the ItemsViewController can easily be used with other subclasses of ItemStore without having to be changed.

This is covered in Chapter 10, in the section Giving the Controller Access to the Store of the book iOS Programming: The Big Nerd Ranch Guide, 6th Edition.