简体   繁体   中英

Does an iOS app's app delegate need to retain the UIWindow?

In the Xcode templates for iOS apps such as the 'View Based Application', a MainWindow nib is created with contains three top-level objects: The App Delegate, the Window, and the main View Controller. The App Delegate defines retain outlets/accessors for both the window and the view controller. I don't understand why the App Delegate would need to retain these objects since they are already top-level objects in the nib and therefore should have been retained by UIApplication. Checking the retainCount of these objects sure enough shows 1 for the app delegate and 2 for the window and view controller. Could I/should I change these to assign instead?

I know this is a nit picky thing but I'm hoping that understanding why this is done will improve my overall understanding of memory management in iOS.

Assign is tricky in iOS with outlets I use @property (nonatomic, retain). Unlike in Mac OS, connected outlets to XIB objects in iOS are not automatically retained and memory managed, this may change with iOS 5, but is somewhat unlikely.

The rationale there is so that you can release any view objects in - (void)viewDidUnload, and get rid of any views that you either don't need, or can re-initialize on -(void)viewWillAppear. But the goal is, ostensibly, to keep you in control of what is collected and what is not.

my pattern is to just declare normal cocoa accessors for them as I would for any other properties and set them to nil in the viewDidUnload

- (void)viewDidUnload
{
    [super viewDidUnload];
    self.buttonOne = nil;
    self.buttonTwo = nil;
    self.buttonThree = nil;
    self.buttonFour = nil;
    self.buttonFive = nil;
    self.buttonSix = nil;
    self.lineWidthSlider = nil;
    // Release any retained subviews of the main view.
    // e.g. self.myOutlet = nil;
}

You are right, however in that it doesn't really make much sense to have the retain for the window, but it makes sense for consistency IMHO. So long winded way of saying yes, in my experience the app delegate does need to retain the UIWindow or it can be collected in a memory sweep and cause somewhat random crashes.

It appears that the app delegate does need to retain the window UIWindow.

The default implementation of the application delegate in a new Xcode project includes:

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {

    var window: UIWindow?

}

If you remove the window property and instead use a local variable, the app will launch to a black screen.

Xcode will also log the error:

[Application] The app delegate must implement the window property if it wants to use a main storyboard file.

The app delegate must implement the window property if it wants to use a main storyboard file swift


Setting the window property as weak will similarly launch a black screen. Xcode displays the error when you assign a UIWindow to the property:

Instance will be immediately deallocated because property 'window' is 'weak'

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM