Swift, ReactiveCocoa第一个app
引言这篇文章将纪录用Swift语言配合ReactiveCocoa写一个伪搜索引擎app的历程。 ReactiveCocoa简介（翻译自RayWenderlich.com，有改动）作为iOS开发者，我们写的每一行代码几乎都是在和“事件”打交道，例如用户点击了一个按钮，网络上发来一条信息，一个属性值的变化(Key Value Observation)，或者是用户的位置改变了。但是，CocoaTouch把这些事件以不同的格式封装在了一起，例如target-action,delegate,KVO,回调之类的。这就给开发带来了很大的麻烦，降低了代码的可读性，随之而来的就是更多的维护成本和更多的bug。ReactiveCocoa把这一切封装到了一个标准的接口中，这样它们就可以很容易地被组合、过滤。 ReactiveCocoa把函数式编程和响应式编程组合在了一起。
因为这个原因，ReactiveCocoa也被称为是一个函数响应式编程框架。 这里就不再在学术上深究了，打开Xcode吧！ 程序结构设计程序最终运行的效果如下： 当用户在文本框中输入长度大于4的文本时，下方的列表就会显示和用户输入字符长度相同的“搜索结果”（为了保持简单，这里就直接生成了一些字符串，而不是去调用搜索引擎的API）。并且只有当用户的输入在0.5秒中没有变化时，动作才会被触发。由于非常简单，不考虑错误处理。由于真正的Web API需要访问网络，引发异步事件，这个程序如果使用普通的方法将具有相当的复杂性。 程序内部将采用管道式，数据流经过管道之后最终将被一个UITableView显示。由于Swift中变量绑定的问题，程序并未采用MVVM设计模式，代码中的ViewModel只是一个保存数据的容器。（未来将会改进为MVVM模式） 那么就 开始吧！第一步建立一个iOS工程，类型是Single View Application，设备选择iPhone（方便UI设计），语言选择swift 安装ReactiveCocoaReactiveCocoa官方推荐使用Carthage安装。（当然CocoaPod用不了，原因你懂的）Carthage安装外部库的操作非常简单：
设计UI，编写Table View的代码UITableView是UIKit中操作较为复杂的一个，但这个特性也让它可以不需要绑定就直接使用ReactiveCocoa的特性，因此在这里选用它来做介绍。 首先打开Main.storyboard，向场景中拖入一个Text Field。设置AutoLayout：左20，右20，上0。再拖入一个Table View，放在Text Field下方，设置AutoLayout：左20，右20，下20，上8。再拖入一个Table View Cell放在Table View里面，拖入一个Label放在Cell里面，设置AutoLayout：竖直居中，左50。整个场景看上去应该像这样： 之后，在StoryBoard中设置Cell的identifier为ResultCell。我们将在之后编写完Cell的代码之后改变这个Cell的其他属性。如图： 接下来我们就来编写Table View的代码。 首先是Cell：
这样，Cell的就定义好了。这可以被很容易地改为更复杂的情形。 之后是Table View本身的代码。UITableView采用了Data Source - Update的模式。这种模式的实现需要一个Data Source。 struct MainViewModel {
var resultCount: Int!
var results: [String]!
static func isValidSearchString(text text: String) -> Bool {
return text.characters.count > 4
}
static func produceSearchResult(text text: String) -> [String] {
return (1...text.characters.count).map {
i in
return "somebody (i)"
}
}
}
这里定义了封装数据的格式，并提供了两个辅助函数。 之后新建一个swift文件，命名为ResultViewController.swift，加入以下代码： import UIKit
class LFResultViewController: NSObject,UITableViewDataSource {
var viewModel = MainViewModel()
@objc func tableView(tableView: UITableView,numberOfRowsInSection section: Int) -> Int {
return viewModel.resultCount
}
func tableView(tableView: UITableView,cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
var cellRetired = tableView.dequeueReusableCellWithIdentifier(LFTableViewCell.identifier) as? LFTableViewCell
if cellRetired == nil {
cellRetired = LFTableViewCell(style: .Default,reuseIdentifier: LFTableViewCell.identifier)
cellRetired?.outputLabel = UILabel()
}
cellRetired?.outputLabel.text = self.viewModel.results[indexPath.row]
return cellRetired!
}
}
这里实现了Table View更新时需要的数据的方法。具体的关于 构建管道这里先贴出ViewController.swift中其他部分代码： import UIKit
import ReactiveCocoa
class ViewController: UIViewController {
@IBOutlet weak var outputTableView: UITableView!
@IBOutlet weak var searchTextInput: UITextField!
var resultViewController = LFResultViewController()
override func viewDidLoad() {
super.viewDidLoad()
self.resultViewController.viewModel.resultCount = 0
self.resultViewController.viewModel.results = []
self.outputTableView.dataSource = self.resultViewController
self.outputTableView.reloadData()
}
}
最关键的部分开始了！ let searchText = searchTextInput.rac_textSignal()
.toSignalProducer()
.map {text in text as! String}
map函数把一个集合类型（Array例如）中的元素逐一操作，并返回新的元素构成的集合类型。用Array举例可以清楚地解释这一切。（不恰当地说，你可以把SignalProducer当成一个Array，startWithNext就相当于for-in） [1,2,3,4].map {$0 * 2} //[2,4,6,8]
这里把一个RACSignal转化成了一个SignalProducer，并且这个是有类型检查的。为了更好地使用类型检查，我们把原本的 searchText.filter(MainViewModel.isValidSearchString) 还是用Array举例说明： [1,4].filter {$0 % 2 == 0} //[2,4]
这样，我们就用之前定义的过滤函数来检查字符串是否是合法的搜索字符串。这个方法输出的还是一个 .throttle(0.5,onScheduler: QueueScheduler.mainQueueScheduler) 注意前面的点。我们事实上是在调用上一步结果的一个方法。这就是Monad的特点：流畅接口。每一步都会构造一个对象，下一步调用它的方法。Xcode似乎并不喜欢Monad结构，缩进做得很差。Xcode 8和Xcode Extension或许可以解决这个问题，但是现在还得手工格式化。还有swift编译器在处理链式调用时会出现一些问题，最常见的是报错：Expression too complex to be resolved in reasonable time. 这种时候只需要在链式调用的每个点之前换一行就可以了。这也是推荐的用法。 接下来是传统方法最费力一部分了：异步请求。(Accept the fact that we are living in a asynchronous world)所幸ReactiveCocoa提供了一个良好的方法来解决这个问题：把它们包装成SignalProducer。但是我们在这里遇到一个问题：如果用map并且返回一个SignalProducer，我们将会在下一步得到一个SignalProducer<SignalProducer<([String],Int),NoError>,NoError>。这显然不是我们想要的。这里就要介绍flatMap函数了。先看Array的举例： [1,4].map {[$0]} //[[1],[2],[3],[4]]
[1,4].flatMap {[$0]} //[1,4]
也就是说，flatMap方法会自动“剥掉一层”。加上代码： .flatMap(.Latest) {
(text: String) in
return SignalProducer {
(o: Observer<([String],c: CompositeDisposable) in
let rst = MainViewModel.produceSearchResult(text: text)
let cnt = rst.count
o.sendNext((rst,cnt))
o.sendCompleted()
}
}
通过这个flatMap，我们把原来的SignalProducer<String,NSError>转化成了SignalProducer<([String],NoError>。（注意使用NoError类型需要包含Result框架） 现在，我们有了“搜索结果”，可以去显示了。 .observeOn(UIScheduler())
.startWithNext {
[weak self] (x: ([String],Int)) in
if let strong = self {
strong.resultViewController.viewModel.resultCount = x.1
strong.resultViewController.viewModel.results = x.0
strong.outputTableView.reloadData()
}
}
这里有两个要说明的地方：一是在iOS上只有主线程可以更新UI，因此我们需要借助UIScheduler来把工作转移到主线程。还有为了避免循环引用，我们需要声明一个 override func viewDidLoad() {
super.viewDidLoad()
self.resultViewController.viewModel.resultCount = 0
self.resultViewController.viewModel.results = []
self.outputTableView.dataSource = self.resultViewController
self.outputTableView.reloadData()
let searchText = searchTextInput.rac_textSignal()
.toSignalProducer()
.map {text in text as! String}
searchText.filter(MainViewModel.isValidSearchString)
.throttle(0.5,onScheduler: QueueScheduler.mainQueueScheduler)
.flatMap(.Latest) {
(text: String) in
return SignalProducer {
(o: Observer<([String],cnt))
o.sendCompleted()
}
}
.observeOn(UIScheduler())
.startWithNext {
[weak self] (x: ([String],Int)) in
if let strong = self {
strong.resultViewController.viewModel.resultCount = x.1
strong.resultViewController.viewModel.results = x.0
strong.outputTableView.reloadData()
}
}
}
编译运行，程序如预期执行。 写在后面ReactiveCocoa代表了一种全新的方式。它的核心就在于：“高聚合 低耦合” 同时具有强大的异步处理能力。Forget dispatch_async,let's startWithNext. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |