While most apple documents are very well written, I think 'Event Handling Guide for iOS' is an exception. It's hard for me to clearly understand what's been described there.
The document says,
In hit-testing, a window calls hitTest:withEvent: on the top-most view of the view hierarchy; this method proceeds by recursively calling pointInside:withEvent: on each view in the view hierarchy that returns YES, proceeding down the hierarchy until it finds the subview within whose bounds the touch took place. That view becomes the hit-test view.
So is it like that only hitTest:withEvent:
of the top-most view is called by the system, which calls pointInside:withEvent:
of all of subviews, and if the return from a specific subview is YES, then calls pointInside:withEvent:
of that subview's subclasses?
I think you are confusing subclassing with the view hierarchy. What the doc says is as follows. Say you have this view hierarchy. By hierarchy I'm not talking about class hierarchy, but views within views hierarchy, as follows:
+----------------------------+
|A |
|+--------+ +------------+ |
||B | |C | |
|| | |+----------+| |
|+--------+ ||D || |
| |+----------+| |
| +------------+ |
+----------------------------+
Say you put your finger inside D
. Here's what will happen:
hitTest:withEvent: is called on A, the top-most view of the view hierarchy. pointInside:withEvent: is called recursively on each view. pointInside:withEvent: is called on A, and returns YES pointInside:withEvent: is called on B, and returns NO pointInside:withEvent: is called on C, and returns YES pointInside:withEvent: is called on D, and returns YES On the views that returned YES, it will look down on the hierarchy to see the subview where the touch took place. In this case, from A, C and D, it will be D. D will be the hit-test view
It seems quite a basic question. But I agree with you the document is not as clear as other documents, so here is my answer.
The implementation of hitTest:withEvent:
in UIResponder does the following:
It calls pointInside:withEvent: of self
If the return is NO, hitTest:withEvent: returns nil. the end of the story.
If the return is YES, it sends hitTest:withEvent: messages to its subviews. it starts from the top-level subview, and continues to other views until a subview returns a non-nil object, or all subviews receive the message.
If a subview returns a non-nil object in the first time, the first hitTest:withEvent: returns that object. the end of the story.
If no subview returns a non-nil object, the first hitTest:withEvent: returns self
This process repeats recursively, so normally the leaf view of the view hierarchy is returned eventually.
However, you might override hitTest:withEvent
to do something differently. In many cases, overriding pointInside:withEvent:
is simpler and still provides enough options to tweak event handling in your application.
hitTest:withEvent:
of all subviews are executed eventually?
hitTest:withEvent:
in your views (and pointInside
if you want), print a log and call [super hitTest...
to find out whose hitTest:withEvent:
is called in which order.
I find this Hit-Testing in iOS to be very helpful
https://i.stack.imgur.com/FL27E.png
- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event {
if (!self.isUserInteractionEnabled || self.isHidden || self.alpha <= 0.01) {
return nil;
}
if ([self pointInside:point withEvent:event]) {
for (UIView *subview in [self.subviews reverseObjectEnumerator]) {
CGPoint convertedPoint = [subview convertPoint:point fromView:self];
UIView *hitTestView = [subview hitTest:convertedPoint withEvent:event];
if (hitTestView) {
return hitTestView;
}
}
return self;
}
return nil;
}
Edit Swift 4:
override func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? {
if self.point(inside: point, with: event) {
return super.hitTest(point, with: event)
}
guard isUserInteractionEnabled, !isHidden, alpha > 0 else {
return nil
}
for subview in subviews.reversed() {
let convertedPoint = subview.convert(point, from: self)
if let hitView = subview.hitTest(convertedPoint, with: event) {
return hitView
}
}
return nil
}
Thanks for answers, they helped me to solve situation with "overlay" views.
+----------------------------+
|A +--------+ |
| |B +------------------+ |
| | |C X | |
| | +------------------+ |
| | | |
| +--------+ |
| |
+----------------------------+
Assume X
- user's touch. pointInside:withEvent:
on B
returns NO
, so hitTest:withEvent:
returns A
. I wrote category on UIView
to handle issue when you need to receive touch on top most visible view.
- (UIView *)overlapHitTest:(CGPoint)point withEvent:(UIEvent *)event {
// 1
if (!self.userInteractionEnabled || [self isHidden] || self.alpha == 0)
return nil;
// 2
UIView *hitView = self;
if (![self pointInside:point withEvent:event]) {
if (self.clipsToBounds) return nil;
else hitView = nil;
}
// 3
for (UIView *subview in [self.subviewsreverseObjectEnumerator]) {
CGPoint insideSubview = [self convertPoint:point toView:subview];
UIView *sview = [subview overlapHitTest:insideSubview withEvent:event];
if (sview) return sview;
}
// 4
return hitView;
}
We should not send touch events for hidden or transparent views, or views with userInteractionEnabled set to NO; If touch is inside self, self will be considered as potential result. Check recursively all subviews for hit. If any, return it. Else return self or nil depending on result from step 2.
Note, [self.subviewsreverseObjectEnumerator]
needed to follow view hierarchy from top most to bottom. And check for clipsToBounds
to ensure not to test masked subviews.
Usage:
Import category in your subclassed view. Replace hitTest:withEvent: with this
- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event {
return [self overlapHitTest:point withEvent:event];
}
Official Apple's Guide provides some good illustrations too.
Hope this helps somebody.
It shows like this snippet!
- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event
{
if (self.hidden || !self.userInteractionEnabled || self.alpha < 0.01)
{
return nil;
}
if (![self pointInside:point withEvent:event])
{
return nil;
}
__block UIView *hitView = self;
[self.subViews enumerateObjectsWithOptions:NSEnumerationReverse usingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
CGPoint thePoint = [self convertPoint:point toView:obj];
UIView *theSubHitView = [obj hitTest:thePoint withEvent:event];
if (theSubHitView != nil)
{
hitView = theSubHitView;
*stop = YES;
}
}];
return hitView;
}
iOS touch
1. User touch
2. event is created
3. hit testing by coordinates - find first responder - UIView and successors (UIWindow)
3.1 hit testing - recursive find the most deep view
3.1.1 point inside - check coordinates
4. Send Touch Event to the First Responder
Class diagram
3 Hit Testing
Find a First Responder
First Responder
in this case is the deepest UIView
point()
(hitTest()
uses point()
internally) method of which returned true. It always go through UIApplication -> UIWindow -> First Responder
func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView?
func point(inside point: CGPoint, with event: UIEvent?) -> Bool
Internally hitTest()
looks like
func hitTest() -> View? {
if (isUserInteractionEnabled == false || isHidden == true || alpha == 0 || point() == false) { return nil }
for subview in subviews {
if subview.hitTest() != nil {
return subview
}
}
return nil
}
4 Send Touch Event to the First Responder
//UIApplication.shared.sendEvent()
//UIApplication, UIWindow
func sendEvent(_ event: UIEvent)
//UIResponder
func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?)
func touchesMoved(_ touches: Set<UITouch>, with event: UIEvent?)
func touchesEnded(_ touches: Set<UITouch>, with event: UIEvent?)
func touchesCancelled(_ touches: Set<UITouch>, with event: UIEvent?)
Let's take a look at example
https://i.stack.imgur.com/FvbjU.png
Responder Chain
It a kind of chain of responsibility
pattern. It consists of UIResponser
who can handle UIEvent
. In this case it starts from first responder who overrides touch...
. super.touch...
calls next link in responder chain
Responder chain
is also used by addTarget
or sendAction
approaches like event bus
//UIApplication.shared.sendAction()
func sendAction(_ action: Selector, to target: Any?, from sender: Any?, for event: UIEvent?) -> Bool
Take a look at example
class AppDelegate: UIResponder, UIApplicationDelegate {
@objc
func foo() {
//this method is called using Responder Chain
print("foo") //foo
}
}
class ViewController: UIViewController {
func send() {
UIApplication.shared.sendAction(#selector(AppDelegate.foo), to: nil, from: view1, for: nil)
}
}
*isExclusiveTouch
is taken into account when handling multitouch
The snippet of @lion works like a charm. I ported it to swift 2.1 and used it as an extension to UIView. I'm posting it here in case somebody needs it.
extension UIView {
func overlapHitTest(point: CGPoint, withEvent event: UIEvent?) -> UIView? {
// 1
if !self.userInteractionEnabled || self.hidden || self.alpha == 0 {
return nil
}
//2
var hitView: UIView? = self
if !self.pointInside(point, withEvent: event) {
if self.clipsToBounds {
return nil
} else {
hitView = nil
}
}
//3
for subview in self.subviews.reverse() {
let insideSubview = self.convertPoint(point, toView: subview)
if let sview = subview.overlapHitTest(insideSubview, withEvent: event) {
return sview
}
}
return hitView
}
}
To use it, just override hitTest:point:withEvent in your uiview as follows:
override func hitTest(point: CGPoint, withEvent event: UIEvent?) -> UIView? {
let uiview = super.hitTest(point, withEvent: event)
print("hittest",uiview)
return overlapHitTest(point, withEvent: event)
}
Success story sharing
hitTest:withEvent:
of B, C and D are also invoked. What happens if D is a subview of C, not A? I think I got confused...A
returnYES
as well, just asC
andD
does?