Differencebetween Uiapplication.Sharedapplication.Delegate.Window and Uiapplication.Sharedapplication.Keywindow

What is the difference between UIApplication.sharedApplication.delegate.window and UIApplication.sharedApplication.keyWindow?

They could be the same on iOS. When they are different, usually you are presenting another window other than the app delegate's main window. Your app can have many windows but only the keyWindow is the window that is visible on the screen and receiving events (example could be a UIAlert when visible and receiving events it is the keywindow) reference: https://developer.apple.com/library/content/documentation/WindowsViews/Conceptual/WindowAndScreenGuide/WindowScreenRolesinApp/WindowScreenRolesinApp.html

from the documentation:

  • For UIApplication.sharedApplication.delegate.window:

The window to use when presenting a storyboard. This property contains
the window used to present the app’s visual content on the device’s
main screen.

i.e this is the property window that you have in your AppDelegate.h file.

  • For UIApplication.sharedApplication.keyWindow:

This property holds the UIWindow object in the windows array that is
most recently sent the makeKeyAndVisible message.

On iOS you call makeKeyAndVisible in your AppDelegate.m inside

application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions

You made the created appDelegate window the keyWindow. Usually, bank apps switch the key window when the app is put in the background to protect the users sensitive information when the home button is doubled tapped and switch back to the main delegate window when the app is in foreground.

This answer is in collaboration with: @SipkeSchoorstra, @D-Mx and @andyDarwin

what's the difference between self.view.widow and [[UIApplication sharedApplication] keyWindow] in Objective-C

Your question is essentially addressed here:

diffrence between [[[[UIApplication sharedApplication] delegate] window] and [[UIApplication sharedApplication].keyWindow?

To tie it back to your question, the UIAlertView gets presented in a system window, and it is this window that is the keyWindow while your alert is being shown. When the alert is dismissed, that window disappears, hence why your view disappears.

Assuming that self.view is a subview of the app's window (almost always the case), your view continues to display because the window itself continues to be displayed after the alert is dismissed.

UIApplication sharedApplication - keyWindow is nil?

This code was executed before [window makeKeyAndVisible]; which is inside the app delegate.
So, no wonder why keyWindow was nil yet.

(Objective-C) Difference between accessing the navigation stack through the window.rootView and keyWindow

  1. The navigationController property on UIViewController is nullable, so it may return nil.

  2. The topViewController property on UINavigationController is also nullable, and returns a UIViewController?, not a specific class. Simply casting any UIViewController to ViewController is not safe, so you should be checking against isKindOfClass.

  3. Same thing applies for rootViewController, it may not always be a TabBarController, so casting it unconditionally is unsafe.

  • also, found out that if rootViewController is of type UITableViewController, the navigationController is nil.

accessing window property app delegate iOS

Option1 use KVC

id appDelegate = [UIApplication sharedApplication].delegate;
UIWindow *window = [appDelegate valueForKey:@"window"];

Option2 use keywindow property of UIApplication

UIWindow *keyWindow = [[UIApplication sharedApplication] keyWindow];

This property holds the UIWindow object in the windows array that is most recently sent the makeKeyAndVisible message.

Option3 use windoss property of UIApplication

NSArray *array = [[UIApplication sharedApplication] windows];

This property contains the UIWindow objects currently associated with the app. This list does not include windows created and managed by the system, such as the window used to display the status bar.

The windows in the array are ordered from back to front by window level; thus, the last window in the array is on top of all other app windows.



Related Topics



Leave a reply



Submit