Question

I’m looking for a widget that behaves similar to the gallery widget but scrolls vertically instead of horizontally. I googled all around and apparently the answer is no such pre-made widget exists.

So I said myself, oh well, I’ll look at the gallery class in the android source and modify that to scroll vertically instead. Not so easy. The android SDK hides a lots away (understandably for framework maintenance), but it also makes it very hard to extend the widgets. The gallery class, for example, use a lots of member variable from its parent, AbsSpinner (mSelectedPosition, etc.etc.), and its parent’s parent, etc… which are not at all accessible from the app-developer’s standpoint. Without access to those member variable, I cannot use similar code from gallery class for my own use.

Short of moving up the inheritance chain and put the source code of those parent classes all in my project, or writing the widget all from scratch without using the existing framework widgets that already solved the problem, I can’t find a way to get a vertical scrolling gallery.

Is there a better way around? Why does the android framework make extending widget so difficult?

Answer 1

Is there a better way around?

Since we don’t know what you are building, that’s impossible to say. I agree with Yoni Samlan’s comment that a ListView may be sufficient for your needs.

Why does the android framework make
extending widget so difficult?

While it is conceivable that a reimplemented Gallery might make it simpler for you to make it orient differently, the core Android team has to weigh such reimplementation against other development priorities.

One of those priorities is SDK fidelity. They want to make sure that, to the greatest extent possible, code written for Android 1.5 can run on Android 2.1 without modification. This limits them in two ways. First, they cannot just change the existing Gallery, for example, to accommodate your desires, if doing so causes them to break their existing API. Second, the core Android team will not expose new methods or classes, even if those might be beneficial to third-party developers, unless and until the team is ready to support those methods or classes for the long haul.

Android was initially written before an SDK existed. That’s the reason given for why most of the built-in applications (e.g., calculator) cannot be built with the SDK alone, but needs to be built as part of a firmware image. Similarly, the core Android team had to make a decision, as part of creating the initial SDK, of how best to take the existing code and create public stuff we can work with and protected/private stuff we cannot, with SDK fidelity in mind. As you may have noticed, Android is vast, and so creating the SDK must have taken a correspondingly vast amount of staff time. Rewriting lots of it to increase the odds that somebody could, say, create a vertical Gallery wasn’t probably high on their list.

In an ideal world, yes, we would be able to more readily extend built-in widgets and significantly modify their behavior. Similarly, in an ideal world, I would have hair… 🙂