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?

It’s covered in the book. Chapter 10: Giving the Controller Access to the Store. — vacawama, Mar 31 '18 at 21:07

vacawama · Answer 1 · 2018-03-31T21:22:12.757

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.

Bappaditya · Answer 2 · 2018-03-31T21:03:29.723

0

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

edited Mar 31 '18 at 21:03

answered Mar 31 '18 at 20:56

Bappaditya

9,494
3
20
29

This begs the question, why is itemStore defined as an implicitly unwrapped variable? – Mike Taverne Mar 31 '18 at 22:48
it could be a mandatory element in `ItemsViewController` class. – Bappaditya Apr 01 '18 at 03:39
Then, back to the OP's original question, why not just instantiate it in the view controller instead of the AppDelegate? – Mike Taverne Apr 01 '18 at 04:03

score 0 · Answer 3 · answered Mar 31 '18 at 21:01

0

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

answered Mar 31 '18 at 21:01

Shehata Gamal

98,760
8
65
87

1

No, this style of initialization is not useless. This is called Dependency Injection and it is very useful. – Mike Taverne Mar 31 '18 at 22:49
If you read the remaining i said "If the variable can be initialized in the class" – Shehata Gamal Mar 31 '18 at 22:51
1

Of course I read that. You're saying that if a class can initialize a variable, it should always do that. Dependency Injection says that for testability, it's better to pass certain kinds of dependencies into the class. – Mike Taverne Mar 31 '18 at 23:02
The OP asks why we initialized the var out of the class the answer as i explained because if we want to pass data to that class with a specific var configured like from push or data source outside of the class otherwise if data is static it will be **useless** – Shehata Gamal Mar 31 '18 at 23:15
Have you heard of Dependency Injection? – Mike Taverne Mar 31 '18 at 23:16
completely know what you mean and this is useful in unit testing but this out of question purpose – Shehata Gamal Mar 31 '18 at 23:18
It’s completely a valid reason, and probably the best reason, for instantiating the ItemStore outside the view controller and passing it in, as my answer indicates. – Mike Taverne Mar 31 '18 at 23:24

score 0 · Accepted Answer · answered Mar 31 '18 at 22:57

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.

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

4 Answers4