О какао автоматическое расположение

OS X Lion представляет новую систему расположения для Какао, заменяя историческую модель пружин и распорок. Вместо того, чтобы использовать маски автокалибровки, Вы определяете ограничения макета, выражающие Ваше намерение, такое как “эти представления выстраивают в линию голову к хвосту”, или “эта кнопка должна переместиться с этим подпредставлением представления разделения”.

Иллюстрация, 1-1Laying метка

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

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

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

Существуют также более тонкие преимущества:

• Новая архитектура улучшает подразделение ответственности между контроллерами и представлениями.

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

• Для расположения, определенного в Интерфейсном Разработчике, обычно существует меньше необходимых шагов.

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

• Для контроллеров, размечающих представления:

  • Исходный код более читаем посредством использования ВДОХНОВЛЕННОЙ ASCII-ТВОРЧЕСТВОМ строки формата для указания расположения. Исходный код буквально похож на конечный продукт.

  • Существует меньше работы, чтобы сделать. Листовые представления, такие как кнопки, всегда размер сами для адаптации их содержанию, если что-то не предотвращает его.

  • Вы более непосредственно явно выраженный, что Вы хотите. Вы обеспечиваете ограничения, чтобы указать, что “базовые линии этих двух представлений выстраиваются в линию”, и платформа делает необходимые вычисления.

• Для представлений проще изменить метрики и визуальное проектирование, не обновляя клиенты:

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

  • Клиенты не делают hardcode вещей, таких как базовые линии или сумма тени под кнопкой.

Ограничительные явно выраженные отношения между представлениями

Единственный новый класс NSLayoutConstraint, экземпляры которого представляют ограничения. Ограничение является оператором формы

y = m*x + b

• y и x атрибуты представлений.

  Атрибут является одним из left, right, top, bottom, leading, trailing, width, height, centerX, centerY, и baseline.

  Атрибуты leading и trailing совпадают с left и right на английском, но UI зеркально отражает в справа налево среда как иврит или арабский язык. При использовании Интерфейсного Разработчика или визуальных строк формата (см., Создают Ограничения Программно Используя Визуальный Язык Формата), leading и trailing значения по умолчанию.

• Отношение в ограничении не должно быть ==; это может также быть <= или >=.

Следующее представляет конкретный пример ограничения (несмотря на то, что оно представлено как псевдокод):

button1.right == button2.left - 12.0

Ограничение также имеет дополнительный приоритетный уровень с плавающей точкой. Ограничения с более высокими приоритетными уровнями удовлетворены перед ограничениями с более низкими приоритетными уровнями. Приоритетный уровень по умолчанию NSLayoutPriorityRequired, что означает, что ограничение должно быть удовлетворено точно. Система расположения стремится встретить дополнительное ограничение, даже если она не может полностью достигнуть его. Если ограничение a == b является дополнительным, это означает это abs(a - b) должен быть минимизирован.

Приоритетные уровни позволяют Вам выражать полезное условное поведение. Например, они используются для выражения, что все средства управления должны всегда измеряться для адаптации их содержанию, если что-то более важное не предотвращает его. Для большего количества подробности об этом примере посмотрите Делящуюся Ответственность Между Контроллерами и Представлениями.

Ограничения, с некоторыми ограничениями, могут пересечь иерархию представления. В Почте, например, по умолчанию кнопка Delete на панели инструментов выстраивается в линию с таблицей сообщений, и в Настольных Предпочтениях, флажки у основания окна выравниваются с областью просмотра разделения, на которую они воздействуют.

Ограничение не может пересечься посредством представления, вручную размечающегося, или посредством представления, имеющего, границы преобразовывают. Можно думать об этих представлениях как о барьерах. Существует внутренний мир и внешний мир, но внутренняя часть не может быть подключена к внешней стороне ограничениями.

Ограничение является обычно неизменным после создания его но можно все еще изменить константу. Существует две причины этого:

• Это алгоритмически важно. Намного более эффективно изменить константу, чем удалить ограничение и добавить новое.

• Это приводит к естественному способу реализовать операции, такие как перетаскивание, где производительность является самой важной.

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

Создайте ограничения программно Используя визуальный язык формата

Исходный код традиционно не передает визуальное представление хорошо

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

