Важно ли создавать гибкие макеты приложений для iPhone?

Question

Мне интересно, не возникнут ли у меня проблемы при настройке высоты моих просмотров в окне с фиксированными значениями.

Пример: высота строки состояния известна. Это 20 единиц. Итак, при создании представления с хорошим интерфейсом, что произойдет, если пользователь во время использования приложения сделает телефонный звонок, а строка состояния увеличится в высоте? Или что, если Apple когда-нибудь в будущем изменит высоту строки состояния или панели вкладок?

Всегда ли вы используете функции автоматического изменения размера для вашего контейнера, в котором есть все элементы интерфейса внутри? Какой у тебя рисунок?

Answer 1

Я бы держался подальше от жестких значений кодирования для высоты строки состояния, панели инструментов и т. Д. В вашей программе. Вы привели несколько хороших примеров того, как эти значения являются динамическими и могут измениться в будущем. Еще один распространенный сценарий, который вы можете поддерживать или не поддерживать, - это возможность пользователя поворачивать iPhone в альбомную ориентацию.

Я всегда пытаюсь сохранить гибкость макета подпредставлений контейнера. Использование функции автоматического изменения размера является хорошим подходом. Ваш вопрос хороший, и я думаю, он заставит меня пересмотреть мою собственную стратегию верстки!

Answer 2

Я всегда использую гибкий макет, который автоматически изменяет размеры, потому что позволяет мне сосредоточиться на дизайне и позволить компьютеру вычислить математику.

[ПРАВИТЬ] Моя причина в том, что что-то изменится, и я не хочу делать математику снова в этом случае. Вещи, которые могут измениться:

• Пользователи могут выбрать более крупные шрифты
• Следующее поколение устройства получит увеличенный экран
• Переводчики ненавидят это, когда им приходится помещать слова в пиксельные пространства
• Надстройка может занимать несколько пикселей на экране
• Изменение ОС может изменить размер экрана на несколько пикселей
• Когда я использую предопределенные значки, их размер может измениться
• В конечном счете, в гибком приложении пользователь может выбрать то, что он хочет видеть. Я не хочу, чтобы она разрабатывала пользовательский интерфейс.

Так что если вы сделаете ваш макет статичным, вам в конечном итоге придется сделать это снова. И опять. Пока вы не узнаете, что единственной константой в разработке программного обеспечения является изменение.

Answer 3

Ну, я выхожу на передний план, но я думаю, что идея жестких размеров компоновки кода (которые сегодня на iPhone представлены в пикселях) теоретически может вызвать у вас проблемы (или, по крайней мере, дополнительная работа) в будущем.

Меня не очень беспокоит то, как они меняют видимый размер строки состояния, или панели вкладок по умолчанию, или панели навигации ... Меня беспокоит изменение единиц измерения. Я не зарегистрированный разработчик OS X, но давно ходят слухи, что Snow Leopard будет поддерживать независимый от разрешения способ указания интерфейсов, не основанный на пикселях.

Это произойдет не завтра, не в 3.0, а, может быть, даже в следующем году, но эта идея интерфейса, не зависящего от разрешения, превратится в iPhone, особенно когда размер дисплея (а точнее, разрешение дисплея) изменится. в будущем.

Меня долго волнует, но это не размер строки состояния, которую я собираюсь изменить в будущем, это размер устройства и единицы измерения, которые мы используем для указания размеров в Cocoa Touch.

Answer 4

В образце UICatalog есть "constants.h", но он является локальным по отношению к этому образцу и, несомненно, является просто способом, позволяющим разработчику образца упростить свою жизнь. Он несет в себе все проблемы, упомянутые выше ... если что-то изменит «стандартные размеры» в будущем, этот образец перестанет работать правильно.

Отстойно, когда приходится запрашивать другие объекты, чтобы получить правильное размещение, но именно так вы гарантируете, что все работает правильно, когда меняется среда. Расширяющаяся строка состояния «in-call» - прекрасный пример. Если вы жестко закодировали 20 «единиц», чтобы избежать строки состояния, ваше приложение разрывается во время разговора. И это то, что вы вряд ли заметите в симуляторе (потому что, если вы подумали об этом достаточно, чтобы попробовать этот вариант в симуляторе, вы, вероятно, подумали бы об этом при кодировании приложения!)

Answer 5

Стоит задуматься: если пользователь получает телефонный звонок, а затем запускает приложение во время телефонного звонка, высота строки состояния изменится. Поэтому, безусловно, необходимо избегать жесткого кодирования в высоту системных элементов пользовательского интерфейса.

Answer 6

Разве большинство этих размеров не присутствует в файле Apple Constants.h? (Я только что заметил, что это часть примера UICatalog SDK).

Я думаю, что очень вероятно, что Apple когда-нибудь запустит другое устройство с большим или меньшим экраном. Поэтому их следует использовать вместе с [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