A new feature of iOS9 ipad Slideview and Splitview adaptation

Apple has just released IOS9, adding two new features to the ipad, Slideview and Splitview, which can be paged out without shutting down the current activation app, with a 30% scale display, which allows two apps to run at 50% 50%, 70%30% ratio operation, feel very convenient.

However, the user's convenience while the developer, in the same screen running two apps when the app display scale changes, then you need to deal with several different sizes, fortunately, Apple has AutoLayout, and in IOS8 new Sizeclass features, the combination of the two, Can be very good to deal with all the above situations.

Well, to fit the iOS9 above, take a look at how Apple's documentation explains how to handle multiple display scales. Adopting multitasking enhancements on the ipad is a good description of the situation, the main thing is to understand a picture first.

　　

The new Sizeclass in iOS8 a good understanding of the contents of the picture, C (Compact) compact, R (Regular) general, through the combination of C and R can match a variety of screens, If you do not understand the most intuitive can be seen in the storyboard set AutoLayout time at the bottom of the "W any h" can be moved by the mouse to draw a variety of combinations can be adapted to which screen, here is no longer elaborated.

This figure shows that in the ipad standard screen scale, width and height are r, that is, whether the horizontal screen or vertical screen is the general combination of WR HR, however, in the case of split and slide after the state of the change, in the vertical state of the app is split after the advent of the WC HR, In the horizontal screen state, there are two combinations are the main app70% from the app30% and the main app50% from the app50%, through the picture in the horizontal screen 7:3, the main app ratio is WRHR, from the app is WCHR, in 5:5 cases the master and slave app are WCHR, Then you know the various high-wide combinations of apps in the Slideview and Splitview states.

To summarize the various needs of the app after slide and split the size is, 100% general state, 70% as the state of the main app, 50% as the state of Split, 30% as the appearance of the app when the state. Since 100% and 70% belong to WRHR, then our main adaptation is divided into three cases 100%,50%,30%, if the app interface is mainly list-based or relatively simple layout, in fact, as long as the appropriate adjustment of the value of AutoLayout offset can be adapted to all cases, So if it is a more complex interface or need to meet the various state of the display what to do, of course, there is a solution, the following are mainly simple code examples of adaptation work, the main understanding of the principle and know when to trigger the display scale changes, There is also a way to match all the above conditions through the storyboard Sizeclass and adjust the difference, this way is relatively simple to use xib should be easy to solve, the disadvantage is to maintain a little inconvenient.

First of all, there is a need to place a red uiview on the screen, in normal state, left and right margin 100 pixels, and a label to show the current scale, when the departure split or slide, the UIView border adjustment to 10 pixels. The specific results are as follows:

　　

　

　　

For normal full screen, after Splitview.

First, the code first adds a red UIView and a label to the view to show the current state.

1var testingview:uiview!2var collectionstatelabel:uilabel!3 4Testingview =UIView ()5Testingview.backgroundcolor =Uicolor.redcolor ()6 Self.view.addSubview (Testingview)7         8Collectionstatelabel =UILabel ()9Collectionstatelabel.textalignment =Nstextalignment.centerTenCollectionstatelabel.textcolor =Uicolor.blackcolor () OneSelf.view.addSubview (Collectionstatelabel)

Then, starting to analyze the actual situation, through the simulator or the real machine to use, you will find that when the application starts, there may be several cases, the red number represents my app display scale

Scenario 1 If I'm looking at a photo and suddenly want to open the app to see something, there are a few things that happen at this point.

1 The program starts with Slideview. (Ten:3)

2 after the launch through the Slideview and began to Splitview. (5:5)

3 after the use of Splitview I feel uncomfortable, too small, and then want to further expand and become full screen. (0:ten)

Scenario 2 If I'm using the app, I want to see a map of where the building is, and there are a few things that happen.

1 when the program is in use, accept the map program to cut in slide mode, when the map program is activated, you can query the map (3)

2 I have to use my app back when I query the map, when my app is activated and the map is activated (7: 3)

3 I would like to enlarge the map program by the map with Splitview cut in half to show. (5: 5)

From the summary above, scene 1 My app is as from app, photo is main app, Scene 2 My app is present as main app, map program is from app, actually this is not important, The main conclusion is that at the outset of the layout, it is necessary to consider different scenarios to accommodate different layout requirements.

Now that the code layout is started, and the code layout uses a third-party class library to save code, Apple's API is very cumbersome, using Snapkit as the Layout class library (https://github.com/SnapKit/SnapKit), OC version (Https://github.com/SnapKit/Masonry)

From the scene analysis of the need to know at the beginning of the current screen in what proportion, then through the beginning of the article analysis of the Apple document that the ratio of slide and split is WC HR means that the width is compact vertical is the standard. Then it can be judged by the Sizeclass API.