if (_accessoryView) {

minYMessageAndAccessories -= [_accessoryView frame].size.height;

if ([self showsSuppressionButton]) {

// we’ve already accounted for the spacing above the suppression button and below the accessory view. Add spacing between.

minYMessageAndAccessories -= ACCESSORY_INTERY_SPACING;

// adjust y-origin of suppression button since there is also an accessory view

NSPoint buttonOrigin = [_suppressionButton frame].origin;

buttonOrigin.y += [_accessoryView frame].size.height + ACCESSORY_INTERY_SPACING;

[_suppressionButton setFrameOrigin:buttonOrigin];

} else {

// we need spacing above and below accessory view

minYMessageAndAccessories -= ACCESSORY_MINY_SPACING + ACCESSORY_MAXY_SPACING;

}

}

if (_imageView != nil) {

if (minYMessageAndAccessories < NSMinY([_imageView frame])) {

panelHeight += NSMinY([_imageView frame]) - minYMessageAndAccessories;

}

}

Возможно невозможно понять сразу, что делает этот код. Также трудно поддержать — изменение поведения расположения будет хитро и подвержено ошибкам. На практике эта ситуация менее распространена, чем мог бы иметь место, потому что вместо того, чтобы писать такой код, Вы используете Интерфейсного Разработчика:

Это - основной элемент подхода к удобству пользования: необходимо быть в состоянии визуализировать расположение. Самый большой компонент для этого является Интерфейсным Разработчиком. Однако также желательно визуализировать расположение в коде также. Рассмотрите расположение этих кнопок:

Левая сторона button2 стандартное пространство Воды далеко от правой стороны button1. Для простоты иллюстрации, замена “стандартный интервал Воды” с простой константой, 12. Используя основной метод для ограничительного создания, Вы могли бы создать ограничение как это:

[NSLayoutConstraint constraintWithItem:button1

attribute:NSLayoutAttributeRight

relatedBy:NSLayoutRelationEqual

toItem:button2

attribute:NSLayoutAttributeLeft

multiplier:1.0

constant:-12.0];

Код все еще не очень визуален. Трудно быстро определить, например, который является левыми и который является правильной кнопкой. В записи кода это просто в использовании положительная константа вместо отрицательной, или указать неправильный атрибут.

[button1]-12-[button2]

[button1]-[button2]

NSDictionary *views = NSDictionaryOfVariableBindings(button1, button2);

NSArray *constraints = [NSLayoutConstraint constraintsWithVisualFormat:@"[button1]-[button2]"

                                           options:0

                                           metrics:nil

                                           views:views];

Expected ':' after 'V' to specify vertical arrangement

V|[backgroundBox]|

 ^

A predicate on a view's thickness must end with ')' and the view must end with ']'

