resueltos - herramientas de android studio pdf
¿No puede anular el recurso xml de la biblioteca con el recurso png en la aplicación? (3)
Así que una "solución" a este problema, que no considero una respuesta, es la siguiente:
Defina un documento XML en la biblioteca en cuestión (lo llamaremos bunny.xml) y haga que se refiera a otro xml de un nombre similar (bunny_drawn.xml) con el contenido real que se mostrará.
Luego, en el proyecto de destino, anule bunny.xml con otro y utilícelo para referirse a una imagen con un nombre diferente en su lugar: bunny_image.png
Sin embargo, esto no resuelve el problema, en primer lugar porque no estamos anulando técnicamente a un png con un xml (aunque el efecto es algo parecido a eso). En segundo lugar, porque una de las características clave de los recursos de anulación es que están anulados, es decir, NO se compilan en la APK:
las herramientas aseguran que el recurso declarado en la aplicación tenga prioridad y que el recurso en el proyecto de la biblioteca no se compile en la aplicación .apk
¡Pero el bunny_drawn.xml todavía será compilado en! Podemos superar el segundo punto, no solo definiendo la imagen que se reemplazará en la aplicación de destino, sino también reemplazando el antiguo destino bunny_drawn.xml con un xml en blanco. (o, como señaló Fenix, puede tener el contenido de bunny_drawn.xml dentro de bunny.xml en el primer caso; todavía existe el hecho de que el ID del recurso no puede ser reemplazado ...)
Así que mi conclusión final es que esta necesidad debe enviarse como un error en las Herramientas de desarrollo.
Tengo una biblioteca de Android MyLib
contiene todo lo que necesito para mi aplicación (dirigida a Android 2.2). Esta biblioteca tiene un recurso XML:
drawable/main_background.xml
En mi proyecto de aplicación MyApp
, hago referencia a MyLib
. Aquí quiero anular los recursos específicos (es decir, la marca). Así que agregué una imagen de fondo en MyApp
:
drawable/main_background.png
Eclipse me sigue dando este error:
[com.mycom.mylib.myapp] res/drawable/main_background.xml:0: error: Resource entry main_background is already defined.
[com.mycom.mylib.myapp] res/drawable/main_background.png:0: Originally defined here.
¿Cómo puedo anular el recurso en el proyecto de la biblioteca?
No puede simplemente anular la ID del recurso (es la ID del recurso que está anulando, no el archivo real) con un archivo con una extensión diferente en el SDK de Android. Sin embargo, puede hacer el truco colocando el archivo xml de su proyecto con el mismo nombre ( main_background.xml
) y completarlo de manera adecuada para mostrar su nuevo archivo ( main_background.png
), que debe cambiar de nombre antes. Toda la sintaxis que necesita se describe aquí:
http://developer.android.com/guide/topics/resources/drawable-resource.html
, en su caso, podría ser simple (suponiendo que ponga esto en su proyecto no de biblioteca como main_background.xml
, y tenga su nuevo png como main_background_new.png
):
<?xml version="1.0" encoding="utf-8"?>
<bitmap
xmlns:android="http://schemas.android.com/apk/res/android"
android:src="@drawable/main_background_new" />
Con la solución anterior, puede referirse a @drawable/main_background
de su proyecto y debería usar su archivo incluido con ese proyecto, en lugar de uno de la biblioteca.
[com.mycom.mylib.myapp] res/drawable/main_background.xml:0: error: Resource entry main_background is already defined.
[com.mycom.mylib.myapp] res/drawable/main_background.png:0: Originally defined here.
No creo que puedas tener el mismo nombre de archivo, incluso con diferentes extensiones. Intenta nombrar el png algo más.
Ahora, no he usado la anulación, así que esto parece extraño, ya que uno esperaría que esto sea la forma en que anula el activo. Sin embargo, creo que tienes los dos recursos en tu biblioteca con el mismo nombre. Y que en su proyecto podría estar bien tener un activo con el mismo nombre. Sin embargo, me gustaría comprobar que está bien tener diferentes tipos. XML es diferente a png, y si accede al activo desde el código, podría obtener errores de tipo.
Permítanme aclarar el punto anterior. Entiendo que un proyecto de biblioteca puede tener un elemento con la misma ID de recurso que un elemento en su aplicación.
Sin embargo, el error anterior sugiere que main_background.png y main_background.xml están en el mismo proyecto ([com.mycom.mylib.myapp]) que no creo que sea correcto.
Otras lecturas
Esta página describe los distintos tipos de proyectos, incluido el proyecto de biblioteca http://developer.android.com/tools/projects/index.html
Ahora no sé de dónde obtuve la impresión, pero después de haber mirado de nuevo, simplemente no dice en ninguna parte que pueda anular un recurso usando el mismo nombre de recurso. Dios sabe por qué pensé que era una característica.
Así que no, la misma regla se aplica, por lo que puedo decir, que los recursos deben tener un nombre único incluso en los proyectos de la biblioteca, de lo contrario, los identificadores de recursos generados entrarán en conflicto. (El error que está consiguiendo)
Lo que se explica es cómo se gestionan los conflictos de recursos.
Conflictos de recursos Dado que las herramientas combinan los recursos de un proyecto de biblioteca con los de un proyecto de aplicación dependiente, un ID de recurso dado podría definirse en ambos proyectos. En este caso, las herramientas seleccionan el recurso de la aplicación o la biblioteca con la prioridad más alta y descartan el otro recurso. A medida que desarrolle sus aplicaciones, tenga en cuenta que es probable que las ID de recursos comunes se definan en más de un proyecto y que se fusionen, y que el recurso de la aplicación o la biblioteca de prioridad más alta tenga prioridad.
El sistema utilizará el recurso con la mayor prioridad, descartando todo lo demás. Lo que es extraño, es que usted pensaría que no se produciría un error de compilación, ya que el compilador debería descartar el recurso. Esto me hace creer que el póster original tenía los activos con el mismo nombre en el mismo proyecto, y no en la biblioteca y el proyecto.
No he leído en ninguna parte que esta sea realmente una característica prevista. ¿Tienes algún enlace para decir lo contrario? (coméntelos)