Designing for all iOS devices

移动互联 2016-06-01

May 12th, 2016

In a world with an increasing differentiation of screen sizes, it’s important to think about adaptivity right from the design process. However, not all designers keep this in mind. If this is the case, design choices for different screen sizes are not visible to the designer and might not be made. In most cases, it’s up to the interpretation of the developer to choose a correct solution, although these decisions should've been made by the designers themselves.

This blog is meant for designers to solve the problem above by describing a layout in layout constraints, instead of just using absolute pixels.

Layout Constraints

When describing a layout using natural language instead of pixel information, you will almost always get an adaptive layout that’s usable for different screen sizes. For example, the Apple Weather app. The interface of this app can easily be described by the following rules:

  • Center the temperature label horizontally in the window;
  • Pin the temperature label’s top, to the top of the window;
  • Pin the temperature label’s bottom, to the center-Y of the window;
  • Pin the weather forecast’s left, right and bottom to the left, right and bottom of the window;
  • Pin the weather forecast’s top to the center-Y of the window.

Each rule in the list above represents a layout constraint.

Constraint Anatomy

In the example of the Weather app, layout constraints let you center and pin elements, but there are more things. To explain what a constraint should describe, let’s take the following constraint:

Pin the temperature label’s bottom, to the center-Y of the window.

And let’s decompose it into functional blocks:

Pin the temperature label’s bottom, to the center-Y of the window.

As you can see, a constraint should contain a subject, the attribute of the subject, a relative object and the attribute of the relative object. There’s one exception to this rule: describing the width or height of a subject. As this kind of constraint does not refer to another object, but just to itself. In addition to relative positioning, an iOS layout constraint can also describe a relationship, offset constant or multiplication:

The temperature label’s center-Y, should be greater than the window’s center-Y times 0.5, plus 20 points.

As this constraint looks a bit complex, this syntax can describe all possible layout properties. A simple centering constraint for example would look like this:

The temperature label’s center-X, should be equal to the window’s center-X times 1, plus 0 points.

A constraint that describes a width or height would only have a subject, attribute, multiplication and a constant.

Constraint Attributes

A constraint can define a relative position from the following attributes of a subject:

  • Left
  • Right
  • Top
  • Bottom
  • Leading (the side where a line starts, could be reversed in some countries)
  • Trailing (the side where a line ends, could be reversed in some countries)
  • Width
  • Height
  • Center-X
  • Center-Y
  • Baseline (the text’s baseline of the last line)
  • First baseline (the text’s baseline of the first line)

On top of these positions, a constraint can also be described relative to a predefined margin from the object. This is possible for left, right, top, bottom, leading, trailing, center-X and center-Y.

Ambiguity

It’s possible to define multiple layout constraints for a single view. This means that it’s possible to define constraints that contradict each other. This is called ambiguity.

Constraint Priority

To explain ambiguity, let’s look at the following constraints:

  • The label’s center-X, should be equal to the window’s center-X;
  • The label’s leading, should be greater than the window’s leading, plus 15 points;
  • The label’s trailing, should be smaller than the window’s trailing, minus 50 points.

By default, each element gets the dimensions of its content, unless there are constraints that define other dimensions. This content size is called the intrinsic content size. This won’t cause any problem as the label is small. However, when the content starts to grow (which might be the case when the app is being localized in a language that uses longer or more words), problems arise. The label begins to grow beyond the 50 points at its trailing. It won’t be possible to either center the label horizontally, or have a trailing space of at least 50 points. The iOS layout system will give a warning and will remove a random constraint from the conflicting constraint. This might cause unexpected layout behaviour. To solve the problem in this case, we can lower the centering constraint priority, so that the label shifts to the left whenever the label becomes bigger.


Content Hugging Priority

