Why is the top portion of my UISegmentedControl not tappable?

Question

While I was playing on my phone, I noticed that my UISegmentedControl was not very responsive. It would take 2 or more tries to make my taps register. So I decided to run my app in Simulator to more precisely probe what was wrong. By clicking dozens of times with my mouse, I determined that the top 25% of the UISegmentedControl does not respond (the portion is highlighted in red with Photoshop in the screenshot below). I am not aware of any invisible UIView that could be blocking it. Do you know how to make the entire control tappable?

self.segmentedControl = [[UISegmentedControl alloc] initWithItems:[NSArray arrayWithObjects:@"Uno", @"Dos", nil]];
self.segmentedControl.selectedSegmentIndex = 0;
[self.segmentedControl addTarget:self action:@selector(segmentedControlChanged:) forControlEvents:UIControlEventValueChanged];
self.segmentedControl.height = 32.0;
self.segmentedControl.width = 310.0;
self.segmentedControl.segmentedControlStyle = UISegmentedControlStyleBar;
self.segmentedControl.tintColor = [UIColor colorWithWhite:0.9 alpha:1.0];
self.segmentedControl.autoresizingMask = UIViewAutoresizingFlexibleLeftMargin | UIViewAutoresizingFlexibleRightMargin;

UIView* toolbar = [[UIView alloc] initWithFrame:CGRectMake(0, 0, self.view.width, HEADER_HEIGHT)];
toolbar.autoresizingMask = UIViewAutoresizingFlexibleWidth;
CAGradientLayer *gradient = [CAGradientLayer layer];
    gradient.frame = CGRectMake(
        toolbar.bounds.origin.x,
        toolbar.bounds.origin.y,
        // * 2 for enough slack when iPad rotates
        toolbar.bounds.size.width * 2,
        toolbar.bounds.size.height
    );
    gradient.colors = [NSArray arrayWithObjects:
        (id)[[UIColor whiteColor] CGColor],
        (id)[[UIColor 
            colorWithWhite:0.8
            alpha:1.0
            ] CGColor
        ],
        nil
];
[toolbar.layer insertSublayer:gradient atIndex:0];
toolbar.backgroundColor = [UIColor navigationBarShadowColor];
[toolbar addSubview:self.segmentedControl];

UIView* border = [[UIView alloc] initWithFrame:CGRectMake(0, HEADER_HEIGHT - 1, toolbar.width, 1)];
border.autoresizingMask = UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleTopMargin;
border.backgroundColor = [UIColor colorWithWhite:0.7 alpha:1.0];
border.autoresizingMask = UIViewAutoresizingFlexibleWidth;
[toolbar addSubview:border];

[self.segmentedControl centerInParent];

self.tableView.tableHeaderView = toolbar;

http://scs.veetle.com/soget/session-thumbnails/5363e222d2e10/86a8dd984fcaddee339dd881544ecac7/5363e222d2e10_86a8dd984fcaddee339dd881544ecac7_20140509171623_536d6fd78f503_68_896x672.jpg

Answer 1

As already written in other answers, UINavigationBar grabs the touches made near the nav bar itself, but not because it has some subviews extended over the edges: this is not the reason.

If you log the whole view hierarchy, you will see that the UINavigationBar doesn't extends over the defined edges.

The reason why it receives the touches is another:

in UIKit, there are many "special cases", and this is one of them.

When you tap the screen, a process called "hit testing" starts. Starting from the first UIWindow, all views are asked to answer two "questions": is the point tapped inside your bounds? what is the subviews that must receive the touch event?

this questions are answered by these two methods:

- (BOOL)pointInside:(CGPoint)point withEvent:(UIEvent *)event;
- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event;

Ok, now we can continue.

After the tap, UIApplicationMain starts the hit testing process. The hit test starts from the main UIWindow (and is executed even on the status bar window and the alert view window, for example), and goes through all subviews.

This process is executed 3 times:

• two times starting from UIWindow
• one times starting from _UIApplicationHandleEvent

If you tap on the Navigation Bar, you will see that hitTest on UIWindow will return the UINavigationBar (all three times)

If you tap on the area below the Navigation Bar however, you will se something strange:

• the first two hitTest will return your UISegmentedControl
• the last hitTest will return UINavigationBar

why this? If you swizzle and subclass UIView, overriding hitTest, you will see that the first two times the tapped point is correct. The third time, something changes the point doing something like point - 15 (or a similar number)

After a lot of searching, I have found where this is happening:

UIWindow has a (private) method called

-(CGPoint)warpPoint:(CGPoint)point;

debugging it, I saw that this method changes the tapped point if it is immediately below the status bar. Debugging more, I saw that the stack calls that make this possible, are only 3:

[UINavigationBar, _isChargeEnabled]
[UINavigationBar, isEnabled]
[UINavigationBar, _isAlphaHittableAndHasAlphaHittableAncestors]

So, at the end, this warpPoint method checks if the UINavigationBar is enabled and hittable, if yes it "warps" the point. The point is warped of a number of pixel between 0 and 15, and this "warp" increases when you get closer to the Navigation Bar.

Now that you know what happens behind the scenes, you have to know how to avoid it (if you want).

You can't simply override warpPoint: if the application must go on the AppStore: it's a private method and your app will be rejected.

You have to find another system (like as suggested, overriding sendEvent, but I'm not sure if it will work)

Because this question is interesting, I will think about a legal solution tomorrow and update this answer (one good starting point can be subclassing UINavigationBar, overriding hitTest and pointInside, returning nil/false if, given the same event over multiple calls, the point changes. But I must test if it works tomorrow)

EDIT

Ok, I've tried many solutions but it's not simple to find a legal and stable one. I've described the actual behavior of the system, that could vary on different versions (hitTest called more or less than 3 times, the warpPoint warping the point of about 15px that can change ecc ecc).

The most stable is obviously the illegal override of warpPoint: in a UIWindow subclass:

-(CGPoint)warpPoint:(CGPoint)point;
{
    return point;
}

however, I've found that a method like this (in UIWindow subclass) it's stable enough and does the trick:

- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event
{
    // this method is not safe if you tap the screen two times at the same x position and y position different for 16px, because it moves the point
    if (self.lastPoint.x == point.x)
    {
        // the points are on the same vertical line
        if ((0 < (self.lastPoint.y - point.y)) && ((self.lastPoint.y - point.y) < 16) )
        {
            // there is a differenc of ~15px in the y position?
            // if so, the point has been changed
            point.y = self.lastPoint.y;
        }
    }

    self.lastPoint = point;

    return [super hitTest:point withEvent:event];
}

This method records the last point tapped, and if the subsequent tap is at the same x, and an y different for max 16px, then uses the previous point. I've tested a lot and it seems stable. If you want, you can add more controls to enable this behavior only in particular controllers, or only on a defined portion of the window, ecc ecc. If I find another solution, I'll update the post