Adapting to the iPhone X is easy but tedious, as a change in the height of the navigation bar affects almost all pages. If the project is using automatic layout, it should adapt quickly, but unfortunately I did not use automatic layout for this project 😭. (13 years old, there seems to be no such thing as automatic layout 😳, I did not fully use automatic layout after the reconstruction…)

The iPhone X paid off all the stolen laziness.

The reason why we feel cumbersome is that the interface is written.

For example, the navigation bar, the navigation bar in the project is a custom view, initialization basically looks like this:

self.naviView = [[CQShopCartNaviView alloc] 
    initWithFrame:CGRectMake(0, 0, screenWidth, 64)];
Copy the code

Don’t use auto layout and write height to death…

Similarly, there is tabBar, which is 49 in height, but there is only one tabBar in the project, so the changes are quick.

Adapting to the iPhone X basically means changing the height of the controls…

One thing I learned from adapting to the iPhone X:

1. Be sure to use automatic layout wisely

The characteristic of automatic layout is that it is alive and can change according to structural changes.

Compared with absolute frame layout, the advantages of automatic layout are obvious, not only this adaptation for iPhone X, but also I have experienced that the height of the status bar changed when the adaptation hotspot was connected. If the automatic layout is used, there is no need to adapt, because it is dynamic. If the absolute layout is used, You receive notifications that the height of the status bar has changed, and then adjust it page by page…

In addition, my experience of iterative development over a year is that automatic layout is better able to cope with changing requirements.

2. Universal global constants must be defined in macros

So you can change it in one place, all of it. In plain English, don’t write the height of the navigation bar. For example, write the height of the navigation bar.

Macros for the iPhone X include:

/ / judge whether iPhone X # define iPhoneX ([UIScreen instancesRespondToSelector: @ the selector (currentMode)]? CGSizeEqualToSize(CGSizeMake(1125, 2436), [[UIScreen mainScreen] currentMode].size) : #define STATUS_BAR_HEIGHT (iPhoneX? F: 20.f) #define NAVIGATION_BAR_HEIGHT (iPhoneX? 88.f: 64.f) // tabBar height #define TAB_BAR_HEIGHT (iPhoneX? (49.f+34.f) : 49.f) // home indicator #define HOME_INDICATOR_HEIGHT (iPhoneX ? 34.f : 0.f)Copy the code

3. The top control leans down, and the bottom control leans up

  • For example, custom navigation:






Controls in the navigation bar should base their constraints on the bottom.

  • Another example is custom tabBar:






Constraints on controls in tabbar should be benchmarked at the top.

This setting constraint does not matter how high the navigation bar or tabbar changes in the future.

In the actual project, the top is not necessarily the navigation bar, the bottom is not necessarily the tabbar, no matter what view, as long as we set the constraint is towards the middle, no matter how the height of the control changes in the future will not cause layout disorder.

conclusion

  1. Programming, must be flexible, to think about the long-term point, I was taken for granted that the status bar, navigation bar and tabbar control height is certainly not changed, so directly write dead, resulting in now have to modify one by one.
  2. It’s important to keep up with the trend. I wouldn’t have to go to so much trouble now if I had used automatic layout all the time when REfactoring.