Graphics Reference
In-Depth Information
Touch Events
You may have also noticed that we can now see the button on the third face. If you press it,
nothing happens. Why is that?
It's not because iOS cannot correctly transform the touch events to match the button
position in 3D; it's actually quite capable of doing that. The problem is the
view order.
As
we mentioned briefly in Chapter 3, touch events are processed according to the order of
views within their superview, not their Z-position in 3D space. When we added our cube
face views, we added them in numeric order, so faces 4, 5, and 6 are in front of face 3 in the
view/layer order.
Even though we can't see faces 4, 5, and 6 (because they are obscured by faces 1, 2, and 3),
iOS still gives them first dibs on touch events. When we try to tap the button on face 3, face
5 or 6 (depending on where we tap) is intercepting the touch event, just as it would if we
had placed it in front of the button in a normal 2D layout.
You might think that setting
doubleSided
to
NO
might help here, as it would render the
rearward facing views invisible, but unfortunately that doesn't help; views that are hidden
because they are facing away from the camera will still intercept touch events (unlike views
that are hidden using the
hidden
property, or by setting their
alpha
to zero, which
don't), so disabling double-sided rendering won't help with this issue (although it might be
worth doing anyway for performance reasons).
There are a couple of solutions to this: We could set
userInteractionEnabled
to
NO
on all of our cube face views except face 3 so that they don't receive touches. Or we could
simply add face number 3 to the view hierarchy
after
face number 6 in our program. Either
way, we will then be able to press the button (see Figure 5.23).
Figure 5.23
Now the background views aren't blocking the button, we can press it.
