android - ¿Cuál es el concepto detrás de R.java?
architecture android-resources (4)
En Android R.java se utiliza para proporcionar acceso a recursos definidos en archivos XML. Para acceder al recurso necesitamos invocar el método findViewById() pasando el id del recurso que se va a buscar.
Esto es similar a Spring, donde los beans se definen en un contexto XML y se obtienen utilizando el contexto de la aplicación. context.getBean("beanId")
Esto proporciona un acoplamiento flexible ya que los granos están definidos externamente y podrían cambiarse sin modificaciones en el código.
Esto me tiene confundido. Aunque lo que hace Android parece similar a la primavera, ¿qué ventaja ofrece?
- ¿De qué sirve tener un R.java intermedio de todos modos? ¿No podríamos simplemente adquirir recursos directamente de XML mediante el uso de un lector de recursos / contexto de aplicación. por ejemplo,
findViewById("resourceId")- No hay ningún acoplamiento flojo. Como las referencias en R.java se generan automáticamente, ¿cómo se puede eliminar un recurso y poner uno nuevo?
- ¿Qué patrón de diseño sigue (si lo hay)?
- ¿No sería mejor tener recursos inyectados usando IOC (como Roboguice)? ¿Por qué entonces Google decidió darnos una forma tan extraña de trabajar con recursos?
Perdonen mi ignorancia Soy un desarrollador Java novato que intenta demasiadas cosas a la vez. :-) Gracias por todos los comentarios.
La comparación se siente un poco extraña (de hecho) , porque se comparan dos mecanismos basados en el hecho de que usan cosas con nombre para hacer cosas. Para la carga de recursos, por ejemplo, eche un vistazo a cómo se hace el manejo de recursos en el mundo de .Net .
Proporciona comprobación en tiempo de compilación si el recurso está disponible. Porque si no, no habrá una estática dentro de R.java que lo señale. En el ejemplo de Spring, ¿cómo puede estar seguro de que hay un bean llamado beanId ? Sin embargo, no proporciona la verificación de si es el tipo correcto de recurso.
¿Por qué esto no está suelto? Siempre que el nuevo recurso tenga el mismo nombre, generará la misma constante estática. En Spring, deberías usar el mismo nombre de bean.
¿Patrón de diseño? Ninguna. Simplemente agrega un nivel de direccionamiento indirecto al nombrar los recursos y luego se refiere a ellos solo por su nombre , no al cargarlos directamente desde su ubicación real.
En realidad, los recursos se inyectan, porque la carga de recursos debe hacer frente a la localización. Vea here cómo Android hace cosas; en el mundo de .Net , las culturas adicionales se empaquetan en ensamblajes de satélite; el administrador de recursos cargará el correcto según la cultura actual.
La mayor ventaja está en la localización y en la provisión de recursos alternativos para diferentes tamaños de pantalla.
por ejemplo, puede tener un recurso String R.string.myname podría estar definido en inglés en /values-en/strings.xml y en español en /values-es/strings.xml
El sistema se encargará o recogiendo el archivo correcto dependiendo de la configuración regional. Solo necesita usar @string/myname en su archivo de diseño o R.string.myname en su código.
Del mismo modo, podría tener dos archivos de diseño para retrato y paisaje definidos en
res/layout/mylayout.xml
res/layout-land/mylayout.xml
En su código, solo deberá especificar R.layout.mylayout para inflar el diseño. El administrador de recursos recoge el archivo en layout-land si el dispositivo está en modo horizontal.
Hacer esto manualmente sería una pesadilla, de ahí la necesidad de un archivo R
También contiene acceso a recursos, como identificación, elementos extraíbles, diseños, cadenas, matrices y básicamente todo lo que pueda declarar en recursos.
android.R.java no es solo donde se almacenan los identificadores XML . También contiene acceso a los recursos, como elementos dibujables, diseños, cadenas, matrices y básicamente todo lo que puede declarar en recursos.
Personalmente encuentro que es útil cuando se usa Eclipse. Simplemente puedo escribir findViewById(R.id. Y Eclipse mostrarán una información sobre herramientas con una lista de opciones para elegir).
Sin embargo, a nivel de plataforma, diría que las variables de id. Codificadas ayudan a evitar errores cuando se utilizan cadenas para identificar recursos, algo que se puede depurar durante la programación (o durante la compilación, en lugar del tiempo de ejecución).