A summary of iOS layouts and screen adaptations

Once, iOS development does not need to consider screen adaptation issues, because there is only one screen size. And now there are 4 screens, 4,5,6,6p, so screen adaptation has become an issue that must be considered in iOS development. Also, the width-to-height ratio of these 4 screens is all different, so simply scaling does not solve the problem. One of the apps we've been working on is also dealing with screen adaptations, and this article simply summarizes

Judging by Screen type

I don't know if there's a better way, we're doing it based on the device type, writing some if...else, or switch statements

Judging the model can use screen height (cannot use width, because the width of 4 and 5 is the same, is 320), you can also use the API macros, are similar. I personally feel that If...else seems inevitable, although there is auto layout, but there are some large layout changes, or font size, no judgment seems to be impossible to solve

For example, in order to achieve the best display, we use CollectionView on the large screen, and use TableView on the 4S, there should be no way to do it with automatic layout. or depending on the size of the screen, switch font size, as if it can only be achieved by if...else

Depending on the screen type, the code is similar:

if (Screentype = = losscreentype6p) {    layout.minimuminteritemspacing = 30;} else if (Screentype = = LosScreenType5) {    layout.minimuminteritemspacing = 5;} else{    layout.minimuminteritemspacing = 15;}

Frame calculation

We also used a lot of "hard calculations", such as the width of each cell in Uicollectionview, which we handled:

CGRect rect = [[UIScreen mainscreen] bounds];screenwidth = Rect.size.width;cellwidth = (screenWidth-30)/3;cellheight = Cellwidth * 0.8 + 50;

-(Cgsize) CollectionView: (Uicollectionview *) CollectionView layout: (uicollectionviewlayout *) collectionviewlayout Sizeforitematindexpath: (Nsindexpath *) indexpath{    return Cgsizemake (Cellwidth, cellheight);}

We stipulate that there are 3 cells in each row in the CollectionView, the left and right spacing of the whole section is 10, the column spacing is 5, so the calculated (WIDTH-30)/3 is the width of each cell, and the height of the cell is calculated and written dead.

I'm not sure this is a good way, but it works for this page. Similar to this method based on screen size, the app can be used on several pages

Masonry

Masonry is one of the most important means to realize screen adaptation, which is essentially the grammatical sugar of interface constraint. Basically, our practice is: Large page relationship, with the calculation, the relative position of each small piece inside the relationship, with masonry to do. In some scenarios, masonry has a great advantage. For example:

1. Set the aspect ratio of a view

[Thumbimageview mas_makeconstraints:^ (Masconstraintmaker *make) {    make.top.equalTo (@0);    Make.left.equalTo (@0);    Make.width.equalTo (self);    Make.height.equalTo (thumbimageview.mas_width). Multipliedby (0.8);}];

The width of this view is the same as the parent view, and the height is 0.8 of the width

2, set the center, set the relative margin

[AuthorName mas_makeconstraints:^ (Masconstraintmaker *make) {    make.centerY.equalTo (avatarimageview);    Make.left.equalTo (avatarimageview.mas_right). Offset (5);    Make.right.equalTo (@-5);}];

Align vertically with another view, left 5 to the right of the previous element, right 5 to the right of the parent view

Like this layout, it can be a lot more complicated to write with a frame, and if you think about screen fitting, you need a lot of code. This kind of demand, masonry is called artifact. However, using the masonry layout view, we will usually init, or Initwithframe:cgrectzero. This view is not determined by the origin and size of the masonry until it has been processed, and if it is preceded by its origin and size, there will be a problem

Overall replacement UIView

For a small change in the adaptation of the page, the If...else written in the UIView, but there are individual pages, completely according to the device display different view. This situation is more appropriate for the controller to make a judgment, and then load different view

A summary of iOS layouts and screen adaptations