1、网络慢或者接口返回慢......
如果添加动作是依赖于接口 接口返回比较慢的时候 此时用户已经访问到其他页面了 突然出现一个view 不是莫名其妙吗?
如果返回页面还好一点 请求可以被取消 如果是前进页面或者进入模态页面比如登录页面呢 就有问题了
这种情况想解决就要增加逻辑判断 带来新的副作用
2、盖住后面的事件......
举例一、即使不依赖接口 比如用户先点击了一个跳转页面的按钮 事件是接口返回后跳转的
如果在接口返回前,然后点击当前页面按钮出现添加到window的弹窗。
这个时候 接口返回了 会在弹窗后面跳转页面...... 奇怪吧
举例二、全屏弹窗App进后台,然后点了个推送,或者通用链接或者3D touch事件,发现在弹窗后面跳转了页面
3、咋办?
增加viewWillDisappear的处理? 移除掉弹窗?全屏幕的弹窗也行,那局部的呢 比如提示类的view,那viewWillAppear 还加回来?想想就复杂
4、总结
总之程序是复杂的 用户的使用情况更是复杂的。
尽量避免添加到Window上,如无法避免记得考虑接口返回慢 用户跳转到其他页面等情况
推送打开App等情况, 注意移除window上的view 判断有没有模态页面。以及当前是哪个页面来处理,比如填写订单页面等重要流程 就不要打断用户操作流程了,推送消息可以放到消息中心里,以便以后查看。
5、最好的方式
局部的view 加到 ViewController的view上
全屏幕的 按照苹果的规范来 弹窗用 模态页面 可以设置全屏、非全屏等 用户还可以手动向下划动关闭弹框 用户体验更好 更统一