企业官网建设流程全解析

哪家小吃培训网站做的最好,网站建设哪儿好,ppt模板网站排行榜,做公司网站的目的是什么1.3 解决方案#xff1a;添加拖动手势识别器用手势识别器也可以实现与解决方案1-1相同的交互功能#xff0c;而且还不用直接编写触摸处理程序[1]。拖动手势识别器可以侦测拖曳手势。只要iOS系统检测到拖动手势#xff0c;它就会触发你所指定的回调方法。解决方案1-2的代码与…1.3 解决方案添加拖动手势识别器用手势识别器也可以实现与解决方案1-1相同的交互功能而且还不用直接编写触摸处理程序[1]。拖动手势识别器可以侦测拖曳手势。只要iOS系统检测到拖动手势它就会触发你所指定的回调方法。解决方案1-2的代码与解决方案1-1的相似在首次初始化时这段代码会向视图中添加识别器。当iOS发现用户在DragView实例上面执行拖曳时就会触发handlePan回调方法而该方法会更新DragView的中心点使之与用户所拖曳的距离相符。这段代码计算距离的方式看上去似乎有些奇怪。它把视图原来的位置保存在名为previousLocation的实例变量中然后在系统每次检测到拖动手势并触发回调方法时计算目前位置与previousLocation之间的偏移。我们本来可以执行仿射变换affine transform或运用setTranslationinView方法但本例却采用了一种不常见的办法就是移动视图的中心点。解决方案1-2根据x轴和y轴上面的偏移量创建了CGPoint并依照这个偏移量来设定视图的中心点以此来改变视图的实际位置。仿射变换与简单的偏移量不同它可以同时达成旋转、缩放及平移操作。为了支持变换手势识别器以绝对量的方式来描述坐标改变而不是给出两次改变之间的相对差值。这样就不需要把多个偏移量累加起来了因为UIPanGestureRecognizer只返回一个变化量这个变化量以某个视图的坐标系来描述位置的变化一般来说参照的就是当前视图的上级视图的坐标系。有了这个平移变化量我们就可以执行一些简单的仿射变换计算了而且还可以通过数学运算的方式与其他变换结合起来达到一次性执行多种变换操作的效果。如果不保存状态而是直接执行变换那么handlePan方法的代码就会变成下面这个样子请注意手势识别器会在交互操作结束的时候更新视图的位置并重设transform属性的tx与ty。经过上述改编之后我们就无须在程序里记录上一次的位置了于是也就用不着touchesBeganwithEvent方法了。若是不按照上述代码来编写那么解决方案1-2必须保存前一次的状态。解决方案1-2 用拖动手势识别器实现可供拖曳的视图1.4 解决方案同时使用多个手势识别器解决方案1-3是基于解决方案1-2的思路而构建的但是两者之间有一些区别。首先它创建了多个平行运作的识别器。该解决方案的代码分别使用了旋转、双指聚拢及拖动这三种识别器并把它们全都添加到了DragView的gestureRecognizers属性中然后它把DragView设为每个识别器的委托[1]。这样的话DragView就可以实现名为gestureRecognizershouldRecognizeSimultaneouslyWithGestureRecognizer的委托方法从而令多个识别器能够同时运作。我们必须实现好这个方法并将其返回值设为YES否则在同一时刻就只会有一个识别器起作用。平行使用多个识别器可以实现出一些功能例如当用户做出双指聚拢手势时我们可以同时用缩放及旋转效果来响应该手势。提示 UITouch对象保存了含有手势识别器的数组。这个数组里的每个元素都是手势识别器而每个识别器都用来接收相关的触摸对象。如果创建某个视图时没有指定手势识别器那么在系统传给响应者方法的触摸对象里面gestureRecognizers数组就是空的。解决方案1-3扩充了视图的状态给对象添加了与缩放和旋转功能有关的实例变量。这些变量可以记录前一次的变换值而程序代码则会根据它们来合成仿射变换。仿射变换的效果是在解决方案1-3的updateTransformWithOffset方法里面合成出来的该方法把平移、旋转及缩放这三种操作合并成一个效果。与前一个解决方案不同这份解决方案统一经由self.transform来实现对视图的修改而这也是使用手势识别器时的常见做法。解决方案1-3 同时识别多种手势最后请大家注意这份解决方案同时实现了两套手势识别机制。一方面我们给视图的gestureRecognizers数组里添加了手势识别器对象而另一方面我们像解决方案1-1那样通过基本的触摸方法来捕捉“三连击”triple-tap[2]操作。在本例中当用户执行三连击操作时会把视图的transform重置为恒等变换[3]。这样的话原来对该视图所做的操作就将全部还原这个视图的位置、方向及尺寸都会回到原来的样子。通过这段代码大家可以看到touchesBegan、touchesMoved、touchesEnded及touchesCancelled这四个方法与手势识别器的回调方法是并行不悖work seamlessly的笔者之所以要在解决方案中同时实现两套手势识别机制就是为了使大家体会到这一点。同样的功能其实也可以通过添加UITapGestureRecognizer来实现。大家通过这个解决方案可以感觉到用手势识别器来处理触摸操作是非常简明的。解决手势冲突如果需要同时辨认多种手势那么可能会产生手势冲突gesture conflict。比方说需要同时识别单击single-tap和双击double-tap的时候就会出现问题。如果用户想执行的是双击操作那么负责识别单击操作的识别器是应该在用户第一次点击的时候就触发单击操作还是应该等到用户彻底不打算点击第二下的时候再去响应呢iOS SDK提供了一些手段使开发者可以通过代码来解决这些冲突。我们在编写类的代码时可以指明必须等某个手势无法触发时才去触发另一个手势。这种规则可以通过调用requireGestureRecognizerToFail方法来确立。UIGestureRecognizer里的这个方法接收一个参数也就是另外一个手势识别器。调用该方法之后两个手势识别器之间就创建了依赖关系。系统必须先确定另外一个手势无法触发然后才能触发当前这个手势。假如系统可以辨识出另外一个手势那么就不触发这个手势了。iOS 7引入了一些新的API经由UIGestureRecognizer的委托及子类我们可以在运行期runtime实现更为灵活的手势判定规则[4]。在UIGestureRecognizer的委托中我们可以实现gestureRecognizershouldRequireFailureOfGestureRecognizer方法及gestureRecognizer shouldBeRequiredToFailByGestureRecognizer方法而在UIGestureRecognizer的子类中则可以覆写shouldRequireFailureOfGestureRecognizer方法及shouldBeRequiredToFailByGestureRecognizer方法。对于上面所说的四个方法其返回值均为布尔类型。如果返回的是YES就意味着必须等某个手势彻底无法触发时才能触发另一个手势。每当识别器想要辨识某个手势时系统就会调用UIGestureRecognizer的相关委托方法这样一来我们就可以在处于不同视图体系的识别器对象之间建立依赖关系了此外如果想定义针对某个UIGestureRecognizer子类的手势辨识规则那么可以在其中覆写并实现相关的方法。在开发真实的应用程序时如果设定了手势间的依赖关系就意味着识别器的反应时间会有所延迟因为它得等另一个识别器彻底失败为止。也就是说它得等到另一个手势彻底无法触发只有到那时该识别器才能完成对本手势的辨识。如果我们要同时辨识单击和双击那么当用户初次点击屏幕之后应用程序必须多等一会儿才能确定是不是发生了单击。因为它必须在确定了不可能发生双击之后才能去触发单击。假如触发了双击那么就不再触发单击了这两种手势只能触发一种。为了适应这种规则变化GUI的响应能力会下降它对单击操作的响应会稍显“迟钝”。这是因为程序必须等待一段时间才能判断出是否会发生双击。假如程序的高速响应能力对用户体验有着非常重要的影响那么就不要同时使用这两种识别器了而是应该把单击行为解读为立刻执行某操作。在这种情况下不应该同时设计单击及双击这两种手势。大家可别忘了开发者可以随时添加、移除或禁用手势识别器。比方说用户在执行单击操作之后程序界面会进入另一种模式而在那种模式下用户可以分别通过单击和双击来做不同的事情。离开了那种模式之后开发者可以将辨识双击手势所用的识别器移除或禁用这样能够重新提高程序对单击操作的辨识速度。在确有必要时这种优化技术可以缓解界面的延迟现象。[1] “把A设为B的委托”或“把A赋给B的委托属性”这种句式其大概的意思是B需要通过某个实现了C协议的对象来处理发生在B身上的一些事件而A对象所属的类实现了C协议于是我们就用A来处理发生在B上面的事件。这时C协议中所约定的一些方法就叫作“B的委托方法”而A或A所属的类则可以泛称为“B的委托”。具体到解决方案1-3来说这种句式对应于代码中的“recognizer.delegate self;”其中的self就是Arecognizer就是B。——译者注[2 ] 短时间内连续做三次点击。——译者注[3] 也就是没有经过任何平移、旋转及缩放的变换效果可以理解为“单位矩阵”。——译者注[4 ] 原文称为failure condition失败条件。——译者注1.5 解决方案限制移动本章前面几个解决方案所使用的办法都比较简单但是有个问题就是用户完全有可能把某个视图拖动到屏幕之外导致其难以把自己看不到的视图重新拖回到屏幕内。那些解决方案没有对移动施加限制。它们并没有判断用户所要操作的对象是不是处在大视图的范围内而且也没有判断那个对象是不是可供触摸。解决方案1-4对视图在其上级视图内的移动行为做出了限制从而解决了此问题。具体的限制办法是从x轴和y轴方向上分别检查视图的移动是否符合规则以此来限制其在每个方向上的移动行为。分两个轴来检测有个好处就是即便视图对象在某个轴上已经移动到了边界它也依然可以在另一个轴上面继续移动。比方说就算视图已经碰到了上级视图的右边界它也照样可以在垂直方向上下移动。提示 iOS 7引入了一套UIKit Dynamics API用于对真实的物理现象进行建模其中包含物理模拟及响应式动画等功能。开发者可以使用这套声明式的Dynamics API来对重力、碰撞、力、附着、弹簧、伸缩等大量现象进行建模并将其效果运用在UIKit物件上面。但是本条解决方案采用传统的做法也就是通过手势识别器以及直接框架操作direct frame manipulation来实现UI物件的移动并对其施加限制读者可以用Dynamics实现出更为精致的版本。图1-1演示了一个样本界面。程序将各个子视图也就是图中的花的移动范围限制在界面中央的黑色矩形内使用户无法将其拖到屏幕范围之外。解决方案1-4的代码写得比较通用所以你可将其改编使之适用于任意尺寸的外围边界parent bound及子视图。1.6 解决方案测试触摸由于直接操纵界面中的大部分屏幕视图元件onscreen view element都不是矩形所以触摸测试实现起来会比较困难因为视图所在的矩形框与实际应该接受触摸的范围并不完全相同。图1-2演示了这个问题。右侧的屏幕截图展示了整套界面以及界面中可供触碰的各个子视图而左侧的截图则描绘出每个子视图周围的矩形框[1]。其中灰色的部分虽然处在矩形框范围之内但却在圆圈外面因此如果用户触碰了这个区域那么应用程序不应该判定其点击hit了相关的子视图。只要触碰点位于视图的范围内iOS就会侦测到这一动作。这个范围既包括视图的主体部分也包括用户看不到的区域也就是图1-2左侧截图中处于圆形之外但又位于矩形之内的灰色区域。在图1-2右侧截图中每个UIView本体周围的透明部分clear portion的下方可能还有别的视图所以我们必须添加某种触摸判定机制hit test才能使用户可以触碰到那些视图。如果想把视图所对应的矩形框显示出来那么可以用下面代码来设定其背景色这样就可以在不影响屏幕实际图形的前提下给它们后方画上一块灰色的板子如图1-2左侧截图所示。在本例中每个视图的主体部分都是圆形图样如果不添加上面的代码那么其背景色就是透明的。由此可见我们必须添加某种触摸判定机制否则如果用户点击了透明部分系统就会认为用户点击的是相关的视图。手工指定背景色是一种便捷的调试手法它使开发者能够看到每个视图真正应该接受触摸的范围。在发布正式产品之前别忘了把对背景色的赋值语句注释掉。除了笔者所说的这种调试办法之外还有一种办法就是设定视图的层layer所具备的边框宽度及样式。解决方案1-5给视图添加了简单的触摸判定机制以判断触摸点是否在圆圈范围内。我们是通过覆写UIView的pointInsidewithEvent方法来实现此机制的。该方法如果返回YES就表明触摸点位于视图之内如果返回NO则表明不在视图之内。本例所实现的判定机制采用的是基本的几何运算也就是检查触摸点是不是在圆圈的半径之内。你也可以采用与自己的应用程序相符的其他办法来判断用户是否触摸了屏幕上的视图。在下一节的解决方案1-6中笔者会对判定代码进行扩充以实现更加精细的控制。解决方案1-5 判断某个点是否位于圆形的视图中请注意对于配备了Retina显示屏的设备其触摸检测方式与老式的设备相同在做数学运算时使用的也是标准的点坐标系统而不是实际的像素。设备上多出来的像素并不影响处理手势时所用的数学算式。视图的坐标系统依然采用亚像素精度subpixel accuracy的浮点数。设备绘制屏幕内容时所采用的具体像素数既不会影响UIView的范围框也不会影响UITouch中的坐标。它只是一种能在坐标系统中提高绘制精度的手段。提示 我们这里所说的触摸判定机制hit test是指一种判断点是不是处于视图之中的机制而不是指名字看上去与之相似的hitTestwithEvent方法。这个方法用于返回视图体系中包含某个点的最顶层视图topmost view也就是距离用户及屏幕最近的视图。它会在每个视图上面调用pointInsidewithEvent。如果pointInside方法返回YES那么它就会沿着视图体系继续向下判断。