哪家小吃培訓(xùn)網(wǎng)站做的最好,網(wǎng)站建設(shè)哪兒好,ppt模板網(wǎng)站排行榜,做公司網(wǎng)站的目的是什么1.3 解決方案#xff1a;添加拖動手勢識別器用手勢識別器也可以實現(xiàn)與解決方案1-1相同的交互功能#xff0c;而且還不用直接編寫觸摸處理程序[1]。拖動手勢識別器可以偵測拖曳手勢。只要iOS系統(tǒng)檢測到拖動手勢#xff0c;它就會觸發(fā)你所指定的回調(diào)方法。解決方案1-2的代碼與…1.3 解決方案添加拖動手勢識別器用手勢識別器也可以實現(xiàn)與解決方案1-1相同的交互功能而且還不用直接編寫觸摸處理程序[1]。拖動手勢識別器可以偵測拖曳手勢。只要iOS系統(tǒng)檢測到拖動手勢它就會觸發(fā)你所指定的回調(diào)方法。解決方案1-2的代碼與解決方案1-1的相似在首次初始化時這段代碼會向視圖中添加識別器。當(dāng)iOS發(fā)現(xiàn)用戶在DragView實例上面執(zhí)行拖曳時就會觸發(fā)handlePan回調(diào)方法而該方法會更新DragView的中心點使之與用戶所拖曳的距離相符。這段代碼計算距離的方式看上去似乎有些奇怪。它把視圖原來的位置保存在名為previousLocation的實例變量中然后在系統(tǒng)每次檢測到拖動手勢并觸發(fā)回調(diào)方法時計算目前位置與previousLocation之間的偏移。我們本來可以執(zhí)行仿射變換affine transform或運用setTranslationinView方法但本例卻采用了一種不常見的辦法就是移動視圖的中心點。解決方案1-2根據(jù)x軸和y軸上面的偏移量創(chuàng)建了CGPoint并依照這個偏移量來設(shè)定視圖的中心點以此來改變視圖的實際位置。仿射變換與簡單的偏移量不同它可以同時達(dá)成旋轉(zhuǎn)、縮放及平移操作。為了支持變換手勢識別器以絕對量的方式來描述坐標(biāo)改變而不是給出兩次改變之間的相對差值。這樣就不需要把多個偏移量累加起來了因為UIPanGestureRecognizer只返回一個變化量這個變化量以某個視圖的坐標(biāo)系來描述位置的變化一般來說參照的就是當(dāng)前視圖的上級視圖的坐標(biāo)系。有了這個平移變化量我們就可以執(zhí)行一些簡單的仿射變換計算了而且還可以通過數(shù)學(xué)運算的方式與其他變換結(jié)合起來達(dá)到一次性執(zhí)行多種變換操作的效果。如果不保存狀態(tài)而是直接執(zhí)行變換那么handlePan方法的代碼就會變成下面這個樣子請注意手勢識別器會在交互操作結(jié)束的時候更新視圖的位置并重設(shè)transform屬性的tx與ty。經(jīng)過上述改編之后我們就無須在程序里記錄上一次的位置了于是也就用不著touchesBeganwithEvent方法了。若是不按照上述代碼來編寫那么解決方案1-2必須保存前一次的狀態(tài)。解決方案1-2 用拖動手勢識別器實現(xiàn)可供拖曳的視圖1.4 解決方案同時使用多個手勢識別器解決方案1-3是基于解決方案1-2的思路而構(gòu)建的但是兩者之間有一些區(qū)別。首先它創(chuàng)建了多個平行運作的識別器。該解決方案的代碼分別使用了旋轉(zhuǎn)、雙指聚攏及拖動這三種識別器并把它們?nèi)继砑拥搅薉ragView的gestureRecognizers屬性中然后它把DragView設(shè)為每個識別器的委托[1]。這樣的話DragView就可以實現(xiàn)名為gestureRecognizershouldRecognizeSimultaneouslyWithGestureRecognizer的委托方法從而令多個識別器能夠同時運作。我們必須實現(xiàn)好這個方法并將其返回值設(shè)為YES否則在同一時刻就只會有一個識別器起作用。平行使用多個識別器可以實現(xiàn)出一些功能例如當(dāng)用戶做出雙指聚攏手勢時我們可以同時用縮放及旋轉(zhuǎn)效果來響應(yīng)該手勢。提示 UITouch對象保存了含有手勢識別器的數(shù)組。這個數(shù)組里的每個元素都是手勢識別器而每個識別器都用來接收相關(guān)的觸摸對象。如果創(chuàng)建某個視圖時沒有指定手勢識別器那么在系統(tǒng)傳給響應(yīng)者方法的觸摸對象里面gestureRecognizers數(shù)組就是空的。解決方案1-3擴(kuò)充了視圖的狀態(tài)給對象添加了與縮放和旋轉(zhuǎn)功能有關(guān)的實例變量。這些變量可以記錄前一次的變換值而程序代碼則會根據(jù)它們來合成仿射變換。仿射變換的效果是在解決方案1-3的updateTransformWithOffset方法里面合成出來的該方法把平移、旋轉(zhuǎn)及縮放這三種操作合并成一個效果。與前一個解決方案不同這份解決方案統(tǒng)一經(jīng)由self.transform來實現(xiàn)對視圖的修改而這也是使用手勢識別器時的常見做法。解決方案1-3 同時識別多種手勢最后請大家注意這份解決方案同時實現(xiàn)了兩套手勢識別機(jī)制。一方面我們給視圖的gestureRecognizers數(shù)組里添加了手勢識別器對象而另一方面我們像解決方案1-1那樣通過基本的觸摸方法來捕捉“三連擊”triple-tap[2]操作。在本例中當(dāng)用戶執(zhí)行三連擊操作時會把視圖的transform重置為恒等變換[3]。這樣的話原來對該視圖所做的操作就將全部還原這個視圖的位置、方向及尺寸都會回到原來的樣子。通過這段代碼大家可以看到touchesBegan、touchesMoved、touchesEnded及touchesCancelled這四個方法與手勢識別器的回調(diào)方法是并行不悖work seamlessly的筆者之所以要在解決方案中同時實現(xiàn)兩套手勢識別機(jī)制就是為了使大家體會到這一點。同樣的功能其實也可以通過添加UITapGestureRecognizer來實現(xiàn)。大家通過這個解決方案可以感覺到用手勢識別器來處理觸摸操作是非常簡明的。解決手勢沖突如果需要同時辨認(rèn)多種手勢那么可能會產(chǎn)生手勢沖突gesture conflict。比方說需要同時識別單擊single-tap和雙擊double-tap的時候就會出現(xiàn)問題。如果用戶想執(zhí)行的是雙擊操作那么負(fù)責(zé)識別單擊操作的識別器是應(yīng)該在用戶第一次點擊的時候就觸發(fā)單擊操作還是應(yīng)該等到用戶徹底不打算點擊第二下的時候再去響應(yīng)呢iOS SDK提供了一些手段使開發(fā)者可以通過代碼來解決這些沖突。我們在編寫類的代碼時可以指明必須等某個手勢無法觸發(fā)時才去觸發(fā)另一個手勢。這種規(guī)則可以通過調(diào)用requireGestureRecognizerToFail方法來確立。UIGestureRecognizer里的這個方法接收一個參數(shù)也就是另外一個手勢識別器。調(diào)用該方法之后兩個手勢識別器之間就創(chuàng)建了依賴關(guān)系。系統(tǒng)必須先確定另外一個手勢無法觸發(fā)然后才能觸發(fā)當(dāng)前這個手勢。假如系統(tǒng)可以辨識出另外一個手勢那么就不觸發(fā)這個手勢了。iOS 7引入了一些新的API經(jīng)由UIGestureRecognizer的委托及子類我們可以在運行期runtime實現(xiàn)更為靈活的手勢判定規(guī)則[4]。在UIGestureRecognizer的委托中我們可以實現(xiàn)gestureRecognizershouldRequireFailureOfGestureRecognizer方法及gestureRecognizer shouldBeRequiredToFailByGestureRecognizer方法而在UIGestureRecognizer的子類中則可以覆寫shouldRequireFailureOfGestureRecognizer方法及shouldBeRequiredToFailByGestureRecognizer方法。對于上面所說的四個方法其返回值均為布爾類型。如果返回的是YES就意味著必須等某個手勢徹底無法觸發(fā)時才能觸發(fā)另一個手勢。每當(dāng)識別器想要辨識某個手勢時系統(tǒng)就會調(diào)用UIGestureRecognizer的相關(guān)委托方法這樣一來我們就可以在處于不同視圖體系的識別器對象之間建立依賴關(guān)系了此外如果想定義針對某個UIGestureRecognizer子類的手勢辨識規(guī)則那么可以在其中覆寫并實現(xiàn)相關(guān)的方法。在開發(fā)真實的應(yīng)用程序時如果設(shè)定了手勢間的依賴關(guān)系就意味著識別器的反應(yīng)時間會有所延遲因為它得等另一個識別器徹底失敗為止。也就是說它得等到另一個手勢徹底無法觸發(fā)只有到那時該識別器才能完成對本手勢的辨識。如果我們要同時辨識單擊和雙擊那么當(dāng)用戶初次點擊屏幕之后應(yīng)用程序必須多等一會兒才能確定是不是發(fā)生了單擊。因為它必須在確定了不可能發(fā)生雙擊之后才能去觸發(fā)單擊。假如觸發(fā)了雙擊那么就不再觸發(fā)單擊了這兩種手勢只能觸發(fā)一種。為了適應(yīng)這種規(guī)則變化GUI的響應(yīng)能力會下降它對單擊操作的響應(yīng)會稍顯“遲鈍”。這是因為程序必須等待一段時間才能判斷出是否會發(fā)生雙擊。假如程序的高速響應(yīng)能力對用戶體驗有著非常重要的影響那么就不要同時使用這兩種識別器了而是應(yīng)該把單擊行為解讀為立刻執(zhí)行某操作。在這種情況下不應(yīng)該同時設(shè)計單擊及雙擊這兩種手勢。大家可別忘了開發(fā)者可以隨時添加、移除或禁用手勢識別器。比方說用戶在執(zhí)行單擊操作之后程序界面會進(jìn)入另一種模式而在那種模式下用戶可以分別通過單擊和雙擊來做不同的事情。離開了那種模式之后開發(fā)者可以將辨識雙擊手勢所用的識別器移除或禁用這樣能夠重新提高程序?qū)螕舨僮鞯谋孀R速度。在確有必要時這種優(yōu)化技術(shù)可以緩解界面的延遲現(xiàn)象。[1] “把A設(shè)為B的委托”或“把A賦給B的委托屬性”這種句式其大概的意思是B需要通過某個實現(xiàn)了C協(xié)議的對象來處理發(fā)生在B身上的一些事件而A對象所屬的類實現(xiàn)了C協(xié)議于是我們就用A來處理發(fā)生在B上面的事件。這時C協(xié)議中所約定的一些方法就叫作“B的委托方法”而A或A所屬的類則可以泛稱為“B的委托”。具體到解決方案1-3來說這種句式對應(yīng)于代碼中的“recognizer.delegate self;”其中的self就是Arecognizer就是B?！g者注[2 ] 短時間內(nèi)連續(xù)做三次點擊?！g者注[3] 也就是沒有經(jīng)過任何平移、旋轉(zhuǎn)及縮放的變換效果可以理解為“單位矩陣”?！g者注[4 ] 原文稱為failure condition失敗條件?！g者注1.5 解決方案限制移動本章前面幾個解決方案所使用的辦法都比較簡單但是有個問題就是用戶完全有可能把某個視圖拖動到屏幕之外導(dǎo)致其難以把自己看不到的視圖重新拖回到屏幕內(nèi)。那些解決方案沒有對移動施加限制。它們并沒有判斷用戶所要操作的對象是不是處在大視圖的范圍內(nèi)而且也沒有判斷那個對象是不是可供觸摸。解決方案1-4對視圖在其上級視圖內(nèi)的移動行為做出了限制從而解決了此問題。具體的限制辦法是從x軸和y軸方向上分別檢查視圖的移動是否符合規(guī)則以此來限制其在每個方向上的移動行為。分兩個軸來檢測有個好處就是即便視圖對象在某個軸上已經(jīng)移動到了邊界它也依然可以在另一個軸上面繼續(xù)移動。比方說就算視圖已經(jīng)碰到了上級視圖的右邊界它也照樣可以在垂直方向上下移動。提示 iOS 7引入了一套UIKit Dynamics API用于對真實的物理現(xiàn)象進(jìn)行建模其中包含物理模擬及響應(yīng)式動畫等功能。開發(fā)者可以使用這套聲明式的Dynamics API來對重力、碰撞、力、附著、彈簧、伸縮等大量現(xiàn)象進(jìn)行建模并將其效果運用在UIKit物件上面。但是本條解決方案采用傳統(tǒng)的做法也就是通過手勢識別器以及直接框架操作direct frame manipulation來實現(xiàn)UI物件的移動并對其施加限制讀者可以用Dynamics實現(xiàn)出更為精致的版本。圖1-1演示了一個樣本界面。程序?qū)⒏鱾€子視圖也就是圖中的花的移動范圍限制在界面中央的黑色矩形內(nèi)使用戶無法將其拖到屏幕范圍之外。解決方案1-4的代碼寫得比較通用所以你可將其改編使之適用于任意尺寸的外圍邊界parent bound及子視圖。1.6 解決方案測試觸摸由于直接操縱界面中的大部分屏幕視圖元件onscreen view element都不是矩形所以觸摸測試實現(xiàn)起來會比較困難因為視圖所在的矩形框與實際應(yīng)該接受觸摸的范圍并不完全相同。圖1-2演示了這個問題。右側(cè)的屏幕截圖展示了整套界面以及界面中可供觸碰的各個子視圖而左側(cè)的截圖則描繪出每個子視圖周圍的矩形框[1]。其中灰色的部分雖然處在矩形框范圍之內(nèi)但卻在圓圈外面因此如果用戶觸碰了這個區(qū)域那么應(yīng)用程序不應(yīng)該判定其點擊hit了相關(guān)的子視圖。只要觸碰點位于視圖的范圍內(nèi)iOS就會偵測到這一動作。這個范圍既包括視圖的主體部分也包括用戶看不到的區(qū)域也就是圖1-2左側(cè)截圖中處于圓形之外但又位于矩形之內(nèi)的灰色區(qū)域。在圖1-2右側(cè)截圖中每個UIView本體周圍的透明部分clear portion的下方可能還有別的視圖所以我們必須添加某種觸摸判定機(jī)制hit test才能使用戶可以觸碰到那些視圖。如果想把視圖所對應(yīng)的矩形框顯示出來那么可以用下面代碼來設(shè)定其背景色這樣就可以在不影響屏幕實際圖形的前提下給它們后方畫上一塊灰色的板子如圖1-2左側(cè)截圖所示。在本例中每個視圖的主體部分都是圓形圖樣如果不添加上面的代碼那么其背景色就是透明的。由此可見我們必須添加某種觸摸判定機(jī)制否則如果用戶點擊了透明部分系統(tǒng)就會認(rèn)為用戶點擊的是相關(guān)的視圖。手工指定背景色是一種便捷的調(diào)試手法它使開發(fā)者能夠看到每個視圖真正應(yīng)該接受觸摸的范圍。在發(fā)布正式產(chǎn)品之前別忘了把對背景色的賦值語句注釋掉。除了筆者所說的這種調(diào)試辦法之外還有一種辦法就是設(shè)定視圖的層layer所具備的邊框?qū)挾燃皹邮?。解決方案1-5給視圖添加了簡單的觸摸判定機(jī)制以判斷觸摸點是否在圓圈范圍內(nèi)。我們是通過覆寫UIView的pointInsidewithEvent方法來實現(xiàn)此機(jī)制的。該方法如果返回YES就表明觸摸點位于視圖之內(nèi)如果返回NO則表明不在視圖之內(nèi)。本例所實現(xiàn)的判定機(jī)制采用的是基本的幾何運算也就是檢查觸摸點是不是在圓圈的半徑之內(nèi)。你也可以采用與自己的應(yīng)用程序相符的其他辦法來判斷用戶是否觸摸了屏幕上的視圖。在下一節(jié)的解決方案1-6中筆者會對判定代碼進(jìn)行擴(kuò)充以實現(xiàn)更加精細(xì)的控制。解決方案1-5 判斷某個點是否位于圓形的視圖中請注意對于配備了Retina顯示屏的設(shè)備其觸摸檢測方式與老式的設(shè)備相同在做數(shù)學(xué)運算時使用的也是標(biāo)準(zhǔn)的點坐標(biāo)系統(tǒng)而不是實際的像素。設(shè)備上多出來的像素并不影響處理手勢時所用的數(shù)學(xué)算式。視圖的坐標(biāo)系統(tǒng)依然采用亞像素精度subpixel accuracy的浮點數(shù)。設(shè)備繪制屏幕內(nèi)容時所采用的具體像素數(shù)既不會影響UIView的范圍框也不會影響UITouch中的坐標(biāo)。它只是一種能在坐標(biāo)系統(tǒng)中提高繪制精度的手段。提示 我們這里所說的觸摸判定機(jī)制hit test是指一種判斷點是不是處于視圖之中的機(jī)制而不是指名字看上去與之相似的hitTestwithEvent方法。這個方法用于返回視圖體系中包含某個點的最頂層視圖topmost view也就是距離用戶及屏幕最近的視圖。它會在每個視圖上面調(diào)用pointInsidewithEvent。如果pointInside方法返回YES那么它就會沿著視圖體系繼續(xù)向下判斷。