Ограничения ячейки ios8 прерываются при добавлении индикатора раскрытия

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

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

Центрировать его по вертикали внутри супервизора (я думаю, это прекрасно)
Установите маркерный клей для метки до 30 (относительно супервизора)
Установите маркерный маркер до 30 (относительно супервизора)

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

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

2014-10-30 15:51:46.358 ContraintIssue[25572:1586028] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want. 
Try this: 
(1) look at each constraint and try to figure out which you don't expect; 
(2) find the code that added the unwanted constraint or constraints and fix it. 
(Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, 
refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints) 
(
    "<NSLayoutConstraint:0x7fd3f3d23390 UITableViewCellContentView:0x7fd3f3d226f0.trailingMargin == UILabel:0x7fd3f3d227e0'Label'.trailing + 30>",
    "<NSLayoutConstraint:0x7fd3f3d235f0 UILabel:0x7fd3f3d227e0'Label'.leading == UITableViewCellContentView:0x7fd3f3d226f0.leadingMargin + 30>",
    "<NSLayoutConstraint:0x7fd3f53b73b0 'fittingSizeHTarget' H:[UITableViewCellContentView:0x7fd3f3d226f0(38)]>"
)

Will attempt to recover by breaking constraint 
<NSLayoutConstraint:0x7fd3f3d23390 UITableViewCellContentView:0x7fd3f3d226f0.trailingMargin == UILabel:0x7fd3f3d227e0'Label'.trailing + 30>

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

Любые идеи?

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

(см. "рингтон" или "настройка вибрации" в добавлении контакта для примера того, чего я пытаюсь достичь)

Большое спасибо,

Ли.

Ответ 1

У меня была такая же проблема. Я хочу, чтобы макет изображения в левой руке с меткой справа, которая заполняет пространство между представлением изображения и правой (или задней) границей супервизора (который является содержимым содержимого ячейки). Аксессуар также установлен на индикатор раскрытия. Как и в вашем случае конфликтующие ограничения, где все H-based и одно я нашел в журналах, где fittingSizeHTarget. Я не узнал, что это значит и откуда это происходит, но я нашел здесь ваше сообщение.

Следующее сделало трюк для меня:

Уменьшить приоритет ограничения привязки метки к супервину. (Я выбрал 990).

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

Надеюсь, это решит вашу проблему.

Ответ 2

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

Приоритеты обычно используются в контексте, где элемент A имеет ограничение, говорящее, что высота равна или меньше/больше 300, а элемент B имеет один, который говорит, что высота равна или меньше/больше 500. Затем автозапуск может удовлетворять обоим условиям на основе их приоритеты.

В этом конкретном примере обе ограничения установлены на определенное значение, а приоритет понижения, по сути, указывает на игнорирование этого ограничения, если это невозможно удовлетворить (там нет "частично игнорировать его" ). Однако. У UILabel есть исключение. Поведение UILabel по умолчанию заключается в том, чтобы изменить его размер, чтобы он соответствовал содержанию, если только он не ограничен дополнительными полями (ограничение автосохранения скрывается под именем fitSizeHTarget), и это поведение иногда показывает ложные предупреждения. В действительности это ограничение будет проигнорировано во время выполнения, но прежде чем оно будет отключено внутренне, оно выдаст предупреждение. Поэтому, несмотря на то, что мы говорим, чтобы игнорировать одно из наших ограничений, понижая его приоритет (тот, который мы устанавливаем приоритетом на 900), поскольку ограничение автосохранения будет игнорироваться во время выполнения, наш приоритет 900 будет применен и удовлетворен.