Android - multiple charts inside scroll view


#1

I have multiple charts inside a LinearLayout inside a HorizontalScrollView. The charts are set to scroll/zoom only on the yAxis, and I was hoping to be able to swipe sideways to scroll inside the HorizontalScrollView, but it appears the charts are intercepting all motion events.

I think each chart should look at whether only one of the directions is enabled for panning/zooming and not intercept events that don’t conform to that direction.

Nesting scrollable containers is a tricky problem, for an example on how this could work, check out ScrollView or HorizontalScrollView’s onInterceptTouchEvent or this project: https://github.com/sephiroth74/HorizontalVariableListView.

Is there an ETA on when something like this could be implemented?


#2

Hi Radu,

The issue here is your definition of “events that don’t conform to that direction.”. All user gestures will contain some element of motion in both the X and Y direction - I know that it is mathematically quite possible for the motion in on direction to be zero, but for all practical purposes this statement holds.

At the component level we make no assumptions about the meaning of user gestures beyond what the chart recognizes. We have no way of knowing whether a small horizontal motion is meaningful to your app or not. Your required behaviour is application specific and will need to be handled in your code. To make this possible we provide listener interfaces at various levels. The onAxisRangeChangeListener interface

http://www.shinobicontrols.com/docs/ShinobiControls/ShinobiChartsAndroid/1.3.2/Premium/Normal/apidocs/docs/reference/com/shinobicontrols/charts/ShinobiChart.OnAxisRangeChangeListener.html

gives you access to the results of pan and zoom gestures, but I think you will find onGestureListener

http://www.shinobicontrols.com/docs/ShinobiControls/ShinobiChartsAndroid/1.3.2/Premium/Normal/apidocs/docs/reference/com/shinobicontrols/charts/ShinobiChart.OnGestureListener.html

as it gives you direct access to the motions on the gestures, so that you can extract the components you require and act according to the requirements of your app.

As far as building this kind of behaviour into the chart framework, it is not on our roadmap, and there is no ETA for implementing it.

Best regards,

Robin Sillem


#3

I fully agree with the X and Y both being not zero. However, if you take a quick peek in ScrollView for example: http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.4.2_r1/android/widget/ScrollView.java#ScrollView.onInterceptTouchEvent(android.view.MotionEvent)

The correct behavior that allows containers scrolling in different directions to be nested on Android is to properly implement this onInterceptTouch behavior. That’s how we can have a ScrollView inside a HorizontalScrollView.

The way this is done is based on whether there’s more movement on one axis than another. For example, once movement on the Y axis has passed a certain threshold and if it is greater than movement on the X axis, the ScrollView will return true from onInterceptTouchEvent which will cause all future events for this touch to be only dispatched to the ScrollView. For an example on how this would work in action, open any app’s page on Google Play and see how the screenshots “grab” movement on the X axis and all future moves will only affect scrolling the screenshots. Consequently, if the movement is on the Y axis on the screenshots, the ScrollView will latch onto this event and all future movement will be dispatched there.

Also, I agree that the app library has no way of knowing whether motion is meaningful to the app or not - that’s exactly why I’m proposing to do things the right Android way. There’s plenty of examples in the Android SDK, including ListView, HorizontalScrollView, etc:

http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/2.2_r1.1/android/widget/AbsListView.java#AbsListView.onInterceptTouchEvent(android.view.MotionEvent)

I was just hoping for the same kind of behavior to be built into ShinobiCharts so I don’t have to do custom event creation and dispatching on every screen where I use a chart that scrolls in a single direction. 

I understand if you think this may be low priority and not willing to implement it - is there a way you could allow users (like me) to add our own custom onInterceptTouchEvent behavior? For example, expose the actual view class that implemetns ShinobiCharts so that I can subclass it (from what I can see, ChartView only wraps the actual ShinobiChart)?

I also understand you’re trying to build a product and have to make hard priority calls - however, I do believe something like this will only make the library better and closer to “the principle of least surprise”. Especially as your the Android version of your library gains more traction.

I don’t know what’s your process for this, but I’d be willing to implement this the right way and share the code with you if that means it will make it in the library. Please contact me privately if you’d be interested in this.

Thanks. 


#4

I have a simplified version (no need to track velocity for example) of what ScrollView does that works for one of my own views that does vertical scrolling and zooming. Please contact me privately if you’re interested in pursuing this. If I get a release from clause 3.1.4 in your trial licensing agreement (considering I’m doing this to make the software interoperate with my software program) I’m confident I can get this to work with your chart and then I can share the code with you.

Cheers,

Radu


#5

Hi Radu,

Thanks for the very clear response. Looking at it that way it does indeed appear to be a general improvement rather than anything specific to your app, and we’re convinced.

While I appreciate the offer, we’d rather make the changes ourselves. There’s a lot of behaviour (including crosshairs etc) which depends on the gestures, not all of which is view-based, and the level to which we expose the internals of the chart is carefully chosen to minimise the risk of extensive support load. This is a key concern for us, as support is handled by the core development team. Historically the support load is primarily generated by less technically adept customers than yourself, so we favour simple APIs with tighly controlled extensibility, though this sometimes imposes more work on those who are able to customize the controls.

Having got that disclaimer out of the way, the required changes look reasonably simple and low risk.  We’ll take a look at it, and if this turns out to be the case we’ll try to get the fix into the next release (V1.4). If you’re still happy to show us your solution on that basis we’d certainly like to see it, if only to make sure we haven’t missed any subtlties that you have caught - just email to info@shinobicontrols.com.

Best regards,

Robin