關於這個標題,起因是這樣的。
最近一次做項目需求時,遇到這樣一個需求,就是本來我們App
是必須注冊或者第三方登錄才可以使用,現在希望不登錄也可以浏覽App
裡面的內容,只是在需要的時候才提示登錄,並且在用戶沒有登錄的情況下,用戶選擇並登錄成功了,程序需自動完成用戶操作登錄前的操作。比如購買商品時沒有登錄,用戶登錄成功後,直接跳轉至訂單確認頁面。
在接到這個需求時,我們的App
功能已經很多了,評估了下這個需求,發現App
裡面很多功能是需要登錄才可以操作,比如關注用戶、購買商品、私信聊天、評論等等,而且這些功能的入口也比較多。
這麼多的地方我們都要去寫判斷的代碼顯然是不科學的,那麼有沒有簡單點的方式呢?怎麼避免我們去做苦力活呢?????????????
於是,進一步分析,發現這些功能大部分都是用戶主動通過點擊按鈕來觸發下一步操作。此時,我們把關注點移到按鈕UIButton
上。
最開始想到的辦法是自定義一個button
,讓所有需要登錄操作的按鈕繼承這個按鈕,然後,在這個按鈕裡面攔截自身事件進一步處理。但是,發現這麼做還是需要改大量的代碼。接著想到用類別來做,這樣直接給按鈕增加一個BOOL
屬性,設置為YES
的按鈕視為需要做登錄才可以操作的按鈕。然後,對於需要登錄操作的按鈕,在分類裡面攔截其點擊事件,並記錄target
和action
,然後先判斷是否登錄:如果沒有登錄則丟棄其target
和action
,並且提示用戶登錄;如果用戶已經登錄或者登錄成功了,則繼續讓target
執行action
,這樣完美解決我們的需求,也只需要很少的代碼即可搞定。
這個方案看似很不錯,不過在實際做的時候還是走了彎路。一開始,我們想從下面方法入手
- (void)addTarget:(nullableid)target action:(SEL)action forControlEvents:(UIControlEvents)controlEvents
但是發現根本就不能實現。經過查找,找到了下面這個方法:
- (void)sendAction:(SEL)action to:(id)target forEvent:(UIEvent *)event
關於這個方法,蘋果給了如下解釋:
send the action. the first method is called for the event and is a point at which you can observe or override behavior. it is called repeately by the second.
這正是我們要找的方法,於是我們重寫此方法,如下:
- (void)sendAction:(SEL)action to:(id)target forEvent:(UIEvent *)event { if (self.checkLogin) { self.selector = NSStringFromSelector(action); self.objClass = target; [self checkIsLogin]; } else { [super sendAction:action to:target forEvent:event]; } } - (void)checkIsLogin { __weak typeof(self) weakSelf = self; [LoginManager checkLoginSuccess:^{ SEL sel = NSSelectorFromString(weakSelf.selector); if ([weakSelf.objClass respondsToSelector:sel]) { if ([weakSelf.selector hasSuffix:@":"]) { objc_msgSend(weakSelf.objClass, sel, self); } else { objc_msgSend(weakSelf.objClass, sel); } } }]; }
簡單解釋下這段代碼:
當按鈕事件執行時會走sendAction:to:forEvent:
這個方法,於是,我們在這個方法裡面,先判斷該按鈕是否需要登錄後再操作,如果需要,阻斷事件傳遞,並記錄下按鈕的action和target,然後判斷是否登錄了,如果已經登錄或者用戶登錄成功了,那麼再調用objc_msgSend(self.objClass, self.selector)
去實現按鈕事件,如果用戶放棄登錄或者登錄失敗,則不做處理。
實現了上面的方法之後,我們只需要找出那些按鈕事件需要登錄後才能操作,然後,設置按鈕的checkLogin = YES
即可,這樣是不是省了很多不必要的代碼。
到此,上面的實現已經解決了所有按鈕點擊需要判斷登錄的操作。還有些是上述方式解決不了的,則使用LoginManager
單獨處理下,幸運的是,幾乎很少地方需要單獨處理。
通過這個案例:一方面鞏固了對sendAction:to:forEvent:
這個方法的理解;另一方面在做需求的時候一定要發散思維,找到更合理的解決方法。
歡迎大家留言討論,如果你有更好地方法,歡迎分享!