First recognized iOS9 iPad new features SlideView and SplitView adaptation, ios9ipad

First recognized iOS9 iPad new features SlideView and SplitView adaptation, ios9ipad

Apple just released iOS9 and added two new features, SlideView and SplitView, on the iPad, the former can be lowered without disabling the current APP activation. The other apps are displayed at a rate of 30%. The latter allows two apps to run at a rate of 50% to 50%, it is very convenient.

However, this makes it easier for users to get bored with developers. When running two types of apps on the same screen, the display ratio of the apps will change. In this case, several different sizes need to be processed, fortunately, Apple has Autolayout and added the SizeClass feature in ios8. the combination of the two can well cope with the above situations.

Well, in order to adapt to the features described above in iOS9, let's take a look at Apple's documentation to illustrate how to deal with the problem of multiple display ratios. Adopting Multitasking Enhancements on iPad provides a good description of this situation. The most important thing is to first understand an image.

　　

The new SizeClass in ios8. it can understand the image content very well. C (Compact) is Compact, and R (Regular) is conventional. Through the combination of C and R, various screens can be matched, if you do not understand the most intuitive view, you can view the w Any h Any at the bottom of the StoryBoard when Autolayout is set. You can move the mouse to find the screen that can be adapted to different combinations, I will not describe it here.

This figure shows that the width and height of the standard screen ratio on the iPad are both R, that is, whether the horizontal screen or the vertical screen is a conventional combination, that is, wR hR, however, after split and slide appear, the status changes. In the portrait status, after the APP is split, wC hR appears. In the landscape status, there are two combinations: Master APP70 % from APP30 % and master APP50 % from APP50 %. The figure shows that in on the horizontal screen, the proportion of the master APP is wRhR, the proportion of the APP is wChR. in the case of, the master and slave apps are both wChR, so we know the various combinations of height and width of the APP in the slideView and splitView states.

To sum up the size that the APP needs to adapt to after Slide and Split is 100% normal status, 70% as the status of the main APP, and 50% as the split status, 30% is the status when the APP appears. Since both 100% and 70% belong to wRhR, our main adaptation is divided into three scenarios: 100%, 50%, and 30%. If the APP interface is mainly list-based or relatively simple, in fact, you only need to adjust the offset Value of Autolayout to adapt to all situations. What if it is a complicated interface or needs to meet the display requirements in various States? Of course, there is a solution, the following is an example of simple code for adaptation. It mainly understands the principle and knows when to trigger the display ratio change. Another way is to use the Storyboard's SizeClass to match all the above conditions and adjust the difference one by one, this method is relatively simple and should be easy to solve when XIB is used. The disadvantage is that it is slightly inconvenient to maintain.

First, you need to place a red UIView on the screen. Normally, the border between the left and right sides is 100 pixels, and a label shows the current proportion, when split or slide is set, the left and right sides of the UIView are adjusted to 10 pixels. The specific results are as follows:

　　

　

　　

For normal full screen, after splitView.

First, add a red UIView and a label to the view to display the current status.

 1  　　　　var testingView:UIView! 2  　　　　var collectionStateLabel:UILabel! 3  4         testingView = UIView() 5         testingView.backgroundColor = UIColor.redColor() 6         self.view.addSubview(testingView) 7          8         collectionStateLabel = UILabel() 9         collectionStateLabel.textAlignment = NSTextAlignment.Center10         collectionStateLabel.textColor = UIColor.blackColor()11         self.view.addSubview(collectionStateLabel)   

Next, start to analyze the actual situation. After using the simulator or a real machine, you will find that there may be several situations when the application is started. The red number indicates the proportion shown by my APP.

Scenario 1 if I am browsing a photo and suddenly want to open the APP to view something, then there will be several situations.

1. The program is started with SlideView. (10: 3)

2. After being started through SlideView, The SplitView is expanded. (5: 5)

3. After using SplitView, I felt uncomfortable. It was too small. I wanted to expand it further and become a full screen. (0: 10)

Scenario 2 if I am using an APP, I want to use a map to view the location of a building. Several situations may occur at this time.

1. When the program is in use, accept the map program to cut in the slide mode. At this time, the map program is activated and can query the map)

2. When querying a map, I still need to use my APP. At this time, my APP is activated and the map is also activated)

3. I want to zoom in the Map Program. The map is cut into half a display by SplitView. (5: 5)

As shown in the preceding figure, scenario 1: My APP exists as a slave APP, the photo is a master APP, Scenario 2: My APP exists as a master APP, and the map APP is a slave APP, in fact, this is not important. The main conclusion is that at the beginning of the layout, we must consider different scenarios to meet different layout requirements.

Now start code layout, code layout uses a third-party class library to save the amount of code, Apple's API is really very cumbersome, here using SnapKit as the layout class library (https://github.com/SnapKit/SnapKit ), OC version (https://github.com/SnapKit/Masonry)

