Event handling for iOS - how hitTest:withEvent: and pointInside:withEvent: are related?

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:

1. hitTest:withEvent: is called on A, the top-most view of the view hierarchy.
2. pointInside:withEvent: is called recursively on each view.
3. pointInside:withEvent: is called on A, and returns YES
4. pointInside:withEvent: is called on B, and returns NO
5. pointInside:withEvent: is called on C, and returns YES
6. pointInside:withEvent: is called on D, and returns YES
7. 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.
8. 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.

I find this Hit-Testing in iOS to be very helpful

- (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;
}

1. We should not send touch events for hidden or transparent views, or views with userInteractionEnabled set to NO;
2. If touch is inside self, self will be considered as potential result.
3. Check recursively all subviews for hit. If any, return it.
4. 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:

1. Import category in your subclassed view.
2. 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;
}

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)
}

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

https://i.stack.imgur.com/LLKhr.png" height="450">

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" height="350"> https://i.stack.imgur.com/24jH5.jpg" height="350">

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

https://i.stack.imgur.com/QN10u.png" width="700">

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

[Android onTouch]