设计灵活的iPhone应用程序布局是否重要？

我想知道，如果在neb中使用固定值设置视图高度，是否会遇到麻烦

示例：状态栏的高度已知。20个单位。因此，当创建一个显示良好界面的视图时，当用户在使用应用程序时接听电话，并且状态栏高度增加时，会发生什么情况？或者，如果苹果公司在将来某一天改变状态栏或标签栏的高度会怎么样

---

对于包含所有接口元素的容器视图，是否始终使用自动调整大小功能？你的模式是什么？

我总是使用灵活的布局，可以自动调整大小，因为这样可以让我专注于设计，让计算机计算出数学

[编辑]我的理由是有些事情会改变，在这种情况下，我不想再做计算了。可以改变的事情：

• 用户可以选择更大的字体
• 下一代设备的屏幕更大
• 翻译人员讨厌将文字放入像素密集的空间
• 附加组件可能会占用屏幕上的几个像素
• 操作系统的改变可能会改变屏幕大小几个像素
• 当我使用预定义图标时，它们的大小可能会改变
• 最终，在一个灵活的应用程序中，用户可以选择她想看到的内容。我不想让她设计UI

---

所以，如果你让你的布局是静态的，你最终将不得不再做一次。一次又一次。直到您了解到软件开发中唯一不变的是更改。

我将避免在程序中硬编码状态栏、工具栏等的高度值。您提供了一些很好的示例，说明这些值是动态的，并且在将来会发生变化。您可能支持也可能不支持的另一个常见场景是用户能够将iPhone旋转到横向

---

我总是尝试保持容器子视图的布局灵活。使用自动调整大小功能是一个很好的方法。你的问题很好，我想这会让我重新审视自己的布局策略

苹果提供的文件“Constants.h”中不存在这些大小的大部分吗？ （我刚刚注意到它是UICatalog SDK示例的一部分）。

我认为苹果很可能会在某个时候推出另一款屏幕更大或更小的设备。因此，它们应该与[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

好吧，我在这里有点冒险，但我认为硬编码布局尺寸（在今天的iPhone上，以像素为单位）的想法在理论上可能会让你在未来遇到麻烦（或者至少做额外的工作）

我不太关心他们改变状态栏、默认选项卡栏或导航栏的外观大小。。。我担心单位的变化。我不是一个注册的OSX开发者，但长期以来一直有传言说雪豹将支持一种与分辨率无关的接口指定方式，而不是基于像素

明天、3.0版甚至明年都不会出现这种情况，但这种独立于分辨率的界面理念将在iPhone上实现，特别是在未来显示器尺寸（更具体地说，显示器分辨率）发生变化的情况下

---

我有点啰嗦，但我关心的不是状态栏的大小，而是设备的大小，以及我们在Cocoa Touch中用来指定大小的单位。

需要考虑的一件事是：如果用户接到电话，然后在通话过程中启动应用程序，状态栏的高度就会改变。因此，绝对有必要避免在系统UI元素的高度上进行硬编码。

UICatalog示例中有一个“constants.h”，但它是该示例的局部示例，显然只是示例开发人员简化其生活的一种方式。它带有上面提到的所有问题。。。如果将来“标准尺寸”发生任何变化，此示例将停止正常工作

---

要查询其他对象以获得正确的位置很糟糕，但这是在环境发生变化时确保事情正常工作的方式。扩展的“通话中”状态栏就是一个完美的例子。如果您硬编码20个“单位”以避开状态栏，则您的应用程序在通话中会中断。而且，在模拟器中你可能不会注意到这一点（因为，如果你在模拟器中充分考虑到这个选项，你可能会在编写应用程序时考虑到它！）

我去查看了，因为我认为这将是一个有趣的文件，我在OSXSDK或iPhone SDK中都找不到任何对UIConstants.h文件的引用。是我遗漏了什么，还是这个文件的名称不同？iPhone已经有了一个独立于分辨率的界面。您不指定像素。您可以指定单位。就iPhone而言，目前一个单位是一个像素。但这在将来可能会改变。好吧，我会的。你说得对。因为对于当前的屏幕形状因子1单位=1像素，我从来没有考虑过。当设备的大小或分辨率发生变化时，这将被证明是非常重要的。是的，当他们改变显示大小，或者更重要的是改变纵横比时，一些应用程序将遇到麻烦。但由于目前只有一个屏幕大小，我不太担心。如果他们真的推出了iphonenano，那么我将不得不做一些变通；）但这就是为什么我选择iPhone操作系统而不是谷歌安卓系统，在谷歌安卓系统中，你有数百万的屏幕大小和纵横比。谢谢！我想知道当状态栏或选项卡栏变大或变小时如何测试这些事件。只需在模拟器中运行应用程序，然后进入调用状态栏中的硬件->切换。状态栏将增长。选择相同的菜单选项