I’m trying to take the android-wheel from http://code.google.com/p/android-wheel/ and make it display horizontally. My first attempt to make this happen came from a suggestion by the author himself http://android-devblog.blogspot.com/2010/05/wheel-ui-contol-backgrounds.html at the bottom of the comments section.
kankan: “The easy way: use the vertical wheel, but rotate the canvas before drawing. In this case it needs also to change the onTouch and swap x and y touch coordinates for scrolling.”
My implementation is very simple where I extend WheelView and just rotate the canvas by 90 degrees in the onDraw method (I’m not concerned with the touch portion, the wheel is not for interaction). Unfortunately all it does is turn the numbers themselves on their side, the wheel window stays vertical.
Does anyone have any experience with horizontalizing the wheelview?
I think the question is pretty clear and can only guess why some respondents are confused. You asked how to make the Vertical Wheel component at http://code.google.com/p/android-wheel/ behave with horizontal gestures and scrolling, as described by the author (and restated in your question).
I’ve recently done this in my own project.
First of all, the author’s assertions merely provide a conceptual framework. In practice significantly more work is involved to realize. To make the HorizontalWheel I extended WheelView AND WheelScroller and wrote code to override ALL of the logic in both classes based on height. To do this some fields in WheelView and WheelScroller needed getters/setters; as well some constants and methods needed to be accessible and set as protected or public instead of private so they could be overridden. For example, WheelView does not provide a way to inject a WheelScroller or set a custom ScrollingListener.
Finally, there’s a fundamental problem in the design of the component that I’ve been struggling with throughout the customization. I’m struggling with the problem now. The component fundamentally treats the list of Views it contains as having a “current item” == the View in the middle of the widget. It measures scrolling and justification based on the midpoint of the View that is closest to the center of the widget. This gives the widget the snap-to-middle effect. The snap effect is nice if there are shadows that only permit one element to show. However, deviate from that use-case, say you want more than one item to be visible between the shadows or want a different snap behavior and you’ll run into problems. The Component’s view-recycler also doesn’t support multiple View types.
I’ve fixed most of these things and will publish soon. If given a chance I’d rebuild this component to call the first fully-visible item == first_item. Then I’d do away with the concept of “current item” because it only makes sense for the use-case in the screenshots and makes extending and customizing the component needlessly more difficult. Undoutedly snap-to-middle, left, and right seem like required features too, and should be configurable.