關于這個標題，起因是這樣的。
最近一次做項目需求時，遇到這樣一個需求，就是本來我們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:這個方法的理解；另一方面在做需求的時候一定要發散思維，找到更合理的解決方法。
歡迎大家留言討論，如果你有更好地方法，歡迎分享！
