RxSwift:ReactiveX for Swift 翻译
RxSwift:ReactiveX for Swift 翻译
RxSwift
|
|-LICENSE.md
|-README.md
|-RxSwift --- 平台核心
|-RxCocoa --- 对UI,NSURLSession,KVO...的扩展
|-RxBlocking --- block 操作符集合，仅用于单元测试
|-RxExample ---
|-Rx.xcworkspace --- 包含所有project的workspace
闲来逛逛哦rxswift.slace.com
1. Why
写出稳定而又快速的代码是何其的难，这个过程中有许多坑，这些坑足以让你毁了你的所有的辛勤付出。
State 状态
允许修改的语言很容易访问全局状态并修改它，未受控制的状态的修改很可能会导致程序的混乱崩溃(combinatorial explosion),但是从另一方面来说，强类型语言能都写出更高效的代码，这中方式就是尽可能地保持状态简单，并使用单项数据流来模型化数据，这就是Rx的闪光处
Bindings 绑定
当你写UI app的时候，理想情况就是用户界面可以随着状态的改变而改变，并且不会出现不一致的情况，这就是所谓的binding。
observable.combineLatest(firstName.rx_text,lastName.rx_text) { $0 + " " + $1 }
.map { "Greeting \\($0)" }
.bindTo(greetingLabel.rx_text)
官方建议使用
.adddisposableTo(disposeBag)即使对于简单地bindings 来说这并不是必要的
Retries
我们很期望APIs 不会失败，但是这并不能如我们所愿，下面我们就来看一个：
func doSomethingIncredible(forWho: String) throws -> IncredibleThing
这个函数如果执行失败很难再次retry，即使是retry了，这也会产生很多的transient states，这并不是我们想要的，Rx 实现起来就很简单
doSomethingIncredible("me")
.retry(3)
Transient State
在写 async 程序的时候会有许多的 瞬态问题，最典型的就是输入框的自动搜索，先输入ab ,发送一次请求，再输入c,又会发送一次请求，之前的请求可能需要cancel掉，或者使用另外一个变量引用。
另外一个问题就是，如果请求失败，就需要大量的retry 逻辑处理,如果成功，之前的retry 也需要清理。
如果我们在触发请求之前能有一丢丢时间的间隔，那就会非常完美，毕竟有些输入操作需要较长的时间。
还有一个问题就是在搜索请求执行过程中，屏幕上显示啥呢？失败了，又要显示啥？(公司产品要求，你懂得，处理起来极其繁琐)，下面就是Rx 大展拳脚的时候了
searchTextField.rx_text
.throttle(0.3, scheduler: MainScheduler.instance)
.distinctUntilChanged()
.flatMapLatest { query in
API.getSearchResults(query)
.retry(3)
.startWith([]) // clears results on new search term
.catchErrorJustReturn([])
}
.subscribeNext { results in
// bind to ui
}
throttle 节流，在设定的时间内多次发送请求，仅仅触发最后一次
distinctUntilChanged 求异去同，比较前后两个值，如果相同则不会触发，不同则触发
startWith 开始设定的值，可以认为是占位符或者placeHolder
整合网络请求
你想一同发送两个请求，当两个请求都成功后，将两者的结果整合起来处理，这... 好伤脑筋啊！！！
没关系，zip 帮你实现
let userRequest: Observable<User> = API.getUser("me")
let friendsRequest: Observable<Friends> = API.getFriends("me")
Observable.zip(userRequest, friendsRequest) { user, friends in
return (user, friends)
}
.subscribeNext { user, friends in
// bind them to user interface
}
zip 将两个信号合并成一个信号，并压缩成一个元组返回，前提是两个信号均成功
还有个问题是，这些请求是在后台，绑定还没有在主线程发生，这就要用到observeOn
let userRequest: Observable<User> = API.getUser("me")
let friendsRequest: Observable<[Friend]> = API.getFriends("me")
Observable.zip(userRequest, friendsRequest) { user, friends in
return (user, friends)
}
.observeOn(MainScheduler.instance)
.subscribeNext { user, friends in
// bind them to user interface
}
轻松整合RX
实现自己的observable,那真是太简单了，(so easy，老板再也不担心我写不出代码了)
extension NSURLSession {
public func rx_response(request: NSURLRequest) -> Observable<(NSData, NSURLResponse)> {
return Observable.create { observer in
let task = self.dataTaskWithRequest(request) { (data, response, error) in
guard let response = response, data = data else {
observer.on(.Error(error ?? RxCocoaURLError.Unknown))
return
}
guard let httpResponse = response as? NSHTTPURLResponse else {
observer.on(.Error(RxCocoaURLError.NonHTTPResponse(response: response)))
return
}
observer.on(.Next(data, httpResponse))
observer.on(.Completed)
}
task.resume()
return AnonymousDisposable {
task.cancel()
}
}
}
}
综合处理 (Compositional disposal)
设想一下几个场景： 在tableView上展示一个模糊的image，这个image首先需要获取，然后解码，然后模糊处理
- 在cell 退出了可显示区域，整个操作可以取消
- 当用户快速滑动cell,cell 进入可现实区域，不会立刻去获取image。cell仅仅是昙花一现,这需要发送很多的request 和 cancel 操作。
- 我们可以限制并发数量
以上场景如果可以优化并满足要求，改多好，是吧 !
让我们看看 Rx是怎么做的
// this is conceptual solution
let imageSubscription = imageURLs
.throttle(0.2, scheduler: MainScheduler.instance)
.flatMapLatest { imageURL in
API.fetchImage(imageURL)
}
.observeOn(operationScheduler)
.map { imageData in
return decodeAndBlurImage(imageData)
}
.observeOn(MainScheduler.instance)
.subscribeNext { blurredImage in
imageView.image = blurredImage
}
.addDisposableTo(reuseDisposeBag)
代理(Delegates)
代理一般用于回调和作为一种观察机制。
传统的delegate 在设置setter 方法时，不会触发初始值，因此你需要通过其他的途径来读取初始值。
RxCocoa 不仅提供了UIKit Class的封装，而且还提供了一套通用机制-DelegateProxy,使你能够封装你自己的 delegate 并作为可观察的Sequence 暴漏出来。
来看一下整合后的UISearchbar
It uses delegate as a notification mechanism to create an Observable<String> that immediately returns current search text upon subscription, and then emits changed search values.
extension UISearchBar {
public var rx_delegate: DelegateProxy {
return proxyForObject(RxSearchBarDelegateProxy.self, self)
}
public var rx_text: Observable<String> {
return defer { [weak self] in
let text = self?.text ?? ""
return self?.rx_delegate.observe("searchBar:textDidChange:") ?? empty()
.map { a in // a 包含了searchbar:textDidChange:的参数，第一个是Searchbar,第二个是值
return a[1] as? String ?? ""
}
.startWith(text)
}
}
}
RxSearchBarDelegateProxy 可在这里找到 here
下面是该API的使用
searchBar.rx_text
.subscribeNext { searchText in
print("Current search text '\\(searchText)'")
}
通知 (Notificatioins)
通知可以注册过个观察者，但是他们也是未知类型的，值需要从userInfo中提取。
冗余的形式：
let initialText = object.text
doSomething(initialText)
// ....
func controlTextDidChange(notification: NSNotification) {
doSomething(object.text)
}
你可以使用rx_notification 来创建一个观察序列，减少逻辑和重复代码的散播。
let subscription = notificationCenter.rx_notification("testNotification", object: targetObject)
.subscribeNext { n in
numberOfNotifications += 1
}
KVO
KVO 是一个很方便的观察机制，但是也不是没有缺点，他最大的缺点就是让人模糊的内存管理。
在观察一个对象的一个属性时，该对象必须要比注册的KVO observer 活的时间长，都则会遇到crash
`TickTock` was deallocated while key value observers were still registered with it. Observation info was leaked, and may even become mistakenly attached to some other object.
另外还有一套规则你还得遵守，否则结果有可能很诡异。还的实现一个笨拙的方法
-(void)observeValueForKeyPath:(NSString *)keyPath
ofObject:(id)object
change:(NSDictionary *)change
context:(void *)context
RxCocoa提供了一套很方便的观察序列--rx_observe 和 rx_observeWeakly
使用方法：
view.rx_observe(CGRect.self, "frame")
.subscribeNext { (frame: CGRect?) in
print("Got new frame \\(frame)")
}
or
someSuspiciousViewController.rx_observeWeakly(Bool.self, "behavingOk")
.subscribeNext { (behavingOk: Bool?) in
print("Cats can purr? \\(behavingOk)")
}
(翻译拙劣,如有问题,欢迎留言)
