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:
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.