2010-02-20 16 views
6

Estoy buscando un widget que se comporte de manera similar al widget de la galería, pero se desplaza verticalmente en lugar de horizontalmente. Busqué en Google todo y aparentemente la respuesta es que no existe ese widget prefabricado.Android: ¿una galería vertical?

Así que me dije, bueno, voy a mirar a la clase en la galería de la fuente androide y modificar ese lugar para desplazarse verticalmente. No tan fácil. El SDK de Android se esconde un montón (comprensiblemente para el mantenimiento del marco), pero también hace que sea muy difícil extender los widgets. La clase de galería, por ejemplo, usa una gran cantidad de variables miembro de su elemento primario, AbsSpinner (mSelectedPosition, etc.etc.), Y el elemento primario de sus padres, etc., que no son del todo accesibles desde el punto de vista del desarrollador de la aplicación. Sin acceso a esa variable miembro, no puedo usar un código similar de la clase de la galería para mi propio uso.

A falta de moverme por la cadena de herencia y poner el código fuente de esas clases principales en mi proyecto, o escribir el widget desde cero sin usar los widgets de framework existentes que ya resolvieron el problema, no puedo encontrar un forma de obtener una galería de desplazamiento vertical.

¿Hay una mejor manera alrededor? ¿Por qué el marco de Android hace que la extensión del widget sea tan difícil?

+1

Dependiendo del comportamiento que necesita, ¿por qué no usar simplemente un ListView normal, dentro de un LinearLayout horizontal con un ImageView en el otro lado? –

Respuesta

12

¿Hay una mejor manera alrededor?

Dado que no sabemos lo que está construyendo, eso es imposible de decir. Estoy de acuerdo con el comentario de Yoni Samlan de que un ListView puede ser suficiente para sus necesidades.

¿Por qué hacer el marco androide widget de se extiende tan difícil?

Si bien es concebible que un reimplementado Gallery podría hacer más fácil para que usted pueda hacer que orientar de manera diferente, el equipo de Android núcleo tiene que sopesar tales reimplementación frente a otras prioridades de desarrollo.

Una de las prioridades es la fidelidad SDK. Quieren asegurarse de que, en la mayor medida posible, el código escrito para Android 1.5 se pueda ejecutar en Android 2.1 sin modificaciones. Esto los limita de dos maneras. Primero, no pueden simplemente cambiar el existente Gallery, por ejemplo, para acomodar sus deseos, si al hacerlo causa que rompan su API existente. En segundo lugar, el equipo principal de Android no expondrá nuevos métodos o clases, incluso si pueden ser beneficiosos para desarrolladores externos, a menos y hasta que el equipo esté listo para admitir esos métodos o clases a largo plazo.

Android fue escrito antes de que existiera un SDK. Esa es la razón por la cual la mayoría de las aplicaciones integradas (por ejemplo, la calculadora) no se pueden compilar con el SDK solo, sino que se deben crear como parte de una imagen de firmware. Del mismo modo, el equipo central de Android tuvo que tomar una decisión, como parte de la creación del SDK inicial, sobre cómo tomar el código existente y crear material público con el que podamos trabajar y cosas protegidas/privadas que no podemos, teniendo en cuenta la fidelidad del SDK. Como habrás notado, Android es enorme, por lo que la creación del SDK debe haber requerido una gran cantidad de tiempo del personal. Reescribir muchos de ellos para aumentar las probabilidades de que alguien pudiera, por ejemplo, crear un Gallery vertical, probablemente no estaba en lo más alto de su lista.

En un mundo ideal, sí, que sería capaz de extender más fácilmente los widgets integrados y modificar significativamente su comportamiento. Del mismo modo, en un mundo ideal, tendría pelo ...:-)

+9

+1 por, 'Del mismo modo, en un mundo ideal, tendría pelo ... :-)' – Samuel

Cuestiones relacionadas