How to prevent chart from eating touches unnecessarily?


#1

I have a chart embedded in a scroll view, but when you drag up and down on the chart area the scroll-view doesn’t scroll - the chart eats the touches even though panning is not enabled on the y-axis. If implemented properly using gesture recognizers, they should be able to prevent the gesture recognizer from beginning when the initial touches don’t match a possible gesture. That is the gesture recognizer should transition from UIGestureRecognizerStatePossible straight to UIGestureRecognizerStateFailed when it realises that the touches are not in a direction that can be panned and the touches won’t be eaten, they will be sent up to the scroll-view for consumption. iOS already does a wonderful job of this, but how do I configure the chart to take advantage of it?


Shinobi chart not accessible when inside a scrollview
#2

Hi Jay,

Currently, we use a single gesture recognizer our chart panning movement. As you say, at the moment, it will always swallow gestures, unless you turn off chart panning completely.

Our chart’s gesture recognizers are all on the chart canvas’ overlay, and we have a single pan gesture recognizer on our chart that handles the chart panning. If we set a delegate on this gesture recognizer, we can tell the gesture recognizer not to begin unless the horizontal movement is greater than the vertical movement.

So, to set the delegate on your chart’s pan gesture recognizer you should do the following:

for (int x=0; x<_line.canvas.overlay.gestureRecognizers.count; x++)
 {
    UIGestureRecognizer *r = _line.canvas.overlay.gestureRecognizers[x];
            
    if ([r isKindOfClass:[UIPanGestureRecognizer class]])
    {
        r.delegate = self; // Or any delegate you desire.
    }
}

Now you can implement the -gestureRecognizerShouldBegin: delegate method and return NO if the gesture is a vertical pan. This will cause the gesture to propagate through to your scroll view.

Thanks,
Jan


#3

Ok, but to do it properly you’d need to use knowledge of the internal state of the chart. For example if the chart can scroll vertically then the gesture should be recognised within the chart and used, but if the chart can’t scroll vertically (maybe it is zoomed all the way out or maybe it has reached the edge of its range in that direction) then the gesture should not begin.

This knowledge/management of internal chart state should be handled by a chart controller, it seems somewhat fragile to put such controller code into 3rd party apps (our developer apps) which is dependent on implementation details of the chart view.


#4

Hi Jay,

I understand exactly where you are coming from. As you say, this isn’t supported directly by our API. I just wanted to point out a workaround that others have used to get around this issue.

Fortunately, we are planning to investigate into improving how we handle our gestures with respect to this.

Jan