如今扩展高度比iPad规定大得多 [英] Today Extension height for iPad much larger than specified

问题描述

我今天的扩展需要有基于小部件正在显示的内容的动态高度。我是能够通过我的最底部元件上增加一个约束来实现这一点：底部布局导向顶尖小于或等于所述底部最元件的底部，为0的常数，优先权999，乘法器1

My Today extension needs to have a dynamic height based on the contents the widget is displaying. I was able to achieve this by adding a constraint on my bottom-most element: bottom layout guide's top is less than or equal to the bottom most element's bottom, with a constant of 0, priority 999, multiplier 1.

这工作完全在iPhone预期 - 小部件高度适合所有的内容加上默认下边距显示下一个小部件之前应用

This works exactly as expected on iPhones - the widget height fits all content plus the default bottom margin is applied before the next widget is shown.

不过在iPad上就好像是我的设置widget的高度等于最大高度通知中心将允许小部件是 - 有很多我的小部件下方的空间，它几乎全屏幕

But on iPad it seems to be setting my widget's height equal to the max height Notification Center will allow a widget to be - there's a lot of space underneath my widget, it's nearly full screen.

如何删除多余的空间？的

How can I remove that extra space?

我知道问题是什么，但我不知道如何解决它 - 看到问题一节。首先让我解释的设置：

I know exactly what the problem is but am not sure how to solve it - see the "The Problem" section. First let me explain the setup:

的设置：结果
我设置故事板这种扩展的观点了，没有什么是编程方式。视图包括垂直堆叠5个元素，和其他一些人的水平。这些都是对于垂直线从上到下自动布局约束 - 在没有说明的首要任务是1000，乘数1：

The Setup:
I set this extension's view up in a storyboard, nothing is done programmatically. The view consists of 5 elements stacked vertically, and some others horizontally. These are the auto layout constraints for that vertical line from top to bottom - where not stated priority is 1000, multiplier 1:

UILabel: height = 35, top space to top layout guide with constant of 10
UIButton: equal height and width to a different button (whose aspect ratio is 1:1, there is no fixed width/height), top space to label 10
UIButton: equal height and width to same button, top space to above button 8
UIButton: equal height and width to same button, top space to above button 8
UIButton: equal height and width to same button, top space to above button 8, bottom space to bottom layout guide <= 0 with priority 999

的必要行为：搜索

• 我需要位于一个单一的全宽度标签的下方，4×4按键一格


• 每个按钮应该是完全相同的宽度和高度 - 所有完美的正方形


• 按钮的最后一行的下方没有额外的空间

结果：结果

The Result:

预期的结果：结果

The Expected Result:

问题：结果
所有按钮的纵横比限制最终在小工具视图的高度时，它被送到 systemLayoutSizeFittingSize间接强加一个​​隐宽高比约束：withHorizo​​ntalFittingPriority：verticalFittingPriority： ，它是在配件一级优先通过了本公司所需的优先必要的宽度（724）的布局和0的高度（以COM preSS的观点）。这将导致iPad上的一个小部件高大的图，其中的观点是更广泛的开始。但是，可以除去没有实际宽高比约束。从本质上讲，因为我申请纵横比限制为所有的按键，扩展今天的高度依赖于它的宽度（考虑所有约束在一起，纵横比和其他）。因此，延伸的高度是在广域笨拙，广泛的设备如iPad上表现出来。按钮上的限制需要重新考虑，或以某种方式调整。

The Problem:
The aspect ratio constraints on all of the buttons end up indirectly imposing an 'implicit' aspect ratio constraint on the height of the widget view when it is sent systemLayoutSizeFittingSize:withHorizontalFittingPriority:verticalFittingPriority:, where it’s passed the necessary width (724) for layout at the required priority and a height of 0 (to compress the view) at the fitting level priority. This results in a tall widget view on iPad where the view is wider to begin with. But there is no actual aspect-ratio constraint that can be removed. Essentially, because I've applied aspect-ratio constraints to all the button, the height of the today extension is dependent on its width (considering all the constraints together, aspect-ratio and otherwise). Thus the height of the extension is ungainly in a wide area, manifesting itself on a wide device like the iPad. The constraints on the buttons need to be reconsidered, or somehow adjusted.

示例项目：结果
演示问题一个示例项目可从CloudApp这样你就可以下载并使用它。

The Sample Project:
A sample project that demonstrates the issue is available from CloudApp so you can download and play with it.

我已经试过：结果
我试图通过覆盖删除默认的保证金插图 widgetMarginInsetsForProposedMarginInsets 并返回 0 的底部。这并删除默认的填充，因此降低了高度了一点，但还是有很多额外的空间，它的下面。

What I've Tried:
I tried removing the default margin insets by overriding widgetMarginInsetsForProposedMarginInsets and returning 0 for the bottom. This did remove the default padding, therefore decreased the height a bit, but there's still a lot of extra space underneath it.

的的UILabel 有一个约束它：标签领先等于上海华领先 - 恒为0，优先级1000，倍频1.如果我只是更改为上海华领先的< STRONG>缘后，多余的底部距奇迹般地消失了。我不知道是不是因为元素正变得过大，因此增加左边的间距的量会减少它们的大小，但我想保持它设置为普通龙头，增加不断，但这并没有解决问题。但是，这只是解决问题为iPad的肖像。它甚至不完全解决这个问题，每次拉下通知中心时它开始于大高度，然后逐渐缩小到合适的大小。在景观从不使用缩小到合适的大小。

The UILabel had a constraint on it: label's leading equal to superview's leading - constant 0, priority 1000, multiplier 1. If I simply change that to the superview's leading margin, the extra bottom spacing magically disappears. I wondered if it was because the elements were becoming too large, so increasing the amount of left spacing would decrease their size, but I tried keeping it set to the regular leading and increasing the constant and that didn't resolve the issue. But this only resolves the issue for iPad in portrait. And it doesn't even fully resolve it, every time you pull down Notification Center it starts at the large height then shrinks down to the proper size. In landscape it never does shrink to the proper size.

试图解决方案：

• @Lefteris提出硬编码的大小，这将不会在这种情况下工作
  随着高度是动态的和小部件可用于许多屏幕
  大小/方向。


• @Yuyutsu试图解决它，但它遗憾的是不符合要求和展品冲突的约束和改进的布局。

推荐答案

下面是如何做到了这一点：

Here's how to achieved this:

1. 您应该考虑你的约束。

1. You should consider your constraint.

您的小部件默认保证金插图不正确你所需的方式配置，因此对自己在这里通过调用设置，这是唯一的解决方法widgetMarginInsetsForProposedMarginInsets：

Your widgets default margin insets are not properly configured on the way you desired it, so setting this on your own is the only workaround here by calling 'widgetMarginInsetsForProposedMarginInsets:'

//更新部件插图

func widgetMarginInsetsForProposedMarginInsets(defaultMarginInsets: UIEdgeInsets) -> UIEdgeInsets {

    println(NSStringFromUIEdgeInsets(defaultMarginInsets))
    return UIEdgeInsetsMake(20, 20, 10, 20)
}

修改的示例文件链接：
修改文件

这篇关于如今扩展高度比iPad规定大得多的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！