Code for a better world.

Xcode 10 release 之后第一时间便是更新了 Xcode 10，但是项目一运行发现编译错误。相信很多人都也遇到了这个问题。毕竟在好几个群里都看见了这个文件在传来传去。

早在之前 beta 的时候就知道了苹果已经在 Xcode 10 中彻底移除了 libstdc++6.0.9 这个库，当时 stackoverflow 上就有了从 Xcode 9 中把这个库弄出来的方法。遇到这个问题，我也首先想到了这个解决方案，然而很不幸的是，模拟器，真机不能同时运行。接下来我做了这些事情：

UserProfile

每个用户都有 name、 firstName、 lastName 有些用户还有 email、phoneNumber 。模型可能会是这样:

1
2
3
4
5
6

struct UserProfile {
    let name: String
    let lastName: String
    let phoneNumber: String？
    let email: String?
}

可能我们每天都会看到这样的模型，也习惯了这样的模型，但仔细思考一下。email 有没有把信息完整的表示出来呢？还有phoneNumber ？ 他俩仅仅只是字符串吗？

过载(overloaded)

对象需要表示的信息: 类型、身份、行为、状态、值

对象具有的用来表示信息的方法: 类、实例化、方法、属性

这就带来了一个问题，属性需要用来表示状态和值两种信息。

在 Swift 中用泛型用得很爽了, 回过头来有时候还是想要在 OC 中也用到这项技术。对 iOS 开发来说可能很多人都觉得 OC 是没有泛型的，但其实早在15年，苹果就在 OC 中引入了泛型。虽说引入泛型的目的是更好的实现 Swift 和 OC 的兼容(苹果叫它Lightweight generics)。

知道 ObjectMapper 的人大概都见过在使用 Mappable 定义的模型中 func mapping(map: Map) {} 中需要写很多 name <- map["name"] 这样的代码。这里的 <- 将模型中的属性跟数据中的 key 对应了起来。

Swift 提供的这种特性能够减少很多的代码量，也能极大的简化语法。在标准库或者是我们自己定义的一些类型中，有一些只是简单的一些基本的值类型的容器，比如说 CGRect、CGSize、CGPoint 这些东西。或者直接使用 John Sundell 的文章 Custom operators in Swift 中的例子。在某个策略类游戏中，玩家能够手机两种资源木材还有金币。为了要将两种资源模型化，定义了 Resources 这个结构体。

每到年关，总会看到各种各样的年终总结。大学以来一直坚持着记录一些东西的习惯。趁着今年的政治任务，还是开始了今年的总结。与其说是总结，不如说是好好的给刚刚过去的这段时间说说再见，然后再给新的阶段说句你好。

你可能听过这个术语 :类型擦除。甚至你也用过标准库中的类型擦除(AnySequence)。但是具体什么是类型擦除, 我们怎么才能实现类型擦除呢？这篇文章就是介绍这件事情的。

在日常的开发中, 总有想要把某个类或者是某些实现细节对其他模块隐藏起来, 不然总会感觉这些类在项目里到处都是。或者想要实现两个不同类之间的互相转换。类型擦除就是一个移除某个类的类型标准， 将其变得更加通用的过程。

到这里很自然的就会想到协议或者是提取抽象的父类来做这件事情。协议或者父类 就可以看作是一种实现类型擦除的方式。举个例子:

NSString 在标准库中我们是没办法得到 NSString 的实例的，我们得到的所有的 NSString 对象其实都是标准库中 NSString 的私有子类。这些私有类型对外界可以说是完全隐藏起来了的, 同时可以是用 NSString 的 API 来使用这些实例。所有的子类我们在使用的时候都不需要知道他们具体是什么, 也就不需要考虑他们具体的类型信息了。

在处理 Swift 中的泛型和有关联类型的协议的时候, 就需要一些更高级的东西了。Swift 不允许把协议当作类来使用。如果你想要写一个接受一个 Int 类型的序列的方法。这么写是不对的:

1
2
3

func f(seq: Sequence<Int>) {...}
// Compile error： Cannot specialize non-generic type 'Sequence'

已经有好几个人跟我抱怨过为什么 swift 里面有那么多问号(?)还有叹号(!)了。恰恰哈, 在刚刚开始写 swift 的时候, 我也面临着这种问题。

昨天一个朋友发了我一行代码, 让我看看应该怎么写:

1

let pageiid = (self.pageid?.intValue)! + 1

