ReactiveCocoa代碼實踐之-RAC網絡請求重構
前言
- RAC相比以往的開發模式主要有如下優勢：提供了統一的消息傳遞機制；提供了多種奇妙且高效的信號操做方法；配合MVVM設計模式和RAC宏綁定減小多端依賴。
- RAC的理論知識很是深厚，包含有FRP，高階函數，冷信號與熱信號，RAC Operation，信號的生命週期等，這些文檔裏都有介紹。 可是因爲RAC自己的特性，可能會聽上去容易上手難。
- 本文仍是從一個比較接地氣的角度開始的。由於如今要作一個完美100%的全項目ReactiveCocoa架構基本不太現實，大多數項目都會有不少歷史包袱，咱們只能漸漸的向RAC靠攏，將一段段噁心的代碼重構，使邏輯功能更加清晰。
本節主要我以前對網絡請求的重構的一個簡單記錄。git
一.普通請求重構
舊代碼結構圖：github
以前的代碼控制器中都是一個個須要鏈接網絡的方法中直接調用service的請求方法並獲取回調，屬於常規作法。web
// controller.m ************************************
// 控制器中的某一處方法
- (void)requestForTop{
[MDSBezelActivityView activityViewForView:self.view withLabel:@"加載中..."];
// 直接調用service裏的請求方法
[SXFeedbackService requestForFeedbackSummarySuccess:^(NSDictionary *result) {
[MDSBezelActivityView removeView];
// 成功後相關處理
} failure:^(AFHTTPRequestOperation *operation, NSError *error) {
[MDSBezelActivityView removeView];
// 失敗後相關處理
}];
}
重構後結構圖： 設計模式
使用RAC改寫後，controller不會直接調用service，controller經過控制一個個command的執行與否來達到發請求的目的。獲得數據後綁定的值一旦發生改變，會來到RACObserve的回調方法。而且若是請求失敗，也會以錯誤信號的方式傳遞到execute的subscribeError回調方法裏。 executing能夠用來監聽命令是否執行完。數組
// controller.m ************************************
@property(nonatomic,strong)SXFeedbackMainViewModel *viewModel;
- (void)viewDidLoad{
[self addRACObserve];
}
// 在頁面初次加載時設置綁定
- (void)addRACObserve{
@weakify(self);
[[RACObserve(self.viewModel, topNumEntity) skip:1] subscribeNext:^(id x) {
@strongify(self);
// 綁定viewModel的值一旦改變來到這裏。
}];
}
// 本來用來發請求的地方
- (void)requestForTop
{
[[self.viewModel.fetchFeedbackSummaryCommand execute:nil] subscribeError:^(NSError *error) {
// 對錯誤的處理
}];
[[self.viewModel.fetchFeedbackSummaryCommand.executing skip:1] subscribeNext:^(NSNumber *executing) {
if ([executing boolValue]) {
[MDSBezelActivityView activityViewForView:self.view withLabel:@"加載中..."];
}else{
[MDSBezelActivityView removeView];
}
}];
}
// viewModel.m ************************************
- (instancetype)init
{
self = [super init];
[self setupRACCommand];
return self;
}
// 初始化設定一個指令用來打開某個請求
- (void) setupRACCommand
{
@weakify(self);
_fetchFeedbackSummaryCommand = [[RACCommand alloc] initWithSignalBlock:^RACSignal *(id input) {
return [RACSignal createSignal:^RACDisposable *(id<RACSubscriber> subscriber) {
// 這裏面更完全的方法是直接將請求寫成一個operation，可是大多數項目的網絡層應該都有manager或是簽名等緣由想直接改爲那種結構可能比較複雜 ，因此這裏面的代碼像是RAC和直接請求的結合。
[SXMerchantAutorityService requestForFeedbackSummarySuccess:^(NSDictionary *result) {
@strongify(self);
// 成功回調後作的相關操做
[subscriber sendCompleted];
} failure:^(AFHTTPRequestOperation *operation, NSError *error) {
[subscriber sendError:error];
}];
return nil;
}];
}];
}
二.須要傳參數的請求
上面是普通的請求，就是請求地址是寫死或者是從全局變量中拼接參數的。 若是須要傳入若干參數的話controller沒法直接接觸到service，因此須要以viewModel做爲媒介傳值，有兩種傳值方法。網絡
1.經過viewModel的屬性
這種方法可用於參數少，一個或兩個的。直接在viewModel里加上一些屬性，而後controller在適當的時候給這個屬性賦值。 在viewModel中的RACCommand中調用service方法須要參數時直接從本身的屬性取。架構
// controller.m ************************************
self.viewModel.isAccess = self.isAccess;
[self requestForTop];
// viewModel.h ************************************
// input參數
/**
* 是美團仍是點評
*/
@property(nonatomic, assign) BOOL isAccess;
// viewModel.m ************************************
_fetchFeedbackSummaryCommand = [[RACCommand alloc] initWithSignalBlock:^RACSignal *(id input) {
return [RACSignal createSignal:^RACDisposable *(id<RACSubscriber> subscriber) {
[SXMerchantAutorityService requestForFeedbackSummaryWithType:self.isAccess success:^(NSDictionary *result) {
// 成功
} failure:^(AFHTTPRequestOperation *operation, NSError *error) {
// 失敗
}];
return nil;
}];
}];
若是是用RAC宏設置viewModel和controller的某些屬性綁定，那也能夠省去手動給viewModel的set方法賦值這一步。（董鉑然博客園）異步
2.經過execute方法參數傳值
這種方法適用於參數較多的狀況沒法一一列爲viewModel的屬性。 這時候建議設置一個對象模型，而後在execute方法前將這個模型創建好並賦值，而後做爲參數傳入。函數
好比這種常見的列表類的具備多個參數的請求方法：fetch
// service.h ************************************
/**
* 獲取評價列表
*/
+ (void)requestForFeedbacklistWithSource:(BOOL)isFromWeb
dealid:(NSInteger)dealid
poiid:(NSInteger)poiid
labelName:(NSString *)labelName
type:(NSString *)type
readStatus:(NSString *)readStatus
replyStatus:(NSString *)replyStatus
limit:(NSNumber *)limit
offset:(NSNumber *)offset
success:(void(^)(NSDictionary *result))success
failure:(void(^)(AFHTTPRequestOperation *operation, NSError *error))failure;
在controller的發請求方法中舊方法就是直接調用service的請求接口，這裏再也不列出，下面列出RAC的寫法。
// controller.m ************************************
- (void)requestForDataWithType:(int)type
{
// ------給RACComand傳入一個input模型。
SXFeedbackListRequestModel *input = [SXFeedbackListRequestModel new];
input.replyStatus = self.replyStatus; // 這裏也能夠寫成一個工廠方法
input.readStatus = self.readStatus;
input.isMeituan = self.isMeituan;
input.dealid = self.dealid;
input.poiid = self.poiid;
input.type = self.type;
input.labelName = labelName;
input.offset = @(self.offset);
input.limit = @(10);
// 上面的input在這裏做爲參數傳入
[[self.viewModel.fetchFeedbackListCommand execute:input] subscribeNext:^(id x) {
// ------這裏處理正確的操做。
} error:^(NSError *error) {
// ------這裏處理失敗的操做。
}];
}
// viewModel.m ************************************
- (void) setupRACCommand
{
_fetchFeedbackListCommand = [[RACCommand alloc]initWithSignalBlock:^RACSignal *(SXFeedbackListRequestModel *input) {
return [RACSignal createSignal:^RACDisposable *(id<RACSubscriber> subscriber) {
// 用前面execute傳入的參數會傳到這個地方
[SXMerchantAutorityService requestForFeedbacklistWithSource:input.isFormWeb dealid:input.dealid poiid:input.poiid labelName:input.labelName type:input.type readStatus:input.readStatus replyStatus:input.replyStatus limit:input.limit offset:input.offset success:^(NSDictionary *result) {
@strongify(self);
// 一些操做
[subscriber sendCompleted];
} failure:^(AFHTTPRequestOperation *operation, NSError *error) {
[subscriber sendError:error];
}];
return nil;
}];
}];
}
可能會以爲在這個command中要把以前的模型的每個屬性都扒出來傳到參數裏行爲有點冗餘。 能夠將以前service裏的那個參數不少的方法改寫成只須要傳入一個模型。而後command這裏就能夠直接傳入模型了，反正在方法內部再取出來也不麻煩。我這邊考慮到了其餘非RAC地方的兼容性就沒有改了。
三.全部請求完成才消除toast
這裏是一個相似於請求combo的概念。全部的請求所有結束後才消除加載中的progressHUD ，若是在普通的架構下可用dispatch調度組來解決，可是RAC實現這個功能很是簡單，主要方法是經過executing信號來判斷一個命令的的狀態，而後使用combineLatest操做來監聽多個command的狀態，combineLatest操做的特徵是監聽的多個信號只要有一個改變了就把全部信號組成一個tuple返回。
// 監聽executing
RACSignal *hud = [RACSignal combineLatest:@[self.viewModel.fetchFeedbackListCommand.executing,self.viewModel.fetchFeedbackSummaryCommand.executing]];
[hud subscribeNext:^(RACTuple *x) {
if (![x.first boolValue]&&![x.second boolValue]) {
[MDSBezelActivityView removeView];
}else{
[MDSBezelActivityView activityViewForView:self.view withLabel:@"加載中..."];
}
}];
這個建議和以前RACObserve寫在一塊兒。 也能夠改爲filter的寫法。
// 能夠把加載HUD的代碼寫在最前面，而後後面直接控制消除HUD
[[hud filter:^BOOL(RACTuple *x) {
return ![x.first boolValue]&&![x.second boolValue];
}] subscribeNext:^(id x) {
[MDSBezelActivityView removeView];
}];
還有另外一種方法也能夠實現這種需求，rac_liftSelector這個方法是隻有全部數組中的信號都發出sendNext信號時纔會調用那個@selector的方法，而且這個方法的三個參數分別就是那三個sendNext發的。 全部的都回來了再統一打包，這主要適用於三個請求都是異步沒有依賴關係。
@weakify(self);
[[self rac_liftSelector:@selector(doWithA:withB:withC) withSignalsFromArray:@[signalA,signalB,signalC]] subscribeError:^(NSError *error) {
@strongify(self);
[MDSBezelActivityView removeView];
} completed:^{
[MDSBezelActivityView removeView];
}];
combineLatest和liftselector兩種combo的方法有必定的區別，具體的使用能夠結合需求。前者是每個請求回來了都會回調一下，後者是所有回來了再調用方法。（董鉑然博客園）
四.結果數據的傳遞
若是是但願全部的請求都完成了全部數據都得到了，後再刷新界面，使用上面統一消除toast的方法時一樣適合的。 把消除toast那行代碼改爲[self.tableVIew reloadData]或其餘代碼便可。
由於如今的主流是但願可以瘦身Controller， 因此通常也建議將業務邏輯、判斷、計算、拼接字符串放在viewModel裏，最後直接把須要的數據返回，控制器只負責獲得乾脆的數據後直接展現界面。 下面的例子是一個文本標籤上文字的得到方法
// Controller.m ************************************
// ViewDidLoad
RAC(self.replyCountLabel,text) = RACObserve(self.viewModel, replyCountLabelTitle);
// ViewModel.m ************************************
_fetchNewsDetailCommand = [[RACCommand alloc]initWithSignalBlock:^RACSignal *(id input) {
return [RACSignal createSignal:^RACDisposable *(id<RACSubscriber> subscriber) {
@strongify(self);
[self requestForNewsDetailSuccess:^(NSDictionary *result) {
// 這邊省去一些判空代碼
self.detailModel = [SXNewsDetailEntity detailWithDict:result[self.newsModel.docid]];
// 中間還有一些其餘的操做省略
NSInteger count = [self.newsModel.replyCount intValue];
// 這裏是直接把拼接好的標題返回，現實中還會遇到更復雜的邏輯
if ([self.newsModel.replyCount intValue] > 10000) {
self.replyCountBtnTitle = [NSString stringWithFormat:@"%.1f萬跟帖",count/10000.0];
}else{
self.replyCountBtnTitle = [NSString stringWithFormat:@"%ld跟帖",count];
}
[subscriber sendCompleted];
} failure:^(AFHTTPRequestOperation *operation, NSError *error) {
[subscriber sendError:error];
}];
return nil;
}];
}];
重構時能夠將更多控制器的屬性好比模型，或數組，放到viewModel裏。 之前控制器裏的self.replyModels 改爲self.ViewModel.replyModels。
// ViewModel.h ************************************
/**
* 類似新聞
*/
@property(nonatomic,strong)NSArray *similarNews;
/**
* 搜索關鍵字
*/
@property(nonatomic,strong)NSArray *keywordSearch;
/**
* 獲取搜索結果數組命令
*/
@property(nonatomic, strong) RACCommand *fetchNewsDetailCommand;
// ViewModel.m ************************************
// 某個command裏調用發請求方法成功的回調內
self.similarNews = [SXSimilarNewsEntity objectArrayWithKeyValuesArray:result[self.newsModel.docid][@"relative_sys"]];
self.keywordSearch = result[self.newsModel.docid][@"keyword_search"];
[subscriber sendCompleted];
// Controller.m ************************************
// 隨便拿了個方法舉例
- (CGFloat )tableView:(UITableView *)tableView heightForHeaderInSection:(NSInteger)section
{
switch (section) {
case 0:
return self.webView.height;
break;
case 1:
return self.viewModel.replyModels.count > 0 ? 40 : CGFLOAT_MIN;
break;
case 2:
return self.viewModel.similarNews.count > 0 ? 40 : CGFLOAT_MIN;
break;
default:
return CGFLOAT_MIN;
break;
}
}
合理的分離以後應該是Controller只有一些UI控件，ViewModel中存放模型屬性，命令，和一些業務邏輯操做或判斷的方法等。
對其中的一些demo代碼感興趣的能夠fork下這裏的代碼 https://github.com/dsxNiubility/SXNews 。之前是用土方法寫了個小項目，如今舊代碼移到了old分支，master分支上持續在作一些RAC相關的改動。
參照如上所說的方法進行重構，controller的代碼將會大大的減小，業務邏輯也會更加明朗。後續的第二節會整理一些特殊UI組件的RAC代碼實踐，第三節會整理一些更多的思考，再後面還沒想好。 本文是系列文而且也會吸收建議進行修改和更新，因此禁止轉載。本文歡迎提建議和吐槽。（董鉑然博客園）
- 1. ReactiveCocoa代碼實踐之-更多思考
- 2. 網絡請求重定向
- 3. 異步請求網絡代碼（一）
- 4. OKHttp源碼解析之網絡請求
- 5. Volley 源碼解析之網絡請求
- 6. charles重發網絡請求&模擬慢速網絡&過濾網絡請求
- 7. dynaTrace之一 —— 網絡請求和往返的最佳實踐
- 8. Android網絡請求框架之Retrofit實踐
- 9. Android之網絡請求5————OkHttp源碼2:發送請求
- 10. Flutter之網絡請求
- 更多相關文章...
- • Markdown 代碼 - Markdown 教程
- • HTTP 請求方法 - HTTP 教程
- • IntelliJ IDEA代碼格式化設置
- • 互聯網組織的未來：剖析GitHub員工的任性之源
-
每一个你不满意的现在，都有一个你没有努力的曾经。