if self.traitCollection.verticalSizeClass = = Uiuserinterfacesizeclass.regular && Self.traitCollection.horizontalSizeClass = =            uiuserinterfacesizeclass.compact{//Slide or split size slide and split state            }else{            //regular size standard state         }

Through the Uitraitcollection class can get the current screen in what kind of scale, this class encapsulates a variety of horizontal vertical direction, such as sizeclass information, through the implementation of Uitraitenvironment interface object can get this property, (This interface is implemented by Uiviewcontroller,uiview,uiwindow,uiscreen). By judging the various combinations of properties Verticalsizeclass and Horizontalsizeclass, it is easy to get the horizontal vertical ratio of the current screen.

At this point, the screen display scale is judged out, then according to the requirements and the actual situation to write a different proportion of the appropriate code can be, here according to demand under the regular button left and right margin 100 pixels, split under the button about 10 pixels.

　　

func setviewtoregularsize () {Collectionstatelabel.text="state:regular View"Guard TestingView.constraints.isEmptyElse{testingview.snp_updateconstraints {(make)-VoidinchMake.left.equalTo (self.view.snp_left). Offset ( -) Make.right.equalTo (self.view.snp_right). Offset (- -) Make.centerY.equalTo (Self.view.snp_centerY)}return} testingview.snp_makeconstraints {(make)-VoidinchMake.left.equalTo (self.view.snp_left). Offset ( -) Make.right.equalTo (self.view.snp_right). Offset (- -) Make.centerY.equalTo (Self.view.snp_centerY) make.height.equalTo ( -)}}} func Setviewtoslidesplitsize () {Collectionstatelabel.text="State:splitview or Slideview"Guard TestingView.constraints.isEmptyElse{testingview.snp_updateconstraints (closure: {make)-VoidinchMake.left.equalTo (self.view.snp_left). Offset (Ten) Make.right.equalTo (self.view.snp_right). Offset (-Ten) Make.centerY.equalTo (Self.view.snp_centerY)})return} testingview.snp_makeconstraints {(make)-VoidinchMake.left.equalTo (self.view.snp_left). Offset (Ten) Make.right.equalTo (self.view.snp_right). Offset (-Ten) Make.centerY.equalTo (Self.view.snp_centerY) make.height.equalTo ( -)        }    }

We set up two functions for the first function to fit the case of regular, the second function fits the case of split or slide, and is labeled on the label, where Swift guard ... else {} is used to determine if the constraint is updated if the constraint is not empty, otherwise a constraint is added. For snapkit usage specifics, see git, just for example. The corresponding function is now called at initialization time to complete the display adaptation when the app starts. and give the label a good restraint.

　　

        ifTraitcollection.verticalsizeclass = = Uiuserinterfacesizeclass.regular && Self.traitCollection.horizontalSizeClass = =uiuserinterfacesizeclass.compact{//slide or split sizeself.setviewtoslidesplitsize ()}Else{            //Regular Sizeself.setviewtoregularsize ()} collectionstatelabel.snp_makeconstraints {(make)-VoidinchMake.top.equalTo (testingview.snp_bottom). Offset ( -) Make.centerX.equalTo (Testingview.snp_centerx)}

By the time this step has been fulfilled, the app has been adapted from the slide when it comes in. However, it's not that simple, and with the scenario, you can transition from slide to split, or even from split to regular, without satisfying the current size, and it involves changing the layout dynamically. Fortunately, Apple's API provides a function to change the current sizeclass. Enter the following code in the Viewcontroller

 override   func Willtransitiontotraitcollection (Newcollection:uitraitcollection, Withtransitioncoordinator Coordinator: Uiviewcontrollertransitioncoordinator) {super.willtransitiontotraitcollection (newcollection, Withtransitioncoordinator:coordinator)  if  Newcollection.verticalsizeclass = = Uiuserinterfacesizeclass.regular && Newcollection.horizontalsizeclass = =  uiuserinterfacesizeclass.compact{self.setviewtoslidesplitsize ()}  else  {self.setviewtoregularsize ()}}  

This function is similar to the previous willrotatetointerfaceorientation (tointerfaceorientation: uiinterfaceorientation, Duration: Nstimeinterval) As with the logic of rotating the screen, as soon as the sizeclass is changed, it is easy to update the current layout according to the scale rules of slide and split provided by the Apple document within the function.

At this point, we have fully met the needs and scenarios 1 and 2 of the situation, in summary, as long as the sizeclass of the various proportions can easily cope with a variety of screen display changes, and then through the cooperation with the AutoLayout to meet a variety of size and dynamic change in size requirements. Finally, although the new features that Apple introduces are seemingly complex, the old techniques are used to solve all kinds of situations, sizeclass and AutoLayout are like double swords, without fear of any size change.

aside, if you are accustomed to using xib the same way as before, you only need to match the combination of compact and regular and set the corresponding constraints and install the corresponding view is very easy to deal with slide and split

　　

Only need to move the mouse to modify the constraints are also very good to meet the actual situation, just storyboard maintenance and readability is not very friendly, the code may be easier to make changes to maintain and abstract, the actual application of my code to use more points.

A new feature of iOS9 ipad Slideview and Splitview adaptation