|[whiteBox1][blackBox4(blackWidth][redBox]|

                                 ^

Unable to find view with name blackBox

|[whiteBox2][blackBox]

                     ^

Unknown relation. Must be ==, >=, or <=

V:|[blackBox4(>30)]|

               ^

Добавьте ограничения к представлениям

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

Предположим, что Вы устанавливаете [zoomableView1]-80-[zoomableView2] на общем предке zoomableView1 и zoomableView2.

Эти 80 находятся в системе координат контейнера, который является тем, на что это похоже, визуализируете ли Вы ограничение.

Если границы преобразовывают любого из zoomable изменений представлений, пространство между ними остается фиксированным.

Если границы преобразовывают в сам контейнер, изменяется, то пространство масштабируется, также.

NSView обеспечивает метод —addConstraint:— добавить ограничение и методы, чтобы удалить или проверить существующие ограничения —removeConstraint: и constraints— а также другие связанные методы. NSView также обеспечивает метод, fittingSize, который подобен sizeToFit метод NSControl но для произвольных представлений, а не для средств управления.

fittingSize метод возвращает идеальный размер для представления, считая только те ограничения установленными на поддереве получателя вместе с предпочтением представления, чтобы быть как можно меньше. Подходящий размер не является «лучшим» размером для представления в общем смысле — в системе на основе ограничений, «лучший» размер представления, если Вы полагаете, что все должно быть размером, который это в настоящее время имеет!

Базовое время выполнения расположения

В дополнение к Какао передачи «дисплея» всегда использовал, Какао, Автоматическое Расположение добавляет еще две передачи, происходящие при рендеринге окна: updateConstraintsIfNeeded и layoutIfNeeded. Они происходят в порядке: ограничения Обновления, разметьте, дисплей. Если Вы вызываете display вручную, это вызывает layout и layout вызывает updateConstraints.

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

Именно в передаче расположения кадры представлений обновляются. Передача расположения является нисходящей.

Эти передачи имеют параллельные наборы методов:

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

• Можно переопределить updateConstraints выполнять задержанную ограничительную установку. Вы вызываете setNeedsUpdateConstraints: когда Вы установили Вас, хотят задержать. Это особенно полезно, когда файл пера загружается, и свойства изменяются много — Вы не получите updateConstraints пока не успокоились вещи.

• Необходимо переопределить layout только если Вы хотите сделать пользовательский макет. Если Вы делаете, то также необходимо вызвать setNeedsLayout: когда что-то, что питается в Ваши изменения пользовательского макета.

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

Объект контроллера обычно более касается в NSWindow и NSView методы, выполняющие передачу. Это использование более редко, хотя все еще допустимый и необходимый при случае.

• Выполните ограничительную передачу обновления вручную, чтобы удостовериться, что все ограничения актуальны.

  Вы могли бы сделать это прежде, чем анализировать ограничение для извлечения метрики.

• Выполните передачу расположения вручную, если Вы хотите извлечь кадры из представлений и принять решения на основе их. Если Вы сначала не удостоверитесь, что расположение актуально, то кадры не будут значимы.

  NSAlert возразите использует это в качестве части его расположения. Система на основе ограничений не имеет дело с текшим текстом и строкой, повреждающейся немного лучше (или хуже), чем пружины и распорки делают. NSAlert устанавливает все его ограничения за исключением чего-либо дающего высоту текстовых полей. Тогда это вызывает layoutSubtreeIfNeeded. В этой точке текстовые поля имеют корректную ширину, но не корректную высоту. Это тогда использует NSTextField методы для нахождения надлежащей высоты для полей данной их ширину, и добавляют ограничения высоты.

Деление ответственности между контроллерами и представлениями

Какао Автоматическая архитектура Расположения улучшает подразделение ответственности между контроллерами и представлениями. Вместо Вас пишущий монолитное, всезнающее, контроллер, вычисляющий, куда представления должны пойти для данной геометрии, представления становятся большим количеством самоорганизации. В дополнение к сокращению нагрузки на Вас в реализации объекта контроллера Какао Автоматическая архитектура Расположения также позволяет разработчику представления изменить представление более легко, не требуя, чтобы адаптировались все пользователи.

Расположение воздействует на прямоугольники выравнивания, не кадры

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

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

Для разрешения расположения на основе представления содержания, а не кадра представления обеспечивают alignmentRect объект, который является тем, на что фактически воздействует расположение.

Отладка

В автоматической системе расположения возможность отладить эффективно ясно очень важна. Какао Автоматическое Расположение предлагает несколько функций, чтобы помочь Вам найти источник ошибок. Вы цель в отладке состоит в том, чтобы обычно идентифицировать неправильное или неправильно прикладной, ограничиваете следующим этот процесс:

1. Идентифицируйте проблему.

   Например, заметьте, что представление находится в неправильном месте.

2. Если возможно, воспроизведите проблему при выполнении под новым шаблоном «расположения» в Инструментах.

   (Это может быть включено с инструментами разработчика в будущем, но в настоящее время предоставлено в связанном примере кода — посмотрите Пример кода).

3. Найдите плохое ограничение или ограничения.

   Для получения ограничений, влияющих на определенное представление, использовать constraintsAffectingLayoutForOrientation:. Можно тогда проверить ограничения в отладчике. Они распечатаны с помощью визуальной нотации формата. Если Ваши представления имеют идентификаторы (см. identifier (NSView)), они распечатывают использование идентификатора в описании, как это:

   <NSLayoutConstraint: 0x400bef8e0 H:[refreshSegmentedControl]-(8)-[selectViewSegmentedControl] (Names: refreshSegmentedControl:0x40048a600, selectViewSegmentedControl:0x400487cc0 ) >

   Иначе, вывод похож на это:

   <NSLayoutConstraint: 0x400cbf1c0 H:[NSSegmentedControl:0x40048a600]-(8)-[NSSegmentedControl:0x400487cc0]>

   Если это не очевидно, какое ограничение является неправильным в этой точке, визуализируйте ограничения на экран путем передачи ограничений использованию окна visualizeConstraints:. Рисунок 1-2 показывает пример визуализации ограничений, влияющих на горизонтальный макет поля находки.

   Полагайте, что 1-2Constraint окно отладки вывело на экран использование visualizeConstraints:.

   При щелчке по ограничению оно распечатано в консоли. Таким образом можно определить, который является, который, и обычно идентифицируют, который является неправильным.

4. Найдите код, это неправильно.

   Иногда, как только Вы идентифицировали неправильное ограничение, Вы будете знать, что сделать для фиксации его.

   Если дело обстоит не так, то в Инструментах ищут указатель ограничения (или часть его описания). Это покажет Вам интересные события в жизненном цикле того ограничения — его создание, модификация, установка в окна, и т.д. Для каждого из них Вы видите след, где это произошло. Найдите этап, на котором спутались вещи, и смотрите на след. Это - код с проблемой.

Неоднозначность

На рисунке 1-2 Вы, возможно, заметили, что отчет “Расположение не неоднозначен”. Расположение неоднозначно, если это - underspecified. Например, предположите, что система состоит из одного ограничения.

x + y == 100

Поскольку существует бесконечное число решений этого уравнения, система неоднозначна (в противоположность невыполнимому). Можно разрешить его путем добавления второго ограничения, такого как:

x == y

В нормальном ходе решения расположения система обнаруживает невыполнимость, но не неоднозначность. (Это по причинам производительности — это - в вычислительном отношении дорогая задача обнаружить неоднозначность в этой системе.) Однако при визуализации ограничений система действительно проверяет на неоднозначность. Если это обнаруживает неоднозначность, visualizer представляет кнопку Exercise Ambiguity. Рисунок 1-3 показывает панель находки после того, как было удалено одно из ограничений.

Изобразите 1-3Constraint неоднозначность иллюстрирования окна отладки

Осуществление неоднозначности (нажимающий кнопку) заставляет Ваш UI переключиться между различными состояниями, что это могло быть в учитывая текущий набор ограничений. Рисунок 1-4 показывает расположение панели находки после щелчка по Exercise Ambiguity. Заметьте различное расположение.

Изобразите 1-4Constraint окно отладки, иллюстрирующее альтернативное разрешение неоднозначности

Выборка FindPanelLayout идет через этот пример отладки, а также демонстрацию других проблем.

2010-08-30 03:48:18.589 ak_runner[22206:110b] Unable to simultaneously satisfy constraints:

(

  "<NSLayoutConstraint: 0x40082d820 H:[NSButton:0x4004ea720'OK']-(20)-|  (Names: '|':NSView:0x4004ea9a0 ) >",

  "<NSLayoutConstraint: 0x400821b40 H:[NSButton:0x4004ea720'OK']-(29)-|  (Names: '|':NSView:0x4004ea9a0 ) >"

)

Will attempt to recover by breaking constraint

<NSLayoutConstraint: 0x40082d820 H:[NSButton:0x4004ea720'OK']-(20)-|  (Names: '|':NSView:0x4004ea9a0 ) >

Автоматическое расположение поддерживает инкрементное принятие

Представления, знающие об Автоматическом Расположении, могут сосуществовать в окне с представлениями, которые не являются. Т.е. существующий проект может инкрементно принять функции Auto Layout.

Это работает через свойство translatesAutoresizingMaskIntoConstraints. Когда значение этого свойства YEStrue, который это по умолчанию, маска автоизменения размеров представления переводится в ограничения. Например, если представление сконфигурировано как на рисунке 1-5 и translatesAutoresizingMaskIntoConstraints YEStrue, тогда ограничения |-20-[button]-20-| и V:|-20-[button(20)] добавляются к суперпредставлению представления. Результирующий эффект состоит в том, что не сознающие представления ведут себя, как они сделали в версиях OS X ранее, чем версия 10.7.

Изобразите 1-5Button расположение, использующее пружины и распорки

Если Вы перемещаете точки кнопки 15 налево (включая путем вызова setFrame: во время выполнения), новые ограничения были бы |-5-[button]-35-| и V:|-20-[button(20)].

Для представлений, знающих об Автоматическом Расположении при большинстве обстоятельств, которые Вы захотите translatesAutoresizingMaskIntoConstraints быть NOfalse. Это вызвано тем, что ограничения, сгенерированные путем перевода маски автоизменения размеров, уже достаточны для завершенного указания кадра мнения, высказанного кадр его суперпредставления, который является обычно слишком много. Например, когда ее заголовок будет изменен, это предотвратит кнопку от автоматического принятия ее оптимальной ширины.

Основное обстоятельство, при котором Вы не должны вызывать setTranslatesAutoresizingMaskIntoConstraints: когда Вы не лицо, указывающее отношение представления к его контейнеру. Например, NSTableRowView экземпляр помещается NSTableView. Это могло бы сделать это, позволив маске автоизменения размеров быть переведенным в ограничения, или это не могло бы. Это - частная подробность реализации. Другие представления, на которых Вы не должны вызывать setTranslatesAutoresizingMaskIntoConstraints: включать NSTableCellView, подпредставление NSSplitView, NSTabViewItem представление или представление содержания NSPopover, NSWindow, или NSBox. Для знакомых с классическим расположением Какао: Если Вы не вызвали бы setAutoresizingMask: на представлении в классическом стиле Вы не должны вызывать setTranslatesAutoresizingMaskIntoConstraints: в автоматическом расположении.

Если у Вас есть представление, делающее его собственное расположение путем вызова setFrame:, Ваш существующий код должен работать. Просто не вызывайте setTranslatesAutoresizingMaskIntoConstraints: с параметром NOfalse на представлениях, что Вы помещаете вручную.

Для обеспечения дополнительной совместимости вся система расположения на основе ограничений неактивна, пока Вы не устанавливаете ограничение на представление. Как правило, это не что-то, что Вы должны быть обеспокоены в, но если Ваше предыдущее расположение было хрупким (в котором у Вас были проблемы Вы фиксированный путем выяснения в том, какой порядок вызываемые методы платформы), можно найти, что эти проблемы возвратились при расположении на основе ограничений. Хотелось бы надеяться, в большинстве случаев самое простое решение будет состоять в том, чтобы принять расположение на основе ограничений для затронутых представлений. Если Вы - автор платформы, обеспечивающий пользовательские представления, и хотите избежать вовлекать расположение на основе ограничений в окно, можно выполнить любую необходимую работу в updateConstraints. Этот метод не вызывают, пока расположение на основе ограничений не занято. Кроме того, одна из целей updateConstraints это, это имеет четко определенную синхронизацию, подобную awakeFromNib, таким образом, можно найти, что проблемы проще разрешить в Автоматическом Расположении.

Существует граничный случай для знания. При реализации представления Вы могли бы реализовать всю свою ограничительную установку в пользовательском updateConstraints метод. Однако, потому что система на основе ограничений привлекается лениво, если ничто не устанавливает ограничения, Вашего updateConstraints метод никогда не будет вызываться. Для предотвращения этой проблемы можно переопределить requiresConstraintBasedLayout возвратиться YEStrue сигнализировать, что для Вашего представления нужно окно для использования расположения на основе ограничений.

Пример кода

Существует несколько демонстрационных приложений, демонстрирующих работу с API, группировался в “Демонстрациях Авторасположения Какао”.

FindPanelLayout является хорошим примером для запуска с. Выборка демонстрирует, как код в уровне контроллера использует API. Это размечает окно, которое довольно сложно с классическим расположением Какао, но это прямо с ограничениями. Пример иллюстрирует использование визуального языка формата, обнимающего содержание приоритета, RTL и поддержки локализации, автоматического размера минимума окна, визуализации для отладки и понятия неоднозначности как что-то, что может пойти не так, как надо.

SplitView демонстрирует API с точки зрения представления. Это реализует представление разделения с одной дополнительной функцией: Когда делитель перетаскивается, он продвигает другие делители из пути, при необходимости, и они хватают назад. SplitView иллюстрирует усовершенствованное использование приоритета, переопределяя updateConstraints, перетаскивание и ограничения, пересекающие иерархию представления.

DraggingAndWindowResize прежде всего демонстрирует, как Вы используете NSLayoutPriorityDragThatCanResizeWindow. Это показывает, что представление с его собственным перетаскиванием изменяет размеры поля в окне, таком как Safari имеет для многострочных доступных для редактирования текстовых представлений в веб-странице. Если окно должно стать больше для размещения перетаскивания, оно делает.

Layout.tracetemplate какао является шаблоном Instruments, упомянутым в Отладке. Шаблон не является демонстрационным приложением, но это может быть полезно для нахождения ошибок.