[iOS UI進階,iosui進階
A.事件的產生和傳遞 發生觸摸事件後,系統會將該事件加入到一個由UIApplication管理的事件隊列中
UIApplication會從事件隊列中取出最前面的事件,並將事件分發下去以便處理,通常,先發送事件給應用程式的主視窗(keyWindow)
主視窗會在視圖階層中找到一個最合適的視圖來處理觸摸事件,這也是整個事件處理過程的第一步
找到合適的視圖控制項後,就會調用視圖控制項的touches方法來作具體的事件處理
touchesBegan…
touchesMoved… touchedEnded… B.不接受事件傳遞的情況 不接收使用者互動
userInteractionEnabled = NO
隱藏
hidden = YES
透明
alpha = 0.0 ~ 0.01
提示:UIImageView的userInteractionEnabled預設就是NO,因此UIImageView以及它的子控制項預設是不能接收觸摸事件的 C.觸摸事件處理的過程 使用者點擊螢幕後產生的一個觸摸事件,經過一些列的傳遞過程後,會找到最合適的視圖控制項來處理這個事件
找到最合適的視圖控制項後,就會調用控制項的touches方法來作具體的事件處理
touchesBegan…
touchesMoved…
touchedEnded…
這些touches方法的預設做法是將事件順著響應者鏈條向上傳遞,將事件交給上一個響應者進行處理 D.響應者鏈條
For the app on the left, the event follows this path:
The app on the right follows a slightly different path, but all event delivery paths follow these heuristics:
渣翻譯: 對於左邊的app來說,事件軌跡是這樣的:(單控制器) 1.初始控制項嘗試處理事件或者資訊,如果它不能處理,因為初始控制項不是它所在控制項控制器的控制項層的最頂層控制項,所以傳遞到它的父控制項。 2.“父控制項”也嘗試跟進處理事件,如果這個“父控制項”還是不能處理,由於此"父控制項"還不是控制器控制項層的最頂層控制項,所以還會傳遞這個事件給它的父控制項(嗯,初始控制項的“爺控制項”)。 3.控制器空間層的最頂層控制項拿到事件,努力想進行處理,如果它還是沒有這個能力,就會傳遞到它所屬的控制器。 4.控制器還不行,只能傳遞給視窗(window)了 5.window不能處理的話,還會繼續傳遞給app單例對象(Application) 6.如果最後app都不能處理,只能放棄這個事件了。 對於右邊的app來講,事件軌跡稍稍不同,不過也都遵循下列規則:(多控制器) 1.一個控制項按照它的控制器控制項層次往上傳遞事件,在此控制器控制項層中傳遞匹配有處理能力的控制項,直到到達最頂層控制項。 2.上述控制項層的最頂層控制項不能處理,把事件傳遞給控制器。 3.如果“2”的控制器不能處理,把事件傳遞給它的父控制項,重複1-3,直到處理了事件,或者到達根控制器。 4.如果根控制器不能處理,傳遞事件給window對象 5.如果window對象也不能處理,傳遞事件給app對象(application) 6.app最後也不能處理,捨棄事件
D.監聽觸摸事件 如果想監聽一個view上面的觸摸事件,之前的做法是
自訂一個view
實現view的touches方法,在方法內部實現具體處理代碼
通過touches方法監聽view觸摸事件,有很明顯的幾個缺點
必須得自訂view
由於是在view內部的touches方法中監聽觸摸事件,因此預設情況下,無法讓其他外界對象監聽view的觸摸事件
不容易區分使用者的具體手勢行為
iOS 3.2之後,蘋果推出了手勢識別功能(Gesture Recognizer),在觸摸事件處理方面,大大簡化了開發人員的開發難度 多種手勢辨識器: