Explain the UIWindow use _ios in IOS design

Each iOS program has a uiwindow, when we work through the template resume project, Xcode will automatically help us generate a window, and then let it become keywindow and display. It all comes so naturally that most of the time we forget that we can also create UIWindow objects.

Usually when we need to customize Uialertview (IOS 5.0 alertview background style, etc.) we can use UIWindow to implement (set Windowlevel to alert level), there are many examples on the Internet, here is not in detail.
First, Uiwindowlevel

We all know that there are three levels of UIWindow, respectively, Normal,statusbar,alert. Print out the values of the three of these three levels we found the 0,1000,2000 from left to right, that is, the normal level is the lowest, StatusBar is at the middle level and the alert level is highest. And usually our program interface is at the normal level, the system at the top of the status bar should be at the statusbar level, Uiactionsheet and uialertview these are usually used to interrupt the normal process, to remind users and other operations, Therefore, at the alert level.

In the previous article I also mentioned a conjecture, since three levels of value between 1000, and we carefully look at the UIWindow header file will find that there is an instance variable _windowsublevel, then we can define many intermediate level window. For example, you can customize windows that are a bit lower than the system Uialertview level. So wrote a small demo, through the print found the system's Uialertview level is 1996, and at the same time Uiactionsheet level is 2001, this also verifies that Sublevel does exist.

Copy Code code as follows:

Uialertview *alertview = [[Uialertview alloc] initwithtitle:@ "Alert View"
message:@ "Hello wolrd, i ' m alertview!!!"
Delegate:nil
cancelbuttontitle:@ "OK"
otherbuttontitles:@ "Cancel", nil];
[Alertview show];
[Alertview release];

Uiactionsheet *actionsheet = [[Uiactionsheet alloc] initwithtitle:@ "Actionsheet"
Delegate:nil
cancelbuttontitle:@ "Cancel"
destructivebuttontitle:@ "Don ' t do that!"
otherbuttontitles:@ "Hello wolrd", nil];
[Actionsheet ShowInView:self.view];
[Actionsheet release];

The following is a screenshot of the program running:

According to the window display level priority principle, the level of high will be shown above, lower level below, our program is normally displayed in the bottom of the view, as to the specific how to obtain Uialertview and uiactionsheet levels, I will introduce and give the corresponding code in the second part of Keywindow below.

UIWindow are sorted according to the Uiwindowlevel when they are displayed, that is, the level high will be in front of all levels lower than his. Now let's look at the definition of Uiwindowlevel:

Copy Code code as follows:

Const Uiwindowlevel Uiwindowlevelnormal;

Const Uiwindowlevel Uiwindowlevelalert;

Const Uiwindowlevel Uiwindowlevelstatusbar;

　　　

typedef cgfloat Uiwindowlevel;
The iOS system defines three window hierarchies, each of which can be divided into a number of subcategories (the member variable CGFloat _windowsublevel can be seen from the UIWindow header file), but the system does not open the attribute. The default level of UIWindow is uiwindowlevelnormal, and the values of the three levels we print out are as follows:

2012-03-27 22:46:08.752 uiviewsample[395:f803] Normal window level:0.000000

2012-03-27 22:46:08.754 UIViewSample[ 395:f803] Alert window level:2000.000000

2012-03-27 22:46:08.755 uiviewsample[395:f803] Status window level: 1000.000000 

This confirms their level of high and low order from small to large for normal < StatusBar < Alert, below please see the small test code:

Copy Code code as follows:

-(BOOL) Application: (UIApplication *) application didfinishlaunchingwithoptions: (nsdictionary *) launchOptions
{
Self.window = [[[UIWindow alloc] initwithframe:[[uiscreen mainscreen] bounds]] autorelease];
Self.window.backgroundColor = [Uicolor Yellowcolor];
[Self.window makekeyandvisible];

UIWindow *normalwindow = [[UIWindow alloc] initwithframe:[[uiscreen mainscreen] bounds]];
Normalwindow.backgroundcolor = [Uicolor Bluecolor];
Normalwindow.windowlevel = Uiwindowlevelnormal;
[Normalwindow makekeyandvisible];

CGRect windowrect = CGRectMake (50,
50,
[[UIScreen Mainscreen] bounds].size.width-100,
[[UIScreen Mainscreen] bounds].size.height-100);
UIWindow *alertlevelwindow = [[UIWindow alloc] initwithframe:windowrect];
Alertlevelwindow.windowlevel = Uiwindowlevelalert;
Alertlevelwindow.backgroundcolor = [Uicolor Redcolor];
[Alertlevelwindow makekeyandvisible];

UIWindow *statuslevelwindow = [[UIWindow alloc] Initwithframe:cgrectmake (0, 50, 320, 20)];
Statuslevelwindow.windowlevel = Uiwindowlevelstatusbar;
Statuslevelwindow.backgroundcolor = [Uicolor blackcolor];
[Statuslevelwindow makekeyandvisible];

NSLog (@ "Normal window level:%f", uiwindowlevelnormal);
NSLog (@ "Alert window level:%f", Uiwindowlevelalert);
NSLog (@ "Status window level:%f", Uiwindowlevelstatusbar);

return YES;
}

