Swift开发的几个小技巧

移动开发 iOS
正所谓掌握一样技术最好的办法就是用它来做一个东西,于是这段时间的实战让我对 Swift 的理解更深了一层,也积累了一些使用技巧。今天就分享一则:如何正确地定义一个类变量(和类常量)。

正所谓掌握一样技术***的办法就是用它来做一个东西,于是这段时间的实战让我对 Swift 的理解更深了一层,也积累了一些使用技巧。今天就分享一则:如何正确地定义一个类变量(和类常量)。

Swift 语言对于无论是静态语言过来还是动态语言过来的开发者来说,都有点点不适应,很多问题的解决思路不能用已经习以为常的方法去做。

如何正确的定义一个类变量(和类常量)

Swift 支持用 class func 来修饰一个「类方法」,然而却不能用「class var」和「class let」来指定类变量和类常量,一旦你尝试这样做了,那么 Xcode 会提示你:Class variable not yet supported。真是遗憾…

不过从这个提示可以看出,Class variable 的支持只是时间问题。那么现阶段我们要怎么完成这一目标?总不能用丑陋的 Workaround 吧。办法还是有的,我从 Apple 官方的例子中学到了如何去定义一个类级的常量和变量,那就是用 struct。

来个 demo 你就明白了:

  1. class MyClass {  
  2.      struct Constants {  
  3.          static let name = "MyClass"  
  4.      }  
  5.      struct Variables {  
  6.          static var age = 0  
  7.      }  
  8.  } 

然后在调用的时候,就可以这样来调用: MyClass.Constants.name 和 MyClass.Variables.age

虽 然中间还隔了一层 Constants 和 Variables,但是我觉得这样也挺好,相当于有了一个 Prefix,直接看代码时就知道是常量还是变量了。如果你不喜欢这种方式,也可以用 computed property 的形式来模拟真实的类变量(常量)的调用。比如:

  1. extension MyClass {  
  2.     class var name: String { 
  3.        get { 
  4.            return Constants.name 
  5.        } 
  6.     } 
  7.     class var age: Int { 
  8.         get { 
  9.             return Variables.age 
  10.         } 
  11.         set { 
  12.             Variables.age = newValue 
  13.         } 
  14.     }  
  15.  } 

定义了这种方式后,就可以直接用 MyClass.name 和 MyClass.age 来访问类常量或修改类变量了。

这种方式在语法上兼容了未来会得到支持的类变量和类常量,但就是自己要写一大堆 getter 和 setter,有点麻烦,大家可以根据自己的需要决定是不是要采用这种方式。

关于本文的 demo 代码,大家可以粘贴进「swift」这个命令行工具来实践一下。效果正如我们想要的那样,常量不允许修改,变量可以修改,所有的这些操作都是在 MyClass 上进行,而不需要实例化。

虽然现在用 Swift 来做一些常用的任务还略显麻烦,不过作为一个年轻的语言,目前它确实已经能用在生产环境中写出真正可用的 App 了,随着接下去的发展,我相信它会变得越来越好的。

PS:现在我只想 SourceKitService 崩溃的少一点…

用Optional来避免异常指针问题

最近在用 Swift 开发的过程中,又碰到了一个问题。简单的说,系统在该返回非 nil 值的地方返回了一个异常指针(即指向 0x0000 地址,产生 KERN_INVALID_ADDRESS 异常)造成了 App 的 crash,算是 iOS UIKit 的一个 Bug。

这个问题需要 SDK 的升级来解决,但是在 SDK 升级之前,我们可以通过一个小小的 Workaround 去解决。来龙去脉是这样的:

iOS 的 Swift 版的 API 与 Objective-C 的 API ***的不同是,你需要看 Objective-C 的 API 文档才知道一个系统返回的值是不是可能是 nil。

