Geek Answers Handbook

Is it important to flexibly develop iPhone App layouts?

I am wondering if I run into problems when adjusting the heights of my views in neb with fixed values.

Example: The height of the status bar is known. This is 20 units. Therefore, when you present a good interface, what happens when a user uses a phone call while using the application, and the status bar increases in height? Or what if Apple changes the height of the status bar or tab bar in the future?

Do you always use auto-resolution features for your container view, which has all the interface elements inside? What is your model?

+4
source share
6 answers

I would avoid hard coding values ​​for status bar heights, toolbars, etc. in your program. You present some good examples of how these values ​​are dynamic and may change in the future. Another common scenario that you may or may not support is the ability of the user to rotate the iPhone in landscape orientation.

I always try to save the layout of containers as containers. Using autosave is a good approach. Your question is good, and I think it will force me to reconsider my own layout strategy!

+7
source

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

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

  • Users can choose larger fonts
  • The next generation of the device gets a larger screen
  • Translators hate this when they have to embed words in a space bounded by pixels.
  • An add-in can take up a few pixels on the screen.
  • Changing the OS can change the screen size by a few pixels.
  • When I use predefined icons, their size may change
  • Ultimately, in a flexible application, the user can choose what she wants to see. I don’t want her to have an interface layout.

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

+4
source

Well, I'm going to the limbs here, but I think that the idea of ​​hard-coding layout sizes (which is currently in pixels on the iPhone) could theoretically cause you problems (or at least do extra work) in the future.

I'm not really worried that they change the visible size of the status bar, the default tab bar or the navigation bar ... I am worried about changing units. I am not a registered OS X developer, but it has long been known that Snow Leopard will support a resolution-independent way of specifying interfaces, rather than pixel-based.

This will not happen tomorrow or in version 3.0, or maybe even next year, but this idea of ​​a resolution-independent interface is going to turn it into an iPhone, especially if the screen size (and, more specifically, display resolution) changes in the future.

I'm very tired, but this is not the size of the status bar that bothers me with in the future, it's the size of the device and the units we use to indicate the sizes in Cocoa Touch.

+3
source

What to think about: if the user receives a phone call and then launches the application during a telephone conversation, the height of the status bar will change. Therefore, it is definitely necessary to avoid hard coding in the height of system user interface elements.

+1
source

Theres "constants.h" in the UICatalog sample, but it is local to this sample and, obviously, is just a way for the developer sample to make its life easier. It carries all the problems mentioned above ... if something changes the "standard sizes" in the future, this sample will stop working normally.

It turns out that you need to request other objects in order to correctly place your placement, but this is how you ensure the correct functioning when the environment changes. A great example is the expanding status bar "on call". If you program 20 "units" hard to avoid the appearance of a status bar, your application breaks during a conversation. And something that you are unlikely to notice in the simulator (because if you thought enough about it to try this option in the simulator, you would probably think about it when coding the application!)

+1
source

Isn't most of these sizes present in the Apple file supplied by "Constants.h"? (I just noticed that this is part of the UICatalog SDK example).

I think it is very likely that Apple will launch another device that will have a larger or smaller screen. Therefore, 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

0
source

More articles:


All Articles