The results of the operation are shown below:

We can notice two points:

1 The Normalwindow we generate is called makekeyandvisible after the first default window, but it is still not displayed. This means that when level levels are the same, only the first one is shown as Keywindow, and then the next sibling setting Keywindow is not displayed.

2) Statuslevelwindow calls makekeyandvisible after Alertlevelwindow, still only appears below the Alertlevelwindow. This means that when UIWindow is displayed, no matter who Keywindow is, it is level priority, that is, the highest level is always displayed at the front.

Second, Keywindow

What is Keywindow, as explained in the official document, "The key window is the one of this is designated to receive keyboard and Non-touch related Ts. Only one window in a time will be the key window. That is, Keywindow is a specified message to receive the keyboard as well as a non touch class, and a window is keywindow at every moment in the program.

Let's write a simple example to see if Keywindow can accept keyboard messages and touch messages, in which we add a uitextfield to the view and create a new alert-level window. And then through the makekeyandvisible let it become Keywindow and show it. The code is as follows:

Copy Code code as follows:

-(BOOL) Application: (UIApplication *) application didfinishlaunchingwithoptions: (nsdictionary *) launchOptions
{
Self.window = [[[UIWindow alloc] initwithframe:[[uiscreen mainscreen] bounds]] autorelease];
Override point for customization after application launch.
Self.viewcontroller = [[[Svuiwindowviewcontroller alloc] initwithnibname:@ "Svuiwindowviewcontroller" Bundle:nil] Autorelease];
Self.window.rootViewController = Self.viewcontroller;
[Self.window makekeyandvisible];

UIWindow *window1 = [[UIWindow alloc] Initwithframe:cgrectmake (0, 80, 320, 320)];
Window1.backgroundcolor = [Uicolor Redcolor];
Window1.windowlevel = Uiwindowlevelalert;
[Window1 makekeyandvisible];

return YES;
}

Copy Code code as follows:

-(void) viewdidload
{
[Super Viewdidload];
Do no additional setup after loading the view, typically from a nib.

[Self registerobserver];

Add a TextField
Uitextfield *filed = [[Uitextfield alloc] Initwithframe:cgrectmake (0, 0, 320, 60)];
Filed.placeholder = @ "Input something here";
filed.clearsonbeginediting = YES;
Filed.borderstyle = Uitextborderstyleroundedrect;
[Self.view addsubview:filed];
[Filed release];
}

Run the screenshot as follows:

As can be seen from the figure, although we created a new one and then set to Keywindow and display, but click on the default window in the program to add TextField can also call out the keyboard, but also normal to accept keyboard input, but the keyboard is blocked, Note that Keywindow can also accept keyboard messages, which is not the same as the documentation.

Looking at UIWindow's documentation, we can see that there are four notices about window changes:

　　

Uiwindowdidbecomevisiblenotification
 
uiwindowdidbecomehiddennotification
 
Uiwindowdidbecomekeynotification
 
uiwindowdidresignkeynotification

object in these four notification objects represents a Window object that is currently displayed (hidden) and has become keywindow (not Keywindow), where the userinfo is empty. So we can register this four messages, and then print the information to observe the Keywindow changes and window display, hidden changes.

The code is as follows:

According to the printed information we can see that the process is as follows:

1, the Program default window first show

2, the default window again become Keywindow

3, Alertview window display

4, the default window becomes a non keywindow

5, the final Alertview window becomes Keywindow

Generally speaking, "to be the Boss (Keywindow), first from the younger brother (Keywindow) began to mix" and according to the printed information, our colleagues can know the default window level is 0, that is, normal levels The level of Alertview's window is 1996, slightly lower than alert.

b, when we open the Viewdidappear "[Self presentactionsheet];" , the console output is as follows:

The Keywindow change is the same as the window display and the above process, and we can see that the level of the Actionsheet window is 2001.

C, the next step, we click on the pop-up Actionsheet cancel, the console output is as follows:

We see the process as follows:

1, first Actionsheet window becomes a non-Keywindow

2, the Program default window becomes Keywindow

3, Actionsheet window is hidden away

The general is "want to hide behind the scenes can, but must first surrender the right."