Zero

## IOS 11 security zone adaptation summary

ReadOne thousand eight hundred and fifty-one

Introduction: This article is a summary of the adaptation of 64pt APP under iOS 11, tableView content in FM, 20pt down or down. The content includes five parts: the cause of the problem analysis, calculation methods, the adjustContentInset attribute what circumstances will occur tableView content down, which solved method, solve the problem encountered when another small problem.

## First, iOS 11 under APP in tableView content down 20pt or down 64pt reasons analysis

The problem is shown in the following figure:

1. cause analysis

If you use APP in a custom NavigationBar, hidden system NavigationBar, tableView and frame (0,0, SCREENWIDTH, SCREENHEIGHT), then the system will automatically adjust the SafeAreaInsets value (20,0,0,0), if you use the NavigationBar of the system, then the SafeAreaInsets value (64,0,0,0), if also use the system tabbar, then SafeAreaInsets value (64,0,49,0). About what circumstances will occur down the contents of the problem, the third part of this article is introduced.

2. concept of safety zone

The system automatically adjusts the tableView content offset, which is adjusted according to the security zone. The security zone is newly proposed by iOS 11, as shown in the following figure:

The security area helps us to place the view in the visible part of the entire screen. Even if the NavigationBar is set to transparent, the system also considers that the security region starts with the NavigationBar of the bottom and is guaranteed not to be covered by the status bar or navigation bar of the system. You can use additionalSafeAreaInsets to extend the security zone so that it includes custom content on the interface. Each view can change the size of the security area embedded, and so can Controller.

The safeAreaInsets property reflects the margin of an view distance from the security region of the view. For a root view of Controller, the SafeAreaInsets value includes areas that are covered by statusbar and other visual bars, and other custom insets values that are customized through the additionalSafeAreaInsets. Other view in the view hierarchy, and the SafeAreaInsets value reflects the part of the view that is covered. If a view is all in the safe area of its parent view, then the SafeAreaInsets value is (0,0,0,0).

The behavior of adjustedContentInset. / * Configure


AdjustContentInset indicates how much contentView.frame.origin is offset by scrollview.frame.origin; it is calculated by the system, and the calculation is determined by contentInsetAdjustmentBehavior. There are several ways of calculation:

1.UIScrollViewContentInsetAdjustmentAutomaticIf the Scrollview in a automaticallyAdjustsScrollViewContentInset = YES controller, and the Controller is contained in a navigation controller in this case will be set in the top & bottom adjustedContentInset = safeAreaInset + contentInset tube rolling. In other cases, the same as UIScrollViewContentInsetAdjustmentScrollableAxes

2.UIScrollViewContentInsetAdjustmentScrollableAxesIn the rolling direction: adjustedContentInset = safeAreaInset + contentInset, in the rolling direction of adjustedContentInset = contentInset; scrollEnabled dependent and alwaysBounceHorizontal / vertical = YES, scrollEnabled defaults to yes, so in most cases, the calculation way or adjustedContentInset = safeAreaInset + contentInset

## Three, under what circumstances the tableView will have these problems?

If automaticallyAdjustsScrollViewInsets = YES is set, then no problem occurs, and the offset of the content has always been adjusted by the system.

Next, the investigation of their own project, which pages will occur the above problems?.

When the tableView frame exceeds the safety range, the system will automatically adjust the location of the content, the SafeAreaInsets value will be 0, so the effect of tableView value of adjustContentInset, so the effect of the contents of the tableView display, tableView content SafeAreaInsets led down the distance. When the SafeAreaInsets value is 0, it is normal.

You need to know the structure of each page to see if tableView is covered by the system's statusbar or NavigationBar, and if it is covered, it will move down. You can also confirm the content of the content caused by a security zone problem through the value of the tableview.safeAreaInsets.

As follows, you can see that the system has adjusted the distance of the 20pt down to tableView, because tableView is beyond the scope of the security region and is covered by statusbar.

Tableview.contentInset: {Sixty-four,Zero,Sixty,Zero}

Tableview.safeAreaInsets: {Twenty,Zero,Zero,Zero}

Tableview.adjustedContentInset: {Eighty-four,Zero,Sixty,Zero}

## Four, what are the solutions to this problem?

1. reset tableView contentInset, offset SafeAreaInset value, because the content of offset = contentInset + SafeAreaInset;

If set up their own contentInset value (64,0,0,0), now the system and set up a SafeAreaInsets value (64,0,0,0), then tableView content down to 64pt, in this case, you can set the contentInset value (0,0,0,0), which is to comply with the system set up.

2. set the contentInsetAdjustmentBehavior attribute of tableView

If you don't need the system to set the edge distance for you, you can do the following:

 / / if iOS system is 11, there will be such a macro definition "#define __IPHONE_11_0 110000"; if the system version is less than 11 is not the #ifdef __IPHONE_11_0 macro definition
}
#endif

The contentInsetAdjustmentBehavior attribute is also used to replace the automaticallyAdjustsScrollViewInsets attribute, which is recommended.

3. by setting the new attribute iOS 11 addtionalSafeAreaInset;

## Five, encountered another tableView content related to the safe area down

The tableView of my work page has moved down about 40pt. Is it related to the security zone?

Check the next page structure, the parent of tableView view frame under NavigationBar bottom, tableView in the security area of the parent view, print out the tableView SafeAreaInset value is (0, 0, 0, 0); so it is not safe to move down the content area.

After viewing the code, tableView style:UITableViewStyleGrouped type, the default tableView at the beginning and at the end there is a distance, do not need this space, can be achieved by heightForHeaderInSection method (return to a smaller value: 0.1) and viewForHeaderInSection (return a view) to remove the head of the blank, the bottom of the.

The top of the tableView on iOS 11 is blank because the heightForHeaderInSection method is implemented only in the code, and the viewForHeaderInSection method is not implemented. That writing is not standard, only the height is achieved without the implementation of the view, but the code is written before iOS 11 is no problem, and iOS 11 should be caused by bug after opening the estimated height mechanism. When you add the viewForHeaderInSection method, the problem is solved. Or add the following code to close the estimated line height, and the problem is solved.

Self.tableView.estimatedRowHeight =Zero;

Self.tableView.estimatedSectionFooterHeight =Zero;