仅使用自动布局的iOS8今日扩展的高度给出了破坏的约束 [英] Height of iOS8 Today Extension using Only Auto Layout Gives Broken Constraints

问题描述

Apple文档建议使用自动布局设置今日扩展的高度。

Apple documentation suggests setting the height of Today Extensions using autolayout.

如果窗口小部件有其他要显示的内容，则可以依赖自动布局约束以适当调整窗口小部件的高度。如果您不使用自动布局，则可以使用UIViewController属性preferredContentSize来指定窗口小部件的新高度。

If a widget has additional content to display, you can rely on Auto Layout constraints to adjust the widget’s height as appropriate. If you don’t use Auto Layout, you can use the UIViewController property preferredContentSize to specify the widget’s new height.

但是，每个示例和我看到的教程最终使用 preferredContentSize 。

However, every example and tutorial I have seen ends up using preferredContentSize.

我通过autolayout设置高度的所有尝试都导致破坏约束的警告。

All of my attempts to set the height via autolayout lead to warnings of broken constraints.

我从一个全新的xcode模板开始，一个新的今天的扩展模板。我添加到 TodayViewController.m 的唯一内容是：

I started with a fresh xcode template, and a fresh today extension template. The only thing I added to the TodayViewController.m was:

- (UIEdgeInsets)widgetMarginInsetsForProposedMarginInsets:(UIEdgeInsets)defaultMarginInsets {
    return UIEdgeInsetsMake(0, 0, 0, 0);
}

注意：如果我只使用默认边距，我仍会遇到此问题。

Note: I still get this problem if I just use the default margins.

我约束标签高度，将标签置于容器中心，并将容器高度限制为与标签高度相同：

I constrained the label height, centered the label in the container, and constrained the container height to be the same as the label height:

这应该导致一个标签在指定的高度填充容器，没有约束冲突。相反，我得到一个约束冲突：

This should lead to a label that fills the container at the specified height with no constraint conflicts. Instead I get a constraint conflict:

2014-09-28 10:27:39.254 TodayExtension[61090:2672196] 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:0x7f8b8b62c670 V:[UILabel:0x7f8b8b62d9b0'Hello World'(124)]>",
    "<NSLayoutConstraint:0x7f8b8b583020 UIView:0x7f8b8b62d6e0.height == UILabel:0x7f8b8b62d9b0'Hello World'.height>",
    "<NSLayoutConstraint:0x7f8b8b5888a0 'UIView-Encapsulated-Layout-Height' V:[UIView:0x7f8b8b62d6e0(667)]>"
)

Will attempt to recover by breaking constraint 
<NSLayoutConstraint:0x7f8b8b62c670 V:[UILabel:0x7f8b8b62d9b0'Hello World'(124)]>

Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.

它打破约束的方式实际上看起来像我想要的那样：

The way that it breaks the constraints, it actually ends up looking like I want it to:

然而，在其他项目，它决定打破其他约束，它看起来不正确。另外，旁注：如果我尝试更改高度约束的优先级，它会崩溃Xcode。这很有趣。

However, in other projects, it decides to break other constraints and it doesn't look correct. Also, side note: if I try and change the priority of the height constraint it crashes Xcode. So that's fun.

我曾希望由于限制高度不起作用，也许如果我没有将容器高度约束到子视图，这可能会找出容纳子视图并正确设置自身所需的高度。

I had hoped that since constraining the height didn't work, maybe if I didn't constrain the container height to the subviews, that perhaps it would figure out the required height to house the subviews and set itself correctly.

我将子视图集中并限制其高度：

I centered the subview and constrained its height:

这导致了一个扩展，它占用了通知中心的整个高度，并且我的正确大小的视图垂直居中：

This just led to an extension that uses up the full height of the notification center, and my correctly sized view vertically centered:

如果我不居中，而是将垂直空间固定到顶部布局指南，我会得到相同的东西，除了子视图固定在顶部（但是容器仍然巨大）。

If I don't center, but instead fix the vertical space to the top layout guide, I get the same thing except that the subview is fixed to the top (but the container is still huge).

我知道我可以使用 preferredContentSize ，但是为什么Apple会说它可以使用Auto Layout约束设置？我做错了什么？

I know I could just use preferredContentSize, but then why would Apple say it can be set using Auto Layout constraints? What am I doing wrong?

我给出的例子显然是做作的。我正在设置视图的高度，所以为什么不设置容器的高度，对吧？在实际项目中，部分要点是仅使用autolayout基于宽度设置窗口小部件的高度。

The examples I have given are obviously contrived. I'm setting the height of the view, so why not just set the height of the container, right? Part of the point of this in an actual project would be to set the height of the widget based on the width using only autolayout.

推荐答案

经过一些实验，并遇到什么是NSLayoutConstraint" UIView-Encapsulated-Layout-Height"以及我应该如何强制它干净地重新计算我确定你可以使用Height和& 等高或高度以及顶部和底部垂直空间（由 Guilherme Sprint 建议），然后将高度约束的优先级降低到999.

After some experimenting, and stumbling across "what is NSLayoutConstraint "UIView-Encapsulated-Layout-Height" and how should I go about forcing it to recalculate cleanly" I determined that you can circumvent this problem using either "Height" & "Equal Heights" OR "Height" and Top and Bottom "Vertical Space" (as suggested by Guilherme Sprint), and then decreasing the "Priority" of the height constraint to 999.

这不是我希望的答案，但是它确实指定了容器的高度通过子视图的自动布局，避免任何关于破坏约束的警告。

This isn't the answer I was hoping for, but it does specify the height of the container via Auto Layout of the subview and avoids any warnings about broken constraints.

我完全不科学的猜测/假设/结论是iOS正确地查看布局约束来确定容器视图的高度。然后，它会添加一个与刚刚计算的高度相同的新约束，但现在这会过度约束高度。降低原始开发人员指定的高度约束的优先级意味着系统生成的约束胜出并且没有生成警告（希望从实际知道的人那里听到更多关于此的信息）。

My entirely unscientific guess/assumption/conclusion is that iOS is correctly looking at the layout constraints to determine the height of the container view. It then adds a new constraint that is the same height as what it just calculated, but this now over-constrains the height. Reducing the priority on the original developer specified height constraint means the system generated constraint wins out and no warning is generated (would love to hear more about this from someone who actually knows).

这篇关于仅使用自动布局的iOS8今日扩展的高度给出了破坏的约束的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！