Propagate gesture events to containing controller (ShinobiCharts)


My Shinobi chart is contained in a scroll view.

The user can navigate to another page by swiping horizontally.

However, as the chart takes up most of the page the swiping functionality is not very useful anymore, since the chart “swallows” all gestures.

Is there a way to propagate gestures to the containing controller?

Note that I still want my chart to be interactive. The chart segments need to be tapable and ideally those nice rotating effects should also still be possible.


Any idea?



Your correct about the chart swallowing the gestures. It isn’t possible to have the chart responding to panning gestures and to also have your scroll view to receive those gestures,  it doesn’t really make sense from a usability point of view. This is similar to how a scroll view nested within a scrollview would work.

What you can do (which is what I think you were asking) is disable the panning gesture recogniser. You can do this by like so:

chart.gesturePanType = SChartGesturePanTypeNone;

If you need to keep the panning functionality, then you can’t really do the above. In that case, we find that adding some kind of handle for the user to drag works quite well.

Jan Akerman


Hi Jan, I tried setting the gesture pan type to none before, that doesn’t help. The swipe gestures are still swallowed by the chart.  :cry:


Is  there any other workaround? I just want to be able to put my pie chart in a scroll view and keep the ability to tap on each slice.


Hi Boo-lee,

I can’t think as to what would be swallowing your gestures after following the above advice. Would you be able to send in a cut down project to that demonstrates the issue that you are having (or upload the project to a file hosting site and post a link)? If you email in, could you please refer to this forum post.

This will help me investigate your issue. Thanks!


Hi Jan,

Here is a test project that demonstrates the swiping issue:

The test project also “demonstrates” the data source refresh issues reported in another thread (labels of old data source values are not always removed), so maybe you can also look into that problem.  :wink:


Hi Jan,

Were you able to reproduce my two issues with this sample project?


Hi Boo-lee,

I’ve looked into your project and it seems that there is a bit of an issue with how the panning gesture recognizer (the regonizer responsible for spinning the chart) work on pie / donut series. Currently, you cannot turn this off (unlike other chart types). A fix for this should be included in the next release, but until then, here are a few tips that you might find helpful:

  • Try keeping your charts frame as small as possible, as to maximise scroll view space.
  • If you have a legend on your chart, try explicitly setting its frame, this will cause it to leave the flow of the chart. This might allow you to make your charts frame smaller. (You can also add the legend as a sub view of another view.)
  • Add a handle that your users can drag.
  • Consider using some other method of selection. For example, you could have a smaller scroll view underneath your chart scroll view, showing images, when the user selects the image that corresponds to a chart, you could programatically set the offset of your chart scroll view to the correct chart.
  • Disabling user interaction will allow you to use your scroll view exactly how you wish (at the expensive of interactivity!  :scream:).

I hope you manage to find a work-around until we manage to release a fix to this issue, and that the above suggestions might have helped you in some way.



Ok, Jan. Looking forward to the next release …

In the meantime I will indeed use a workaround by keeping the chart’s frame as small as possible.

Can you also look into the issue with the chart label refresh problem? That bug is a big “no go” for my customer.  :cry:



If I make the frame as small as possible to fit in the pie chart, the rendering animation is ugly because it is “boxed” within the frame.

I tried setting the chart’s Layer.MaskToBounds property to false but that didn’t help.

Do you know how to handle this?


Hi Boo-lee,

The issue with the labels has been previously reported and we have a fix scheduled to be included in the next major release, sorry for forgetting to mention that!

As for your animation, setting the maskToBounds property wouldn’t help as we are drawing the chart on our GL canvas, which will always be clipped. Changing the clipsToBounds property helps for UIKit elements, such as axis labels and annotations. The default animations we provide should scale relative to the frame of the chart. Are you using a custom animation? If so you might want to make your animation smaller so that it doesn’t get clipped. 

Would it be possible for you to post a screen shot of the issue too? Just so I understand exactly what your problem is.




Hi Jan,

Thanks for you reply. In the meantime, I read the Shinobi tutorials on animation and managed to customize my animation in a way that nothing is clipped.

I was using the standard “bounce” animation curve where at a certain point of time during the animation, the chart was shown larger than its actual size making it bigger than its assigned frame. I implemented a custom curve to solve the problem.

While I’m having your attention :wink: , and I know it’s off topic, but would you also want to take a look at the question I posted in this thread:

It’s not a bug I guess, but I just don’t know why I cannot programmatically select a slice in a chart after creation. And it’s a feature I need in my app.

Thank you!


Actually it is possible in iOS to have a pan gesture recognizer in an inner view (the chart) and still work for the outer-view (the scroll view) - only if the inner one is implemented correctly.

So shinobi guys - here’s how to do it…

  1. Set a UIGestureRecognizerDelegate for the pan GR and implement this:

    • (BOOL)gestureRecognizerShouldBegin:(UIPanGestureRecognizer*)panGR
      CGPoint trans = [panGR translationInView:self.view];
      CGPoint startPos = CGPointSubtract([panGR locationInView:self.view], trans);
      // The GR is ready to start, but it is confirming with you first -
      // There are situations that you should return NO:
      // - If the start-point not inside an interactive area (e.g. the donut part on a donut chart)
      // - If the chart is already at its limit in the direction of panning (see trans)
      // etc…

Also, I think if you subclass the gesture recognizer then it can transition itself to the failed state if the chart reaches a limit during a gesture, allowing the touches to go elsewhere - haven’t used this technique for a while though and it might have been a custom gesture, not a pan-subclass. Alternatively it can be disabled and re-enbaled (with panGR.enabled = NO; panGR.enabled = YES;) to force it to end.

Hope this helps.


Didn’t want to drag this old thread out of the grave, but I wanted to post this thread here for others that may come stumble upon the same issue. It is essentially a workaround inspired by Jay. We are still looking at improving our API to allow users to modify the behaviour of our gesture recognizers.