[译] iOS 11:UIKit 中值得注意的新能力

iOS 11:UIKit 中值得注意的新能力

image

本周每个 iOS 开发者都在热切地观看 W.W.D.C. 的宣讲视频 😜

苹果的常用框架又有了新玩法

在苹果的粉丝群体中被称为 #HairForceOne 的 Craig Federighi ,在 48 小时前揭开了 iOS 11 的新面目。毫无疑问我们又有了新的 API 可以研究。相比受到了重点照顾的 iPad ,苹果今年没有给 iPhone 过多的介绍。

趁着还没有忘记,我总结了几条吸引我的新变化,顺序与重要性无关。

UIStackView

大家都喜爱的 UIStackView 只得到了一点点改变,但关键是这正是它所需要的。我曾经写过这样一篇文章 stack view 的结构越复杂就越灵活 ,但是在它的强大和神奇的自动布局之外,有一点它做的不够好:改变它子视图之间的间距。

在 iOS 11 中这一点得到了改善。事实上 PSPDFKit 的 Pete Steinberger 问大家 UIKit 的改善中什么使我们印象最深刻,我的第一想法是:

image

这个改善可以通过一个新的方法简单地实现:

let view1 = UIView()
let view2 = UIView()
let view3 = UIView()
let view4 = UIView()
let horizontalStackView = UIStackView(arrangedSubviews: [view1, view2, view3, view4])
horizontalStackView.spacing = 10
// Put another 10 points of spacing after view3
horizontalStackView.setCustomSpacing(10, after: view3)

我自己在使用 stack view 时无数次遇到上面这种场景,非常别扭。在旧版本的 UIStackView 的实现中,你只能将所有的间距设置为一致的值,或者添加一个 “spacer” 视图( API 刚出现时就有的一个非常古老的属性)来添加间距。

如果你的 U.I. 需要以动画的形式增加或减少子视图之间的间距,稍后可以去查询和设置相关参数:

let currentPadding = horizontalStackView.customSpacing(after: view3)

UITableView

在开发者社区中一直有一个争论:table view 是否应该被一个 collection view 的 UITableViewFlowLayout 或者类似的东西取代。在 iOS 11 中,苹果重申了这两种组件是明确独立的两种组件,开发者应该根据场景选择使用哪种组件。

首先,table view 默认你需要自动计算行高,设置了如下属性:

tv.estimatedRowHeight = UITableViewAutomaticDimension

这种做法毁誉参半,在解决一些令人头疼的问题的同时,它本身也带来了一些问题(丢帧,内容边距计算问题,滚动条各种乱跳,等等)。

这里注意了,如果你不想遭遇这种行为 —— 你确实有理由不想遭遇它,你可以像这样倒退回 iOS 10:

tv.estimatedRowHeight = 0

我们可以以新的方式来给用户在 cell 上左右轻划的动作添加自定义行为,我们还能精确地得到用户是从首部还是尾部轻划。这些跟上下文相关的动作是已存在的 UITableViewRowAction 的加强版,UITableViewRowAction 是在 iOS 8 中添加的:

let itemNameRow = 0

func tableView(_ tableView: UITableView, leadingSwipeActionsConfigurationForRowAt indexPath: IndexPath) -> UISwipeActionsConfiguration?
{
    if indexPath.row == itemNameRow
    {
        let editAction = UIContextualAction(style: .normal, title:  "Edit", handler: { (ac:UIContextualAction, view:UIView, success:(Bool) -> Void) in
             //do edit

             //The handler resets the context to its normal state, true shows a visual indication of completion
            success(true)
         })

        editAction.image = UIImage(named: "edit")
        editAction.backgroundColor = .purple

        let copyAction = UIContextualAction(style: .normal, title: "Copy", handler: { (ac:UIContextualAction, view:UIView, success:(Bool) -> Void) in
                 //do copy
                success(true)
        })

        return UISwipeActionsConfiguration(actions: [editAction, copyAction])
     }

    return nil
}

这个代理方法的使用和尾部轻划的使用是一致的。另一个好处是我们可以设置一个默认的轻划动作,用于响应用户向左或向右的长轻划动作,如同原生邮箱中删除邮件时所做的那样:

let contextualGroup = UISwipeActionsConfiguration(actions: [editAction, copyAction])

contextualGroup.performsFirstActionWithFullSwipe = true

return contextualGroup

这个属性的默认值是 true ,所以你得记得在不需要响应该动作时关掉它,尽管看起来大部分情况都应该响应。

为了不被超过太多,table view 从它的小兄弟(译者注:collection view )那里学了一招,table view 现在可以进行批量更新了:

let tv = UITableView()

tv.performBatchUpdates({ () -> Void in
    tv.insertRows/deleteRows/insertSections/removeSections
}, completion:nil)

UIPasteConfiguration

这一部分在 “ What’s New in Cocoa Touch ” 的宣讲中直接激起了我的兴趣。为了粘贴操作支持拖拽数据的传递,现在每个 UIResponder 都有一个粘贴配置的属性:

self.view.pasteConfiguration = UIPasteConfiguration()

这个类主要接受粘贴和拖拽的数据,它可以通过传入特定的标识符来限定只接受你想要的数据:

//Means this class already knows what UTIs it wants
UIPasteConfiguration(forAccepting: UIImage.self)

//Or we can specify it at a more granular level
UIPasteConfiguration(acceptableTypeIdentifiers:["public.video"])

而且这些标识符是可变的,所以如果你的应用需要的话,你可以实时地改变它们:

let pasteConfig = UIPasteConfiguration(acceptableTypeIdentifiers: ["public.video"])

//Bring on more data
pasteConfig.addAcceptableTypeIdentifiers(["public.image, public.item"])

//Or add an instance who already adopts NSItemProviderReading
pasteConfig.addTypeIdentifiers(forAccepting: NSURL.self)

现在我们能够轻易的处理拖拽或者粘贴的数据,不论是来自什么系统或者哪个用户,因为在 iOS 11 中所有的 UIResponders 都遵守 UIPasteConfigurationSupporting 协议:

override func paste(itemProviders: [NSItemProvider])
{
    //Act on pasted data
}

总结

很高兴能写一些关于 iOS 11 的东西。虽然总是有很多新东西等着探索和发现,但正因如此,我想我们可以从软件开发中得到一些满足感,毕竟我们中的许多人因为工作或者兴趣的原因每天都要和这些框架打交道。

W.W.D.C. 还在继续进行,大量的代码向我们汹涌而来,我们又有很多新的框架需要掌握,也有很多样例代码需要阅读。这是个令人兴奋的时刻。不论是新的臃肿的导航条,还是 UIFontMetrics ,或者是拖拽式的 API ,都有大量的新内容等着我们去探索。

来不及说了,快上车 📱


掘金翻译计划 是一个翻译优质互联网技术文章的社区,文章来源为 掘金 上的英文分享文章。内容覆盖 AndroidiOSReact前端后端产品设计 等领域,想要查看更多优质译文请持续关注 掘金翻译计划

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 215,539评论 6 497
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,911评论 3 391
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 161,337评论 0 351
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,723评论 1 290
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,795评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,762评论 1 294
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,742评论 3 416
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,508评论 0 271
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,954评论 1 308
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,247评论 2 331
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,404评论 1 345
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,104评论 5 340
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,736评论 3 324
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,352评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,557评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,371评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,292评论 2 352