Is it important to design iPhone App layouts flexible?

Question

I am wondering if I would run into troubles when setting the heights of my views in the neb with fixed values.

Example: The height of the Status Bar is known. It's 20 units. So when making a view that shows an nice interface, what would happen when the user takes a phone call while using the App, and the Status Bar increases in height? Or what if Apple changes the height of the Status Bar, or Tab Bar, some day in future?

Do you always use autoresizing features for your container-view that has all the interface elements inside? What's your pattern?

Answer 1

I always use a flexible layout that resizes automatically because that allows me to focus on the design and let the computer figure out the math.

[EDIT] My reason is that something is going to change and I don't want to do the math again in this case. Things that can change:

• Users might select bigger fonts
• The next generation of the device gets a bigger screen
• Translators hate it when they have to fit words into pixel-tight spaces
• An add-on might take up a few pixels on the screen
• A change in the OS might change the screen size by a few pixels
• When I'm using predefined icons, their size might change
• Ultimately, in a flexible application, the user can choose what she wants to see. I don't want her to have to layout the UI.

So if you make your layout static, you'll eventually have to do it again. And again. Until you learn that the only constant in software development is change.

Answer 2

I would steer clear of hard coding values for the heights of the status bar, tool bar, etc into your program. You present some good examples of how these values are dynamic and can change in the future. One other common scenario that you may or may not be supporting is the ability of the user to rotate the iPhone into landscape orientation.

I always try to keep the layout of the subviews of a container flexible. Using the autoresizing feature is a good approach. Your question is a good one and I think its going to make me review my own layout strategy!

Answer 3

Aren't most of these size present in the Apple supplied file "Constants.h"? (I've just noticed that it is part of the UICatalog SDK example).

I think it is very likely that Apple will launch another device sometime which has a larger or smaller screen. So they should be used in conjunction with [UIScreen frame/bounds];

// these are the various screen placement constants used across all the UIViewControllers

// padding for margins
#define kLeftMargin             20.0
#define kTopMargin              20.0
#define kRightMargin            20.0
#define kBottomMargin           20.0
#define kTweenMargin            10.0

// control dimensions
#define kStdButtonWidth        106.0
#define kStdButtonHeight        40.0
#define kSegmentedControlHeight 40.0
#define kPageControlHeight      20.0
#define kPageControlWidth      160.0
#define kSliderHeight            7.0
#define kSwitchButtonWidth      94.0
#define kSwitchButtonHeight     27.0
#define kTextFieldHeight        30.0
#define kSearchBarHeight        40.0
#define kLabelHeight            20.0
#define kProgressIndicatorSize  40.0
#define kToolbarHeight          40.0
#define kUIProgressBarWidth    160.0
#define kUIProgressBarHeight    24.0

// specific font metrics used in our text fields and text views
#define kFontName               @"Arial"
#define kTextFieldFontSize      18.0
#define kTextViewFontSize       18.0

// UITableView row heights
#define kUIRowHeight            50.0
#define kUIRowLabelHeight       22.0

// table view cell content offsets

#define kCellLeftOffset          8.0
#define kCellTopOffset          12.0

Tony

Answer 4

Well, I'm going out on a limb here, but I think that the idea of hard coding layout dimensions (which, today, on the iPhone, are in pixels) could theoretically get you in trouble (or at least make extra work) in the future.

I'm not so much concerned about them changing the apparent size of the status bar, or the default tab bar, or the navigation bar... I'm worried about the units changing. I'm not a registered OS X developer, but it has long been rumored that Snow Leopard is going to support a resolution independent way of specifying interfaces, not based on pixels.

It won't happen tomorrow, or in 3.0, or maybe even next year, but this idea of a resolution independent interface is going to make it to the iPhone, especially as display size (and more specifically, display resolution) change in the future.

I'm being long winded, but it's not the size of the status bar I'm concerned with changing in the future, it's the size of the device, and the units we use to specify sizes in Cocoa Touch.

Answer 5

One thing to think about: if the user gets a phone call and then launches the application during the phone call, the status bar's height will change. So it's definitely a necessity to avoid hard-coding in the height of system UI elements.

Answer 6

Theres a "constants.h" in the UICatalog sample, but it's local to that sample and is clearly just a way for the sample developer to make his/her life easier. It carries with it all the problems mentioned above ... if anything changes the "standard sizes" in the future, this sample stops working properly.

It sucks to have to query other objects to get your placement right, but it's how you ensure things work properly when the environment changes. The expanding "in-call" status bar is a perfect example. If you hard-code 20 "units" to avoid the status bar, your app breaks while in a call. And, that's something you're not likely to notice in the simulator (because, if you thought about it enough to try that option in the simulator, you probably would have thought about it while coding the app!)