这段代码看起来很操蛋, 但是糟心的是, 在刚刚写 swift 的时候， 我写过更恶心的代码。

既然大家在刚刚开始写 swift 的时候都遇到了这个问题。今天就来看看, 这样的代码应该怎样写才能让我们更爽。

之前翻译过 Mike Ash 的文章 Swift 4.0: Codable。 之后有读者DevHank 提了个问题:

迅速的在 Playgrounds 上面下写了一个例子:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

class Father: Codable {
    var familyName: String = ""
}
class Son: Father {
    var name: String = ""  
}
let jsonText = """
{
    "familyName": "F",
    "name": "N"
}
"""
let data = jsonText.data(using: .utf8)!
do {
    let son: Son = try JSONDecoder().decode(Son.self, from: data)
    print(son.familyName)
} catch let error {
    print(error)
}
// F

我以为事情就算结束了。后来实在是有些不妥, 然后在代码中添加

1

print(son.name)

发现出了问题。所以尝试让子类遵守 Codable 协议。 两个类的代码改成了这样

从字面意思上看，通过字符串字面意思表达。这是一个协议, 就是说实现这个协议可以通过字面意思实例化这个类。

我们查看 String 这个类, Swift 实际上已经给 String 这个类实现了 ExpressibleByStringLiteral 这个协议。所以可以通过

1

let aString = "this is a string"

来初始化一个 String 对象。通过查看文档：

这个协议已经被

• CSLocalizedString
• StaticString
• NSMutableString
• String
• NSString
• SubString
• Selector

这几个东西实现了。

这个协议有什么用呢？其实我们可以通过实现这个协议，来帮助我们更简单的初始化一些东西。比如说: URL。

在实际开发中, 每次初始化一个 URL 都需要

1

let urls = URL.init(string: "https://www.baidu.com")

这样来初始化一个 URL 出来， 这个初始化出来的 URL 又是一个 optional 的，在使用的使用还需要给他解包什么的。但是每次都要这样实在是很烦。所以我们可以通过这个协议来简化这个过程。

1
2
3
4
5
6
7
8