比如 UIDataSourceModelAssociation 这个用来还原 UITableView 和 UICollectionView 位置的 Protocol,它有两个方法,其中一个是:

  1. 1 
  2.      
  3. - (NSString *)modelIdentifierForElementAtIndexPath:(NSIndexPath *)idx inView:(UIView *)view 
  4.  
  5. 光看 Objective-C 这个方法,你是不知道系统返回的 idx 有没有可能是 nil 的,但是一看 Swift 版本,就非常显然了: 
  6. 1 
  7.      
  8. func modelIdentifierForElementAtIndexPath(_ idx: NSIndexPath, inView view: UIView) -> String 
  9.  
  10. idx 和 inView 一样,都没有 ? 和 !,因而它们不是 Optional,所以值不可能是 nil。如果 idx 和 inView 可能是 nil 的,那么它应该是用 ! 来修饰,以警告开发者,这个值可能是 nil,请小心使用。 
  11. 1 
  12.      
  13. func modelIdentifierForElementAtIndexPath(_ idx: NSIndexPath!, inView view: UIView!) 

Swift 这种比 Objective-C 更彻底的 API 即文档的表达形式,我在编码一段时间后非常喜欢。

然而,也正是系统的框架还进化的不彻底的原因,这些 API 依然可能会返回 nil 的值,但是 API 因为被标记不会返回 nil,于是就会发生 swift_dynamicCastClassUnconditional 的异常,***导致 App crash。

下图即是 modelIdentifierForElementAtIndexPath 这个方法在应该返回值的情况下,却返回了一个指向 0x0000000000000000 的对象。然后 Swift 在包装值的时候,没能包装成功而发生 crash。

 

