Tag: 布局

Xcode 7中的堆叠vs多行标签

大家好 一年前,我在一些教程的帮助下开始了我的第一个Xcode项目。 最近,通过一些断断续续的编码,我开始使用约束和堆栈视图。 堆栈视图 Apple在WWDC 2015上介绍了堆栈视图。使用堆栈视图和约束,您几乎可以为所需的任何Apple iDevice设置自动布局。 它能做什么 堆叠视图可水平或垂直堆叠多个级别。 单独的堆栈视图不会有多大帮助,您仍然需要固定或对齐按钮,图像或标签。 在Xcode 7之前,界面构建器中唯一的约束选项是align和pin按钮。 借助堆栈视图,您可以设置复杂的多设备布局。 对于非开发人员来说(乍一看)可能会让人感到困惑,但是它实际上很酷。 示例:复古计算器应用 为了获得一个想法,这是我正在为devslopes(https://www.devslopes.com)在线课程开发的复古计算器的示例。 我要做的是:垂直堆叠行(例如7,8和9),然后水平堆叠所有行。 有一些后续工作需要对整个堆栈进行对齐,以使其在应用程序中居中。 但是您会看到它如何在每个界面上居中。 当然,我本可以修复iPad上丢失的空间,但是此示例只是为了说明我的观点。 不要堆叠多行标签 现在在上面的示例中,您看到一个只有1行的简单标签。 您可以轻松地将其堆叠,不会引起任何问题。 但是后来我在多行标签上进行堆栈视图练习,然后尝试将其水平堆叠到其他堆栈。 这是示例应用程序的屏幕,在堆叠之前有一些按钮和多行标签: 堆叠后是同一个屏幕: 您会看到我遇到的问题。 我很头疼,我尝试将行设置为0或更多行,尝试了对我来说有意义的每个值,但是这对堆栈视图没有帮助。 在其上放置堆栈视图后,宽度更改为1600以上,(至少对我而言)没有意义。 我正在检查stackoverflow以查看是否有任何开发人员遇到与我相同的问题,并找到了这个问题。 投票最多的解决方案是为堆栈视图设置固定宽度。 我一直在想这不是苹果想要的。 事实并非如此。 解 这很简单,我想它只是一个错误。 只需在标签中设置一个占位符单词即可 ( 您可以使用多个单词,但不要使用完整的句子,这样此时它最终会以多行标签出现 ) 堆叠标签 用您打算使用的多行文字交换单词 完成这些步骤后,我能够按照本教程的要求堆叠视图。 我还没有玩过Xcode 8 beta,而且我仍然不是100%确信这确实是Apple的错误或某种原因,但是至少我不再遇到这个问题,老实说,试图解决这个问题这个问题对我总体上了解堆栈视图和约束有很大帮助。 问候, 一月

UIScrollView使用AutoLayout配置

当我们使用UIScrollView时,它会受到管理限制。 因此,这是使用AutoLayout管理UIScrollView的简便方法。 所以我们开始吧 步骤:1选取一个UIScrollView。 步骤2:将Constrain设置为0,尾随,前导,顶部和底部。 步骤:3取一个UIView来管理UIScrollView。 因此,控件的实际层次结构如下所示: 步骤4:将UIView的Constrain设置为尾部,前部,顶部和底部,并设置0。 步骤:5现在我们可以看到AutoLayout问题,因此,我们还向UIView添加了2个约束,如SuperView的Equal Width和Equal Height的给定与您想要的相同(我在这里给出1900以进行测试) 步骤:6运行该应用程序并进行测试。 您可以观看视频: 下载代码: https://github.com/javedmultani16/UIScrollView

我们如何为iOS动态更改布局

什么是动态更改的布局? 由于设备尺寸的不同,此布局也有所不同。 我上一个项目时遇到了此类问题。 主要思想是缩放屏幕上我们拥有的所有内容。 因为更大的屏幕需要更多的调整。 如何解决? 您可能会得到的第一个想法是“尺寸等级”。 实际上,我们最初也使用了此方法,但这还不够。 当项目增长时,控制器也将增长。 这导致对每个尺寸类别使用更多不同的约束。 当您尝试更改任何内容时,这会使您的生活如地狱般艰难。 这些并不是我们使用此想法遇到的所有问题。 有些控制器的UI非常复杂,几乎与任何设备都不一样,因此我们被迫使用几乎所有可能的尺寸等级。 想象一下,当您需要为iPad进行某些更改时,可能会浪费大量时间来寻找iPad的位置。 当我们不想更改约束常数,而是更改其乘数或优先级时,就会出现一个更大的问题。 在size类中实际上是不可能的。 相反,您需要为每个尺寸类别创建不同的约束,并在其中包含所需的值,否则,将对该约束的其他尺寸类别禁用该约束。 我们到底会得到什么? 最终,这种方法真的很难支持,它不灵活,情节提要变得非常复杂,我们有很多难以处理的约束。 最后,无法区分4s,5、6等设备(将来列表可能会更大)。 新分辨率的设备呢? 我们需要为这些创建新的UI。 这意味着我们可能需要在新设备发布时更新代码并将新版本上传到Appstore。 这可能不是项目的最佳解决方案,因为此更新可能由不熟悉先前项目体系结构的其他开发人员执行。 我可以发现的唯一好处是,所有UI工作人员均在UI文件中执行,并且未与代码连接。 这使我们的代码更加清晰。 即使有很多弊端,我们也可以接受这种方法,因为当我们打开它时,它有可能缩放所有设备的UI,这在Size Classs中是不可能的。 我们可以得出的结论是忽略尺寸等级。 下一步是什么? 我们要做的下一步是从代码更改约束值。 由于设备的差异,我们使用不同的值。 这种方法有多好? 实际上,这可能很奇怪,但是绝对比Size类好。 我们可以轻松地将此代码与其余所有代码分开。 是的,这不是明确的分离,并且代码量大量增加。 最后,代码量急剧增加。 添加新视图或更改现有视图需要花费大量时间。 但是,对于开发人员来说,情况变得更加清晰,并且情节提要文件的权重降低了。 这种方法使我们能够覆盖所有设备。 未来设备的问题仍然存在,没有人愿意回到他们以前的项目并为所有视图添加新值。 对于开发人员来说,这将是一个地狱,特别是如果该项目很大。 我想强调的是,以上所有内容都可以应用于字体以及约束。 接下来的两个解决方案可能是最好的,各有其优缺点。 最后,您只需要决定哪个更适合您即可。 先前方法的主要问题是什么? 我们需要将大量代码添加到新视图中。 这会花费很多时间,并且代码变得非常复杂和丑陋。 问题是在哪里删除此代码,或者对我们来说如何简化呢? 在IBInspectable属性中找到了该解决方案。 我们为每个更改约束常量的设备添加了约束属性。 这是一个代码示例,该代码是如何实现的。 @interface NSLayoutConstraint(BBBDevices) @属性(非原子,分配)IBInspectable […]

iOS-如何在界面生成器中使用安全区域布局

本篇文章没有要讨论安全区域是什么,只有单纯纪录如何使用界面生成器来更改原始导航栏或工具栏 会有这个需求是因为画面客制化的关系,没办法直接使用原生的导航栏/工具栏,得自己刻出类似的画面。 如果直接把灰色视图的顶部,前导,尾随约束指向安全区域,会变成上图右边的状况,status bar的部分会空着,没办法像左图那样的效果 把view的顶部约束指向指向superview,结果赋予view跑到status bar底下 回到上一个状态(顶部约束指向安全区域),在视图中间加入一个标签,执行结果如下图,但我想要达成的效果应该是标签在相同的位置,视图的高度不变,然后状态栏跟随标签所在的视图是一样的颜色 以下的view指的是灰色长条状,用作考虑的标签的superview 将标签的顶部约束重新指向视图控制器>视图>安全区域 2.将视图的顶部约束改为指向超级视图,常量设为0,高度设为≥44 3.重新执行后,画面就会如预期想要的那样 4.要特别注意的,标签一定要加上底部约束指向视图,不然就会出现下图的状况 等等,还没结束 以上的作法都是在storyboard完成的,但在xib上会遇到什么事? 一样的autolayout配置,使用在xib上,在iOS12上看是正常的,但iOS10就跑版了,有一部分跑到status bar底下去(如下图) label增加一个约束(要查看的顶部空间),常量设置≥32,优先级设置为1000,原本指向视图控制器>视图>安全区域的约束(将顶部对齐至安全区域)优先级设为750,再执行一次就可以看到正常的画面 我把范例档案放在这边,有兴趣的话可以载来看看! iOS –安全区域布局在iOS 9和iOS 10上不起作用 感谢您为Stack Overflow提供答案! 您过去的一些答案尚未得到很好的接受,您正在… stackoverflow.com

Swift教程:如何在Interface Builder中使用AutoLayout在水平方向上配置NSScrollView(MacOS X,Swift 4.2)

本文最初发布在 http://popcornomnom.com/ 你好! 不久前,我已经开始为MacOS编写应用程序(我具有IOS开发背景),并且遇到了这样一个问题,即我的问题大部分答案是: 已过时(超过3年前的答案,因此某些功能已被弃用) (关于目标C的一些答案让我的“笨拙”的眼睛有点痛苦), 答案适用于iOS,而不适用于OS X 有时找到所需答案的难度比应该的要难。 因此,我决定开始编写循序渐进的快速教程(格式为问题解答的简单教程)。 问题 内容不适合应用程序窗口,并被视图控制器剪切。 解 要解决此问题,您需要向视图中添加约束以达到内容的动态宽度和高度。 好的,让我们开始吧! 步骤1-3。 (步骤1-在下面的图像上)首先将NSScrollView拖动到ViewController。 然后在“属性检查器”的左侧面板中,选择(2)“边框类型” —无,然后选择(3)取消选中“绘制背景”。 步骤4。 之后,添加与超级视图相关的顶部/底部/前导/尾随约束。 我将最高约束设置为20,因为我的NSWindow“完整内容视图” = true。 第五步 然后添加您的内容视图(在我的情况下,这是2个由NSStackView包装的标签)。 第六步 接下来,我们向您的contentView添加顶部,顶部,尾部约束,并向底部添加两个底部约束。 我将所有常量设置为24。 步骤7–8。 然后(7)将第一个底部偏移关系更改为小于或等于(≤) ,并将优先级设置为490 ,(8)将第二个底部偏移关系设置为 – 大于或等于(≥) , 优先级为510 。 步骤9。 (9)除此之外,我还添加了一个最小的contentView宽度500( 宽度常数 = 500 , 关系大于或等于 )。 步骤10-11。 对于scrollView的documentView,添加顶部,顶部,两个尾部和两个底部约束。 (10)将第一尾随偏移关系设置为小于或等于 ,并将优先级设置为510 ,对于第二关系 – 大于或等于 ,将优先级设置为490 。 […]

UIScrollView和AutoLayout

自iOS 2.0起,UIScrollView就已经存在了。 但是,也可以使用AutoLayout配置滚动视图! 由于AutoLayout可以为您完成此操作,因此可以大大减少计算内容大小所需的代码量! 另外,它适用于风景和肖像。 配置UIScrollView 将UIScrollView拖到故事板上的视图控制器中。 将UIScrollView固定到整个视图。 配置内容视图 现在,在UIScrollView中创建一个名为ContentView的UIView。 这是我们所有内容的放置位置。 让我们将其固定到滚动视图! 关键的步骤到了。 再添加一个约束以消除那些令人讨厌的自动布局错误。 使内容视图与视图的宽度相等。 和繁荣,你完成了! 测试出来 内容视图中的所有视图应具有足够的约束,因此AutoLayout知道可以扩展多少内容大小。 我决定使用UIStackView来减少约束数量。 修复导航控制器中的填充 快速提示,如果您将此视图控制器嵌入到导航控制器中,则需要取消选中“视图控制器”中的“调整滚动视图插图”; 否则,您将获得额外的填充。 的GitHub 完整项目可在GitHub上获得

使用Swift(iOS)中的约束以编程方式对视图进行动画处理

您知道对我来说,应用程序开发中最有趣的部分是什么? 它正在改善用户体验(UX)。 改善用户体验的方法之一就是在应用中添加直观的动画。 我们可以通过多种方式实现这一目标,一种方式是修改如下所示的GIF之类的约束。 让我引导您完成这些简单的步骤,以实现惊人的动画效果。 首先为徽标图像定义topView。 私人懒惰var topViewForImage:UIView = { 让view = UIView() view.backgroundColor = .lightGray view.translatesAutoresizingMaskIntoConstraints = false 返回视图 }() translatesAutoresizingMaskIntoConstraints是允许我们以编程方式向视图添加约束的一种方法。 不要忘记将其设置为false 现在该创建imageView以在topView中显示一些图像了, 私人懒惰var topImageView:UIImageView = { 让图像= UIImageView() image.image = imageLiteral(resourceName:“ appLogo”) image.contentMode = .scaleAspectFit image.translatesAutoresizingMaskIntoConstraints = false 返回图片 }() 为NSLayoutConstraints定义类型为NSLayoutConstraints的高度锚点,因为我们需要在各种事件(例如keyboardWillShow()和keyboardWillHide(), var heightAnchor:NSLayoutConstraint? 现在,在ViewController中添加视图和约束。 覆盖func viewDidLoad(){ super.viewDidLoad() view.addSubview(topViewForImage) topViewForImage.addSubview(topImageView) addConstraintsToView() } func addConstraintsToView(){//向topViewForImage添加约束 […]

为什么我停止在iOS项目中使用Storyboard和Xib

故事板可帮助我们简化创建iOS应用程序的UI。 拥有一个仅需几次单击和拖动的模拟应用程序,真的很棒,对吗? 我们甚至可以忘记导航,即每个应用程序使用的功能。 仅通过从一个屏幕到另一个屏幕的链接即可完成所有导航,如果转换很复杂,有时还可以使用自定义代码。 苹果正在继续改进Xcode的Interface Builder,以添加越来越多的功能来帮助开发人员简化其UI存根。 例如,我们现在可以预览不同屏幕尺寸的渲染。 我发现此功能非常有用。 当我们由一个小型团队(或一个人)开发一个小型应用程序时,所有这些好东西仍然是好的。 一旦应用程序扩展,团队就会成长,使用情节提要和.xib可能会成为噩梦。 让我们看看为什么。 如果我们没有足够强大的MacBook(Pro),则当我们不得不打开一个大的故事板时,Xcode可能会冻结您的计算机一段时间。 即使使用简单的情节提要板,我也花了大约10秒钟的时间在Xcode中打开它。 对于必须使用旧的MacMini或旧的MacBook开发的人来说,这可能会降低他们的工作性能。 当我们创建具有多个屏幕的大型应用程序时,情节提要文件可能会非常庞大​​。 概述和遵循应用程序流程并非易事。 如果有新的开发人员加入该项目,他将很难理解屏幕之间的逻辑和转换。 当然,我们仍然可以采用一种解决方法来创建使用情节提要面板场景,以将其分隔为多个情节提要面板,并避免使用大型情节提要。 但是,从中创建View / ViewController的实例时,开发人员应该照顾故事板名称或Xib名称。 使用情节提要/ xib时最不方便的是与.storyboard或.xib文件存在某些合并冲突。 当团队的开发人员在不同的存储库分支中同时编辑同一.xib或.storyboard,然后合并到主分支中时,就会发生这种情况。 情节提要和xib文件均为XML格式。 但是这些XML不是用户友好的。 Xml节点是自动生成的,这使我们很难知道xml中带有节点的UIView的引用。 每个节点还具有很多属性(用于指定高度,宽度,位置,颜色等)。 发生合并冲突时,如果合并不正确,将导致错误的结果,有时我们会破坏xml格式,因此无法打开.xib或.storyboard文件。 基本上,我们不会通过Storyboard / xib创建ViewController和View,而是将它们全部写入* ViewController.m / .swift或* View.m / swift。 在这篇文章中,我只会以Swift来编写代码,因为我更喜欢Swift而不是Objective-C,而且我相信你们也喜欢Swift。 假设我们要创建一个包含登录名和电子邮件文本字段以及用于处理登录的按钮的登录屏幕,如下所示: 我们将必须创建两个类: LoginView.swift和LoginViewController.swift 。 LoginView.swift继承了 UIView的子类,并且包含用于构建要在所有自动布局约束条件下显示的视图的代码。 LoginViewController.swift继承了 UIViewController的子类,并包含我们需要应用于这些元素的控件处理程序。 首先,让我们看看我们在LoginViewController.swift文件中要做的事情。 它不是那么复杂,对吗? 我们要做的就是重写loadView函数,以告知LoginViewController它需要加载并使用LoginView类中的自定义视图。 然后,ViewController应该控制此View内部的功能元素,以控制用户单击登录按钮或关闭按钮时的操作 。 在ViewController类中,我们不实现任何视图布局或视图的自动布局。 所有视图布局必须在View类内部完成。 这样,ViewController将变得更轻,更清洁。 […]

带有情节提要的高级动态自动布局

众所周知,iPhone的尺寸截然不同,因此开发人员可以应对。 为了创建看起来不错/复杂的场景,UI组件需要与其他组件保持动态约束。 让我给你一个我在工作中的设计师给我的情况。 我指的是常量部分正下方的“优先级”。 您可以直接使用优先级。 如果存在彼此相对应的约束,或者在同一UI组件上设置的约束多于约束,则优先级用于确定Xcode坚持的约束。 当然,选择的优先级更高。 在本期中,它可能不只是一个小尺寸的屏幕,因此我们将所有内容都放在滚动视图中作为第一步。 这是我如何设置动态自动布局的提示。 您要处理最坏的要求/限制,然后再转到理想的要求。 让我们看一下必须远离顶部的顶部图像视图。 它必须与顶部至少相距40,但最好为70。 因此,最糟糕的要求是它必须与顶部保持40的距离,因此我们将此约束设置为1000优先级,这是最高优先级,这样其他约束不会对其产生任何影响。 对于距离顶部70的位置,我们将赋予700优先级,这意味着在将所有约束设置为高于700的优先级之后,我们将转向该约束条件,看看是否需要设置。 现在我们完成了顶部图像视图部分。 有多容易? 我们不需要计算空白空间,不需要放置很多if条件,就可以设置约束。 让我们进入拒绝组视图。 由于当我们显示拒绝原因时,我们要相应地更改高度约束,而不是手动更改。 我们如何实现适合内容的自动高度限制? 为此,我们将使用内容抗压缩性优先级。 对于不熟悉内容抗压缩优先级的用户,这基本上是优先级,其中当将某个UI组件在垂直或水平方向上抑制为较小尺寸并且其抗压缩优先级高于对其进行压缩的约束时,UI不会被压缩。 如上所示,我们将拒绝标签的内容抗压缩优先级设置为1000,这意味着该标签在任何情况下都不会被压缩。 您可能要看的一件事是拒绝组视图和横幅视图之间的距离。 它的大小很大没有问题,但是当它很小时,它可能会与另一个重叠,因此我们需要为此设置约束。 彼此之间没有特定的距离,但它的设置方式是两个必须彼此分开。 这就是为什么它的优先级也是1000! 和田田! 都结束了。 是时候检查它是否适用于较小的尺寸,例如iPhone 4s。 如您所见,图像视图和顶部之间的距离是我们想要的40,其他UI组件的行为也与设计时一样,例如拒绝原因标签随内容占用而改变高度限制。 我们已经学习了如何将优先级用于复杂的约束关系。 这是关于哪个优先级更高,哪个对哪个优先级设置了约束。 即使我是程序设计UI的拥护者,但我还是使用Storyboard处理复杂场景的忠实粉丝。 试试看。 如此简单和直接会让您惊讶! 感谢您抽出宝贵时间阅读此博客。 如有任何疑问,请随时告诉我:)

Xcode大学—故事板和Segues快速入门

以任何设备查看 不久前,在情节提要中创建新场景时,我们将获得一个500×500的正方形框来表示我们的视图。 老实说-我喜欢它! 它足够抽象,可以构建通用布局,而无需不知不觉地仅针对一个屏幕大小进行设计。 困难的部分是使用iPad上的每个屏幕尺寸,不同方向和分屏进行测试。 今天,我们可以单击屏幕底部的“查看为”,并为每个设备和方向呈现布局,而无需构建和运行项目。 IBDesignable / IBDesignable 是否曾经创建过自定义视图,并且不得不修改一些代码,运行应用程序并转到视图可见的位置,以查看其外观? 真浪费时间。 使用IBDesignable属性,您的自定义视图将立即在情节提要中呈现! 使用IBInspectable ,您可以在属性检查器中为任何自定义UIView或UIViewController类显示属性。 查看Nate Cook撰写的有关NSHipster的快速指南。 何时不使用情节提要 我们证明情节提要很棒,但并不总是如此。 有些事情他们做不到。 例如: 没有一些技巧,就不可能重用自定义视图,因为没有场景就无法创建视图。 当前,我们必须使用一个nib文件。 对于在不同视图控制器中重用的表/集合视图单元格,同样适用。 Segues非常容易,但是对于链式转换来说效果不佳。 立即关闭并显示视图控制器时,由于转换在转换之前已完成,因此显示将失败(带有已记录的警告)。 结论 Tabs vs. Spaces阵营可能永远不会停止战斗,但这并不意味着我们无法做出自己的命运。 故事板,笔尖与代码阵营可以并存,并在一个大型的快乐项目中享受每个阵营的好处。 如果您有任何疑问,请随时与我联系,或者随时在Twitter上与我联系。 不要忘记查看我们的聚会-Swift Coders和Learn Swift LA。 制表符与空格 有用的资源 Marcin Krzyzanowski编写的情节提要代码生成器—该框架将为情节提要创建具体类型,而不是使用字符串标识符。 想要尝试一会儿。 在AdrienCognée的情节提要中使用IBDesignable和可重复使用的Nib文件-我做了非常相似的事情,以便能够在情节提要中呈现自定义视图。 这是“ hacky”,但非常有用。