Devices running iOS now come in a pretty wide variety of flavors–there are five different screen resolutions available across four different screen sizes. Together, these differences account for the three different aspect ratios iOS developers have to take into account when creating an iOS app.
The different aspect ratios generally don’t affect the core functionality of an app, but it does directly affect how the user experiences the functionality through the interface. With only three different aspect ratios, trying to handle the differences on your own requires a pile of hard-to-maintain conditional statements. Even the smallest of changes will become a time-consuming task.
Apple gives iOS developers a number of different tools to efficiently handle the various screen sizes and screen resolutions without writing a lot of extra code. Less code always translates to fewer bugs and time saved.
Let’s focus on one tool iOS developers have for efficiently designing layouts for multiple screens: autoresizing behaviors. The autoresizing behaviors have been around since iOS 2.0 but can be tricky to master and it’s not always apparent how valuable they are.
Superviews and Subviews
When you think of the hierarchy of views in your application, each visible view always has a parent view or “superview.” Each interface element (for example, a UIButton) is placed inside of a UIView, which may be placed within another UIView, which ultimately is inside a UIWindow. UIWindow is the only interface item that does not have a superview as it should be your topmost view.
When a view changes size, by default it will attempt to resize its subviews (and those subviews will in turn attempt to resize their subviews and so on). A view may change size for a number of reasons–the device may have changed its orientation, the status bar or navigation bar may have just disappeared, or perhaps it was due to a custom animation. It also may change size due to the form factor of the device. In a universal application, you may design a view for the phone form factor with a width of 320px, but on the iPad, this view may display with a width of 768px or 1024px.
You can tune the behavior of the resizing action by setting the autoresizing properties of each interface element. This can be done in code by setting the value of the
autoresizingMask property, but I find it far easier to manage these properties in Interface Builder as it is more visual.
Let’s look at the Size Inspector in Interface Builder (View>Utilities>Show Size Inspector) to get our bearings with View Autoresizing
Within the autoresizing options, you have six different toggle controls that control the autoresizing behavior. There are two groups of autoresizing options–the margin controls and the size controls. For both sets of controls, a dotted line indicates that the control is disabled while a solid line indicates that it is enabled.
The controls around the outside modify the resizing behavior of the margins. “Margin” refers to the space around the top, left, right, and bottom of the selected view.
When any of these controls are enabled, it indicates to the OS that when the superview changes size, the selected view should reposition so that the view maintains a consistent margin from the edge of the superview. For example, if you place a label 10 pixels down from the top of the superview and you want the label to always be 10 pixels down from the top regardless of the orientation or form factor of the device, you would enable the top margin autoresizing control.
When the control is disabled, it indicates to the OS that when the superview changes size, the selected view should move by the same ratio of the change in size. Let’s take the same label as before–still, 10px down from the top of the superview, but this time, the top margin control is disabled. The superview changes height from 400px to 480px, a 20-percent increase in height. The top margin will also increase by 20 percent from 10px to 12px.
What happens if you enable all the margin controls but leave the height and width controls disabled? You’ve created a mutually exclusive scenario–the system cannot both satisfy positioning a view 10 pixels from the left edge and at the same time 10 pixels from the right. The system gives precedence to the top and left. So in this scenario, it will honor the top and left setting, maintaining a consistent top and left a margin, but ignore the right and bottom setting.
The two controls in the middle control the autoresizing behavior of the height and width of the selected view.
When one of these controls is enabled and the superview changes size, the selected view will also change size by the same ratio. A 20-percent increase in width of the superview will translate to a 20-percent increase of width in the selected view. When disabled and the superview changes size, the selected view will not change size.
By way of application, let’s say you wanted a button to change its width with the superview so that it always has a 10px left and right margin. To achieve this, you would set the initial position of the button in Interface Builder ensuring that there are 10 pixels both to the left and right of the button. Then, you would enable the width autoresizing control as well as the left and right margin controls. This indicates to the OS that you want the left and right margins to remain consistent and you’re willing for the width of the view to change in order to make that happen.
Using Autoresizing to Design for Multiple Screens
Table view cells are a great place to see the value in view autoresizing and how it helps you create a design that works at a variety of sizes without having to write a single line of code. Table view cells frequently have to change height based on their content, but may also have elements that need to reposition when the cell changes size. Moreover, the cell may also need to resize based on the form factor of the device (phone or tablet) and the orientation of the device (portrait or landscape).
Let’s take a look at Float’s enterprise social network for learning, Tappestry. One of the primary views in the app is the stream view where you can see posts (threads) created by yourself and other users. Each thread in the stream is a cell in a table view.
The thread cell has metadata about the thread at both the top and the bottom of the cell. The views at the top of the cell, the topic name, avatar, and name, all have the top and left margin controls enabled in the autoresizing options because we always want them to be the same distance from the top left of the cell. The topic name and username labels also have the width and right margin autoresizing control enabled because when the cell is displayed on the iPad, we want the length of the labels to extend the full width of the cell just as they do on the iPhone. The avatar’s size should remain the same regardless of the size of the cell so it has the height and width autoresizing controls disabled.
The views at the bottom of the cell have to change position based on how tall the cell is. The height of the cell is dependent on a number of factors–not only the amount of content in the thread but also on the width of the cell. The wider the cell, the less height it needs since more text will be able to fit on one line. Without writing a line of code, we’re able to specify that the label containing the time the thread was posted should remain at the bottom of the superview (which is the cell). In this case, we have enabled the left and bottom margin controls. We have also enabled the width and right margin controls since we want the label to extend the full width of the cell.
You can preview your autoresizing settings within Interface Builder by enabling Live Autoresizing (Editor>Canvas>Live Autoresizing). Now when you resize a view in Interface Builder by dragging out one of the edges, Interface Builder will adhere to your autoresizing settings and resize the view’s subviews.
By mastering the auto-resizing options, you can create interface designs that maintain consistent layouts regardless of the size of the screen they’re displayed on. Mastering these tools will go a long way in efficiently supporting the various screen resolutions of iOS devices, but it’s also important to remember that there’s more than designing for size.
Is a requirement for your next mobile learning project that it must be visible on many devices? Contact us today for more information!
Latest posts by Daniel Pfeiffer (see all)
- A More Mobile-Friendly Captivate HTML Template - October 21, 2013
- 3 Tools To Help You Optimize Your PhoneGap App’s Performance - October 15, 2013
- Tin Can iOS Library Compatible With Version 1.0 - May 2, 2013