From scenario 1 and 2, you need to know the proportion of the current screen at the beginning, the Apple document analyzed at the beginning of this article shows that the ratio of slide to split is wC hR, that is, width is compact and vertical is the standard. The SizeClass API can be used to determine whether to enable this function.

If self. traitCollection. verticalSizeClass = UIUserInterfaceSizeClass. regular & self. traitCollection. horizontalSizeClass = UIUserInterfaceSizeClass. compact {// slide or split size slide and split status} else {// regular size standard status}

The UITraitCollection class can be used to obtain the proportion of the current screen. This class encapsulates information about SizeClass in various horizontal and vertical directions. This attribute can be obtained by the objects that implement the UITraitEnvironment interface, (UIViewController, UIView, UIWindow, and UIScreen all implement this interface ). By judging the combinations of verticalSizeClass and horizontalSizeClass, you can easily obtain the horizontal and vertical ratio of the current screen.

At this point, the screen display ratio is determined, so you can write the adaptation code at different ratios based on the needs and actual situations. Here, we will set the button margin to 100 pixels at the left and right of the regular button as needed, the split button is about 10 pixels long.

　　

    func setViewToRegularSize(){         collectionStateLabel.text = "State:Regular View"        guard testingView.constraints.isEmpty else{            testingView.snp_updateConstraints { (make) -> Void in                make.left.equalTo(self.view.snp_left).offset(100)                make.right.equalTo(self.view.snp_right).offset(-100)                make.centerY.equalTo(self.view.snp_centerY)            }            return        }        testingView.snp_makeConstraints { (make) -> Void in            make.left.equalTo(self.view.snp_left).offset(100)            make.right.equalTo(self.view.snp_right).offset(-100)            make.centerY.equalTo(self.view.snp_centerY)            make.height.equalTo(60)        }    }        func setViewToSlideSplitSize(){         collectionStateLabel.text = "State:SplitView or SlideView"        guard testingView.constraints.isEmpty else{            testingView.snp_updateConstraints(closure: { (make) -> Void in                make.left.equalTo(self.view.snp_left).offset(10)                make.right.equalTo(self.view.snp_right).offset(-10)                make.centerY.equalTo(self.view.snp_centerY)            })            return        }        testingView.snp_makeConstraints { (make) -> Void in            make.left.equalTo(self.view.snp_left).offset(10)            make.right.equalTo(self.view.snp_right).offset(-10)            make.centerY.equalTo(self.view.snp_centerY)            make.height.equalTo(60)        }    }

We have set the first function of two functions to adapt to regular, the second function to adapt to Split or Slide, and respectively label them on the label. Here we use swift guard... else {} is used to determine whether to update the constraint if the constraint is not empty. Otherwise, the constraint is added. For details about the usage of snapkit, refer to the GIT instructions. Here is only an example. Now you can call the corresponding functions at initialization to complete the display adaptation during APP startup. And impose constraints on the label.

　　

        if traitCollection.verticalSizeClass == UIUserInterfaceSizeClass.Regular && self.traitCollection.horizontalSizeClass == UIUserInterfaceSizeClass.Compact{            //slide or split size            self.setViewToSlideSplitSize()        }else{            //regular size            self.setViewToRegularSize()        }        collectionStateLabel.snp_makeConstraints { (make) -> Void in            make.top.equalTo(testingView.snp_bottom).offset(50)            make.centerX.equalTo(testingView.snp_centerX)        }

This step has been met, and the adaptation of the APP when it comes in from slide. However, the process is not that simple. We can use scenario 1 and 2 to conclude that, if the current size is not satisfied, we can transition from slide to split, or even transition from split to regular, then it involves Dynamic Layout Change. Fortunately, Apple's API provides a function to change the current sizeClass. Enter the following code in 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 logic used to process the rotating screen by willRotateToInterfaceOrientation (toInterfaceOrientation: UIInterfaceOrientation, duration: NSTimeInterval). When the sizeClass changes, it is called immediately, in this function, the current layout is easily updated based on the slide and split ratio rules provided by the Apple documentation.

So far, we have fully met the needs and scenarios 1 and 2. In summary, as long as we know the proportional combinations of sizeClass, we can easily cope with changes in various screen display situations, in addition, it works with Autolayout to meet various sizes and dynamically change sizes. Finally, although Apple's new features seem complicated, they still use old technologies to solve various situations. sizeClass and autolayout work together like a pair of swords and walls without fear of any size changes.

If you are used to using XIB, the usage is the same as before, you only need to match the combination of various Compact and Regular and set the corresponding constraints, and Install the corresponding View is also very easy to deal with Slide and Split

　　

You only need to move the mouse to modify the constraints to meet the actual conditions, but the maintainability and readability of the storyboard are not very friendly, and the code may be easier to modify, maintain, and abstract, in actual application, my code is mostly used.