那么如何避免因为这个问题造成的 App crash 呢?实际上很简单,只需要手动用 Optional 包装一下这个 0x0000 对象,再判断它是不是 nil,就不会发生问题了。比如这样的代码:

  1. let optionalIdx = Optional(idx) 
  2. if optionalIdx == nil { 
  3.     return "Do something" 

刚开始遇到这个问题我也很苦恼,后来突然想到,是不是可以用 Optional 去包装一下这种异常指针再检查是不是 nil,一试果然可以。于是问题就这样解决了。

幸好,这种坑没有多到让我抓狂的步地,我能继续用 Swift 愉快的写下去了…

如何用 Swift 思维设计网络请求

近来在用 Swift 开发 App 的过程中,***的心得就是:我开始渐渐用「Swift 思维」来思考了。回顾刚开始我用 Swift 时,只是套用它的语法而已,脑子里依然是 Objective-C 思维。

这段时间,随着对 Swift 基本特性的掌握,我开始有意识地学习并尝试一些 Swift 才有的特性,此谓「Swift 思维」。Swift 有很多专有(Objective-C 没有的)的模式,今天我就从一个很简单的例子讲起,那就是:

如何用 Swift 思维设计网络请求。

做过网络类应用的同学应该都知道,我们做一个网络请求时,通常会有两个结果:一个是失败,返回错误,一个是成功,返回结果。当然途中还会有更复杂的情况,比如:1、网络请求本身的失败(比如网络超时);2、API 端返回的内部结果型失败(比如密码不正确)。这里我们就不细分了。

在传统的 Objective-C 的项目里,有几种处理这种异常的情况,主要是:

直接判断 NSError

  1. NSError *error = nil; 
  2. id result = [API doSomething:&error]; 
  3. if (error != nil) { 
  4.    NSLog("Oh Error!"

这种处理太直白,一般会阻塞当前的线程,因而不推荐。一般用的比较多的是下面两种:

通过 success,failture 的 block 来处理

  1. [API doSomethingWithSuccess:^(id result) { 
  2.     NSLog(@"Seems good"
  3. } failure:^(NSError *error) { 
  4.     NSLog(@"Oh Error!"
  5. }]; 

这种就相对好点了,通过 Block 及内部实现,可以做到不阻塞当前线程,在有结果的时候再进行处理。在对应的 Block 处理对应的情况:成功 or 失败。 不过这个设计依然还有一点缺陷,因为它对结果的处理分散在不同的 Block,如果我需要统一处理无论成功或失败的情况,那么需要分别调用,不是太直观了。所以,我们还有第三种模式。

通过统一的 completionHander 的 block 来处理

  1. [API doSomethingWithCompletionHandler:^(id result, NSError *error) { 
  2.     if result != nil { 
  3.         NSLog(@"Seems good"
  4.     } 
  5.     if error != nil { 
  6.         NSLog(@"Oh Error!"
  7.     } 
  8. }]; 

这种通过 CompletionHandler 来统一作成功结果和错误失败的处理应该是现在设计的首先,包括系统自己的 API 也是这样设计的。特别适合在一个 Block 里就把所有情况处理掉的需求。

Swift 式网络请求处理

简单列举了三种 Objective-C 下常见的网络请求类处理方式,看起来还不错,那么 Swift 模式是什么样的,能做好更好吗?我觉得是的。

Swift 里有着非常棒的 enum 机制,所有的枚举情况不但可以是任何类型,而且可以是不一样的类型。这意味着,我们在 Swift 里可以包装一种结果型 enum,比如:

  1. enum Result { 
  2.     case Error(NSError) 
  3.     case Value(JSON) 
  4.     init(_ e: NSError?, _ v: JSON) { 
  5.         if let ex = e { 
  6.             self = Result.Error(ex) 
  7.         } else { 
  8.             self = Result.Value(v) 
  9.         } 
  10.     } 

这段是我真实世界的代码,用在了我的微博客户端里。

代码很简单,我定义了一个名为「Result」的 enum 对象,它会包装两种情况,一种是 Value,在网络请求成功时,它就是一个 JSON 值;第二种时 Error,是一个 NSError 值,在网络请求失败时,包含着具体的错误信息。

这样,就成功地把一个网络请求下的可能的两种情况包装在了一个 Result 对象里,这个对象,要么是成功的结果,要么就是失败的错误,永远不会有同时有结果和错误。于是,我们的网络请求处理代码可以更为简单的设计成这样:

  1. API.doSomethingWithCompletionHandler({ (result) -> Void in 
  2.     switch (result) { 
  3.     case let .Error(e): 
  4.         NSLog("Oh Error!"
  5.     case let .Value(json): 
  6.         NSLog("Seems good"
  7.     } 
  8. }) 

看起来似乎和前面 Objective-C 的第二种模式一样?似乎又像第三种?估且称之为混合模式吧。让我来简单说说这种模式有什么好处:

首先,我们通过 Switch 条件判断这种非此即彼的模式,我们可以减少很多错误的发生,保证条件分支判断不会出问题;其次,我们依然只是在一个 Closure (这里换成 Swift 术语,而不是 Objective-C 的 Block)处理我们的一个请求结果 result,因而可以在前前后后做些其他对结果的统一处理,保证我们逻辑的统一性。

这就是我所认为的 Swift 这种模式的好处了。

通过这种模式改造我的项目后,我觉得代码变得更整洁、逻辑清晰,也不会有遗失的错误处理情况。当然我做采用的还只是简化版的 Swift 模式网络处理,更为强大的例子大家可以参考 swiftz 项目的 Result 对象,它使用了 Swift 的 Generic 特性,从而使其可以包装任意值(不仅仅是 JSON),从而大大增强了扩展性:https://github.com/typelift/swiftz/blob/master/swiftz_core/swiftz_core/Result.swift#L12

我依然还在用 Swift 思维改造项目的过程中,目前这种模式应该还是有改进余地的,希望能和大家做更多有关这个的讨论与交流。

责任编辑:chenqingxiang 来源: cocoachina
相关推荐

2011-01-19 09:07:20

Thunderbird

2020-08-26 13:10:03

微信小程序前端代码

2022-11-16 09:04:36

SQL查询SELECT

2022-08-18 10:01:35

Jmeter技巧

2022-06-07 23:28:05

线程安全后端

2011-06-13 17:36:43

外链

2011-07-05 14:59:17

java

2023-04-12 08:18:40

ChatGLM避坑微调模型

2022-03-21 21:05:40

TypeScript语言API

2018-11-13 15:50:41

干货Java源码

2009-06-17 15:38:57

java软件安装

2022-04-27 20:52:48

JSChrome元素

2022-07-18 08:08:16

Go​语言技巧

2021-11-29 11:11:45

SQL查询技巧

2020-07-22 15:15:28

Vue前端代码

2011-02-21 17:15:14

SilverlightNEY

2009-07-31 16:23:00

linux cd命令cd命令技巧

2011-07-28 20:22:17

2009-10-09 10:21:31

Visual Stud

2016-12-28 13:19:08

Android开发坑和小技巧
点赞
收藏

51CTO技术栈公众号