Let’s say we have a text compose view with a send button next to a text field. The horizontal constraints would look like this:

  • The textfield’s leading, should be equal to the window’s leading margin;
  • The textfield’s trailing, should be equal to the button’s leading, with an offset of 8 points;
  • The button’s trailing, should be equal to the window’s trailing margin.

There’s a problem with these constraints. How does the layout system know how big the textfield or the button is? As mentioned, the layout system uses the intrinsic content size of elements, but we have two elements with an intrinsic content size next to each other. In this situation, there’s an ambiguity and the system needs to choose between blowing up either the textfield’s width, or the button’s width. To fix this, we can define a content hugging priority on all views. A content hugging priority describes the need for a view to “hug” its edges while blowing up its window.

A content hugging priority describes the need of the view to “hug” its edges while blowing up its window.

In this case, we would give the button a higher content hugging priority than the textfield.

Content Compression Resistance

Let’s say we still have a text compose view as shown in the last paragraph’s example. The view in that example was bigger than both intrinsic content sizes. But what if we have such a small view that the subviews would be compressed instead of blown up? This is what the content compression resistance is about. The content compression resistance describes the need for a view to keep to its intrinsic content size while compressing it.

The content compression resistance describes the need for a view to keep to its intrinsic content size while compressing its window.

Trait Collections

Layout constraints are really powerful in describing the layout, so that it can be laid out for all kinds of screen sizes. It works very well for interfaces that can be blown up or compressed. However, sometimes we have a different kind of design for different kind of devices. The Apple Settings app for example has a sidebar at the left on the iPad, where the iPhone app does not have this. This is possible by conditionally defining layout constraints, based on a collection of device properties. Such a collection is called a “Trait Collection”.

Size Classes

A size class describes whether a screen’s axis is either “Compact” or “Regular”. A few use case examples:

  • The iOS settings app’s left sidebar is based on the horizontal size class. If it’s regular, the sidebar is being displayed.
  • The visibility of the status bar. If the vertical size class is compact, the statusbar is hidden.
  • The navigation bar height. If the vertical size class is compact, the height will be a bit smaller.

Layout constraints that are defined in Xcode’s Interface Builder can be conditionally set based on a screen’s horizontal or vertical size classes. When the size class changes (for example by rotating, or changing the app window size on the iPad), iOS will automatically change the current used layout constraints. This is an overview of the used size classes on different iOS devices:


Other Properties

In code, layout constraints can be based on more variables than just the horizontal and vertical size class:

  • Display scale
  • User interface idiom (iPhone, iPad, TV or CarPlay)
  • Force Touch capability

责编内容by:Awkward (源链)。感谢您的支持!

您可能感兴趣的

Exception by calling another screen in IOS I am new in IOS developing. In Main.storyoard , I added a new viewcontroller , assigned it to a new class("LoginViewController") and provided a...
AES/CBC/128/PKCS5Padding加密解密算法(iOS、Android、JavaScr... 最近项目中考虑到用户账户数据的安全性问题,需要对用户账户相关信息进行加密解密。这里我们选择使用AES加解密,至于AES相比其他对称加密算法的优缺点就不再详述,当然加解密过程中还使用了一些其他的算法,比如混合MD5。这边文章主要记录下Objective-C、Java、JavaScript、PHP四种语...
Luakit的由来 Luakit的历史渊源 最近发布了一个跨平台的app开发框架 Luakit 。那怎么会想到做这样一个东西呢?这要先说一下我参与过的一些项目,和在项目中接触到的一些技术点和对项目开发体检了,因为Luakit是集合了几个重要技术才能做到用Lua脚本来实现跨平台app开发的。...
Trying to save metadata – HealthKit I'm trying to save some data to HealthKit. Sending a UUID with each item. It's a NSUUID converted into a string. hk_acceptsMetadataValue:]: unrecogn...
iOS多线程全面解读(二):GCD 写在前面 本系列文章列表 概述、NSThread GCD NSOperation 锁 GCD(Grand Central Dispatch)是iOS4引...