Conclusion:
1> If direction control is added to rootviewcontroller, its sub-views inherit the direction control of rootviewcontroller by default.
The sub-view is interpreted as follows:
1. If rootviewcontroller is a common uiviewcontroller, the method that comes in through the presentviewcontroller method is also called a subview. At the same time, this method is also affected by info. restrictions of plist, they are inheritance relationships, can also overwrite the parent class settings, but the coverage range can only be smaller and smaller
2> If rootviewcontroller is a navigation uinavigationcontroller, there are two more cases:
1. For each seed page that comes in through push, you must keep up with the settings on the navigation bar. This may only work with it through category, in addition, each sub-page inherits the parent class settings, and the sub-page cannot be set independently. Unless uinavigationcontroller gives control to each sub-page, the sub-page can be set separately, but it also has an inheritance relationship with the settings of the parent class. It can also overwrite the settings of the parent class, but the coverage range can only be smaller and smaller.
2 presentviewcontroller can only set the seed pages on its own. It does not have any inheritance relationships with the uinavigationcontroller settings and has no connection.
3> you can add a subview directly on the uiwindow. This view is not restricted by info. plist.
Test results:
1> In plist, supported interface orientations,ProgramTurn on the default direction, which is irrelevant to the order set here! It depends on the current direction of the device when it is turned on.
2> if no direction is set in the program, the supported interface orientations setting takes effect only for all pages.
3> info. plist is supported in all directions, and then shouldautorotate is set to no in rootviewcontroller, it will not be rotated at all, and the default direction of opening is also the vertical screen, indicating that this setting will overwrite info. plist settings
4> info. plist: Set shouldautorotate to yes in rootviewcontroller and
-(Nsuinteger) supportedinterfaceorientations {
Return uiinterfaceorientationmaskallbutupsidedown;
}
Test result: the screen is no longer rotated when the button is facing up.
3, 4 indicates that the settings in the program will overwrite the settings of info. plist.
5> set info. plist to support only landscape (landscape left, landscape right), set shouldautorotate to yes in rootviewcontroller, and set
-(Nsuinteger) supportedinterfaceorientations {
Return uiinterfaceorientationmaskallbutupsidedown;
}
At this time, the screen can only work in Landscape mode.
The info. plist settings take effect. If the range of the info. plist rotation direction is largeCodeIf Info. plist is set to a smaller range, it is invalid to expand the range in the code.
6> On the basis of Step 5, add a button to the first page and click to enter the second page (secondpage)
1. The second page is not set. It is found that the rotation of the second page inherits the rootviewcontroller settings and can only be landscape
- Secondpage: shouldautorotate is set to No. It is found that the first page can be rotated normally and the second page will not be rotated. This indicates that the subsequent settings will overwrite the rootviewcontroller settings!
- Set shouldautorotate to yes on secondpage, and then set
- -(Nsuinteger) supportedinterfaceorientations {return uiinterfaceorientationmasklandscapeleft ;}
It is found that the first page can be rotated normally, and the second page can only be left
- On the basis of, set-(nsuinteger) supportedinterfaceorientations {return uiinterfaceorientationmaskall;} found that the second page can only be left and right, and cannot be rotated in any of the four directions
, 4, indicating that the child page inherits the settings of the parent page, and the Child page can also overwrite the settings of the parent page, however, the coverage range can only be smaller and smaller.
The above test shows the general rootviewcontroller. In normal present scenarios, if it is under uinavigationcontroller, what about push?
Start testing the push status of uinavigationcontroller.
The above test results are different. We found that the pages pushed in include the uinavigationcontroller initialized in appdelegate at the beginning.
The first controller, similar to this
[[Uinavigationcontroller alloc] initwithrootviewcontroller: firstpage
Setting rotation in firstpage and secondpage is invalid.
It indicates that the ios6 rotation can only be performed under the root controller. In the case of uinavigationcontroller, the root is uinavigationcontroller, not firstpage!
Therefore, we add the category of uinavigationcontroller to solve the rotation setting.
Add a uinavigationcontroller + rotate file.
Then set
-(Bool) shouldautorotate
{
Return no;
}
If the image is not rotated, only the portrait screen is displayed.
Then we set support for all directions in info. plist, and then set it in uinavigationcontroller + rotate. M.
-(Bool) shouldautorotate
{
Return yes;
}
-(Nsuinteger) supportedinterfaceorientations
{
Return uiinterfaceorientationmasklandscape;
}
It is found that only the landscape screen takes effect. This setting overwrites the info. plist setting and can only be overwritten in a small range.
Continue modification:
-(Nsuinteger) supportedinterfaceorientations
{
Return [self. topviewcontroller supportedinterfaceorientations];
}
-(Bool) shouldautorotate
{
Return [self. topviewcontroller shouldautorotate];
}
This setting is equivalent to assigning the permission to the following sub-views, because each sub-view can set its own rotation direction based on its own situation.
In uinavigationcontroller, how does one add a subpage with the present?
In the case of push, if uinavigationcontroller + rotate does not control the sub-page, the sub-page settings are invalid.
However, if you use the present to add a subpage, the control is effective and does not inherit any settings of uinavigationcontroller + rotate.
Conclusion:
For a common rootviewcontroller, add a sub-page, that is, add a sub-page using the present method. This takes effect in this case.
Info. plist ---> rootviewcontroller ---> subview settings. Their settings are inherited, but they can be overwritten, but the range of the settings can only be smaller and smaller.
If rootviewcontroller is uinavigationcontroller and uitabcontroller, there are two possibilities.
1. In this case, only the uinavigationcontroller's category can be used to set the rotation of the subpage. The subpage settings are invalid. of course, the category of uinavigationcontroller can also assign control permissions to specific subpages. This is also the case.
Info. plist ---> uinavigationcontroller ---> subview. They are inheritance relationships and the range can only be set to smaller and smaller.
2. When the present comes in, the page that the present comes in is not controlled by the uinavigationcontroller, and there is no inheritance relationship. You need to set whether to rotate or not and set the rotation direction independently.
Also compatible with ios5:
The ios5 screen rotation is relatively simple and there is no iofo. List support or restriction. Therefore, setting info. plist in ios5 is invalid.
Ios5 only needs to set a method on the page to be rotated
-(Bool) Shouldautorotatetointerfaceorientation :(Uiinterfaceorientation) Interfaceorientation
{
}
The items that can be rotated are:
Uiinterfaceorientationportrait // vertical uiinterfaceorientationportraitupsidedown // reverse uiinterfaceorientationlandscapeleft // home left uiinterfaceorientationlandscaperight/home right
Therefore, ios5 compatibility must be set separately on the page.
Welcome to the IOS technology exchange group: 190956763. Learn and make progress together!