extension URL: ExpressibleByStringLiteral {
    
public init(stringLiteral value: String) {
	guard let url = URL(string: "\(value)") else {
		preconditionFailure("This url: \(value) is not invalid")
	}
	self = url
}

iOS 7 之后苹果给 UIViewController 引入了 topLayoutGuide 和 bottomLayoutGuide 两个属性来描述不希望被透明的状态栏或者导航栏遮挡的最高位置(status bar, navigation bar, toolbar, tab bar 等)。这个属性的值是一个 length 属性( topLayoutGuide.length)。 这个值可能由当前的 ViewController 或者 NavigationController 或者 TabbarController 决定。

• 一个独立的ViewController，不包含于任何其他的ViewController。如果状态栏可见，topLayoutGuide表示状态栏的底部，否则表示这个ViewController的上边缘。
• 包含于其他ViewController的ViewController不对这个属性起决定作用，而是由容器ViewController决定这个属性的含义：
  • 如果导航栏（Navigation Bar）可见，topLayoutGuide表示导航栏的底部。
  • 如果状态栏可见，topLayoutGuide表示状态栏的底部。
  • 如果都不可见，表示ViewController的上边缘。
    这部分还比较好理解，总之是屏幕上方任何遮挡内容的栏的最底部。

iOS 11 开始弃用了这两个属性， 并且引入了 Safe Area 这个概念。苹果建议: 不要把 Control 放在 Safe Area 之外的地方

1
2
3
4
5
6

// These objects may be used as layout items in the NSLayoutConstraint API
@available(iOS, introduced: 7.0, deprecated: 11.0)
open var topLayoutGuide: UILayoutSupport { get }
@available(iOS, introduced: 7.0, deprecated: 11.0)
open var bottomLayoutGuide: UILayoutSupport { get }

今天, 来研究一下 iOS 11 中新引入的这个 API。

范型可以说是 Swift 跟 OC 相比最大的优势了。通过给像集合这类东西关联范型, 可以写出更可预测并且更安全的代码。在 Swift4 中类型约束更为强大， 它能够让我们更能够轻而易举的做很多事情。即使是通用代码, 也能充分的利用 Swift 的类型系统。

例1:

首先我们来看看一个简单的例子。比如说给一个数字数字求和。我们可能会些这样的代码:

1
2
3
4
5
6

// 在这段代码中, 我们定义了一个方法, 接受一个 Int 数组作为参数, 在方法内部使用高阶函数 reduce 最后返回这个结果。
func sum(_ numbers: [Int]) -> Int {
    return numbers.reduce(0, +)
}
let array = [1,2,3,4,5]
sum(array) // 15

使用范型约束, 我们可以这样来实现这个需求:

1
2
3
4
5
6
7

// 在这段代码中, 我们给 Array 添加了类型约束的 Extension。当数组的 Element 遵守了 Numeric 协议的时候, Array 就拥有 sum 这个方法。
extension Array where Element: Numeric {
    func sum() -> Element {
        return reduce(0, +)
    }
}
array.sum() // 15

两者相比, 使用范型约束最大的优势是使用扩展, 能够让这个功能跟调用者更紧密。比较一下:

1
2

let sum = sum(array)
let sum = array.sum()

在 OC 里面， 可能有些同学会写一个 XXXTool 之类的类, 来封装这种类型的功能。 或者是直接写成 C 的函数。但是不论怎么写, 这样貌似都不是特别的 OOP。或者OC 还可以直接给 NSArray 加一个 category, 然后再实现相似的功能。但是, 这样做不就等于所有的 array 都具有这个功能了吗？

在现在这家公司带了一段时间了，发现了很多因为流程的不完善, 各个流程之间的衔接的不顺畅带来的”浪费”。加上之前有过的敏捷开发的经验, 和看过的一些想过的资料。又在微信读书上看了《敏捷革命》这本书, 才发现敏捷开发原来是一门非常厉害的学问。在看书的过程中就想着自己总结写一个类似于“破.守.离(先学习规则和形式, 掌握之后再进行创新。最后再特别熟悉的状态下，就可以摆脱形式的束缚，随性发挥。因为一切都已烂熟于心。几乎可以在下意识的状态下做出决定。)”的东西。看到最后就看到了这么一段。

国庆来了一次说走就走，除了开车很累，还有轻微的高原反应，一切都很好。

一次旅行，还是想到了很多…

6 Months of Working Remotely Taught Me a Thing or Ten这篇文章是我在 Twitter 上看到的, 作者自身具有半年的远程开发经历。作为一种还算比较新的团队合作方式, 远程办公这种形式对自身以及团队都有着比较高的要求。我本身对这样的工作方式也非常向往(虽然在目前看来不大可能实现)，但是还是希望能够学到更多有用的东西…

WWDC2017中发布的 Swift4.0 有一个有趣的新特性： Coadble. 今天我们就来聊聊这个 Swift4.0 带来的协议！

Serialization

对现在需要随时联网的移动应用来说，把值序列化成能够在硬盘或者通过网络传送的数据是一个基本的需求。但是在苹果的生态中我们的选择很有限。

相信大家都有过重写 dealloc 方法来检查某个 view controller 在消失后是否被释放的经历。这几乎是 iOS 中寻找由于引用循环造成内存泄漏最有效的方法了。基本上每次发布，都会做很多次这种事情。不得不说这件事情很无聊，并且很可能会出错。如果我们在日常的开发中, 提前的学习相关的知识, 那该多好？

不论是在一些大型的开发团队，还是作为独立开发者。我们经常会被预算、技术迭代，以及时间限制。找到合适的工作方式去适应这些限制, 是所有团队都需要去考虑的问题。

Alex Andrews 在成立 Ten Kettles 的时候花了很多了精力去考虑这个问题。直到有一天上帝把敏捷开发砸到了他的头上，很快他就找到了适合他的敏捷开发之道。他认为敏捷开发极大的解放了他的生产力。

这篇文章就会聊到他是怎么进行敏捷开发的。

随着 app 的发展， MVC 渐渐的满足不了业务的需求。大家都在探索各种各样的架构模式来适应这种情况，像是MVVM、VIPER、Riblets 等等。 他们都有各自的特点，但是都有同一个核心: 通过多向数据流将代码按照单一职责原则来划分代码。在多向数据流中，数据在各个模块中传递。

多向数据流并不一定是你想要的，反而，单向数据流才是我们更喜欢的数据传递方式。在这个 ReSwift 的教程中，你会学到如何使用 ReSwift 来实现单向数据流，并完成一个状态驱动的游戏——MemoryTunes

Share Extension 使用户在使用其他的app 的时候, 更加方便的将其内容分享出去，像是社会化分享还有上传服务器。比如说， 在一个 app 中有个分享按钮， 用户可以选择其中一个 Share Extension 来发表评论或者内容。