摘要:一般,会在常规宽度下展示为弹窗,在紧凑宽度下变成一个透明的表。用同样不访问的技巧导致抛出一个异常说必须为这个弹窗提供位置信息。不会在操作列表的异常警告上展现一个弹窗。如果你知道解决这个问题的方法,麻烦在我的留言。
原文链接: Preventing Popovers on Popovers
原文作者: Douglas Hill
译文出自: 掘金翻译计划
译者: llp0574
校对者: yifili09,Graning
译者注:转载请保留此头部。
iOS 9 的页面用了一种我们不能复现的方式去展示一个活动视图控制器,并且当从内部表单和弹窗呈现操作列表和活动视图控制器时 UIKit 的行为一开始看起来不那么连贯。我们提交了两份 Radars 给苹果:rdar://27448912 Can’t show activity view controller filling a form sheet 和 rdar://27448488 Reading an alert controller’s popoverPresentationController property changes behavior。
iOS 的人机交互指南声明:
不要在一个弹窗上展示一个模态视图。 由于一个警告弹窗可能是一个异常,所以不应该在这上面展现任何东西。极少数情况下,当你真的需要在一个动作导致弹窗后展示一个模态视图时,应该先把弹窗关闭掉再进行展示。
并且:
一次只展示一个弹窗。 展示多个弹窗会让交互变得杂乱并让人产生疑惑。千万不要展示一个级联或者有层次结构的弹窗,一个从另一个里面产生的那种。如果你需要展示一个新的弹窗,首先关闭已经弹出的那个。
在横向水平的普通环境和全屏紧凑的环境下具有弹窗样式的视图控制器都应该呈现为弹窗。具有操作列表样式的 UIActivityViewController 和 UIAlertController 都遵守相同的规则:展示为弹窗或者一个上拉式表。所以如果一个弹窗展示一个活动视图控制器或者一个操作列表到底会发生什么?这个人机交互指南文档的说法好像有点矛盾。
在 iOS 9 页面的一个相关说明里,我们注意到在一个表单的视图控制器展示了一个填充了这个表单的 UIActivityViewController,想知道这是不是一个我们之前没有留意到的默认行为呢?又或者它是不是一个我们可以自定义实现的东西?
对于大多数视图控制器来说,在里面展示一个弹窗或者表单需要将当前视图控制器的 modalPresentationStyle 设置为 currentContext 或者 overCurrentContext。但对于某些像 UIActivityViewController 和 UIAlertController 这种 UIKit 提供的视图控制器来说,它们已经被赋予了自己的样式,modalPresentationStyle 的变化将被忽略掉。
一般,UIActivityViewController 会在常规宽度下展示为弹窗,在紧凑宽度下变成一个透明的表。但是如果一个常规宽度的视图控制器要从一个紧凑宽度的视图控制器里展示会怎么样呢?这种情况会在一个有表格或者弹窗 的 modalPresentationStyle 的视图控制器要在 iPad 上展示,或者它是一个使用了 overrideTraitCollection 属性的自定义展示控制器,然后这个控制器展示了一个 UIActivityViewController。
操作列表首先我们来看看 UIAlertController。图中根视图控制器(青色)用弹窗样式(下方,通过切分视图行为以作参考)展示了第二个用表单样式(上方)的视图控制器(粉色)。然后第二个视图控制器展示了一个操作列表样式的警告控制器。
虽然我们想要用列表的展示样式去展示操作列表(而不是弹窗),但因为关注点分离的优势,我设置了警告控制器的 popoverPresentationController.sourceView 和 popoverPresentationController.sourceRect,视图控制器不应该对它怎么展示作出假设。它应该在 app 的其他部分进行全屏展示,视图控制器不应该控制这些行为。
出于好奇,我尝试注释掉了popoverPresentationController的定义,发生了让我意想不到的情况:
原来只读取警告控制器的popoverPresentationController属性会导致即使是从一个紧凑宽度环境下呈现它也会展示为一个弹窗。如果你想这么做,请一定要确保好视图控制器展现的前后环境,因为如果你想从常规宽度的环境展现一个没有设置弹窗源码的警告控制器,UIKit 就会抛出一个异常。切记在展现触发的时候即使呈现视图控制器是在一个紧凑宽度环境下,当展示被激活的时候它还是有可能发生改变。
我提交了一个 rdar://27448488 Reading an alert controller’s popoverPresentationController property changes behavior.
活动视图控制器用UIActivityViewController做同样的事情,并指定弹窗源码信息,出现下面的情况:
不同于页面的行为,我发现表单把这个活动视图控制器展示为一个弹窗,弹窗将活动视图控制器展示在表单上。这是在 iOS 10 的新行为,iOS 9 里,是从另一个弹窗展示一个弹窗。
用同样不访问popoverPresentationController的技巧导致 UIKit 抛出一个异常说“必须为这个弹窗提供位置信息”。
结论我们发现当 UIKit 的视图控制器是从一个展示在常规宽度环境的紧凑宽度的环境中展示时行为会变得很混乱。弹窗展现的一般规则是在常规宽度下展示为弹窗,在紧凑宽度下为全屏(尽管结合当前上下环境更有意义)。操作列表和活动视图控制器的展示有点像弹窗的展示,但不要完全按照一般的规则来展示。
实际的行为看起来像是和人机交互指南说的一样,并很大程度上忽略了特征集合的 Size 类。UIKit 不会在操作列表的异常警告上展现一个弹窗。Size 类并不能控制所有的东西。
我们不能重现页面(Pages)的行为。对于我们来说,当一个表单展示一个活动视图控制器时,它将展示为弹窗。我把这个问题报告给了 Apple :rdar://27448912 Can’t show activity view controller filling a form sheet。如果你知道解决这个问题的方法,麻烦在我的 Twitter 留言。
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/16365.html
摘要:问题描述使用定位的弹窗,在的系统里,软键盘调起后,页面整体上移,当软键盘消失时,视觉上页面已经回到原始位置,但其实弹窗的焦点位置仍在软键盘调起时的位置。 问题描述: 使用fixed定位的弹窗,在ios12的系统里,软键盘调起后,页面整体上移,当软键盘消失时,视觉上页面已经回到原始位置,但其实弹窗的焦点位置仍在软键盘调起时的位置。 解决办法: 这也是参考某位大佬的解决办法 documen...
摘要:尤其是遇到二次确认等场景因此,打算从头整理移动弹窗的基础知识,以弹窗体系为切入点,从定义出发,对移动弹窗进行分类,然后分别分析每一类弹窗的应用场景,以及在使用过程中需要注意的点。 摘要: 最为常见的【弹窗】反而是最捉摸不定的东西。各种类型的弹窗傻傻分不清楚,不知道在什么场景下应该用哪种弹窗。尤其是遇到二次确认等场景…… 因此,打算从头整理移动弹窗的基础知识,以iOS弹窗体系为切入点,从...
移动端弹窗插件第二版,包括常见的 alert、confirm、toast、notice 四种类型弹窗,支持 jQuery 和 Zepto 库。 特性 支持常见的 alert、confirm、toast、notice 四种类型弹窗 可选择使用 IOS 或者 Material Design 风格的弹窗 可自定义按钮的文字、样式、回调函数,支持多个按钮 多个弹窗状态改变回调函数 同时支持 jQuery...
摘要:简述是一个风格的可定制化选项弹窗的快速解决方案,集成了上下左右中个进场方向的种动画效果,如果不能满足你对酷炫效果的需要,同样支持自定义动画,以及选择记录动画的开闭点击特效行列数量控制等。 showImg(https://segmentfault.com/img/remote/1460000008830367); 原文地址----> MyBlog HUD风格的选项弹窗是我们在日常开发中经...
摘要:如何让我们所开发的手机页面能有更好的交互体验,就是这篇文章的主旨移动开发问题和优化小结。关于和鼠标事件的延迟说明,我引用叶小钗大神博客里面的一张图片,如下在手机上,的延迟将近。 1.前言 到目前为止,互联网行业里,手机越来越智能化,移动端占有的比例越来越高,尤其实在电商,新闻,广告,游戏领域。用户要求越来越高,网站功能越来越好,效果越来越炫酷,这就要求我们产品质量越来越高,web前端开...
阅读 1508·2023-04-25 16:19
阅读 2745·2021-11-24 09:39
阅读 595·2021-11-16 11:44
阅读 1242·2019-08-29 12:52
阅读 963·2019-08-26 13:33
阅读 882·2019-08-26 10:26
阅读 1978·2019-08-23 16:42
阅读 2416·2019-08-23 14:37