Android 101: o sobre cómo complicar las estructuras de un proyecto

Bien, si todo fue cómo esperábamos en el post anterior ( y confío en vosotros) ya tenemos un entorno adecuado de trabajo (lo siento chicos Solaris, muy probablemente vosotros no estáis en la lista...guaguaguaguaaaaa -sonido de trompetas-).

Aunque es muy posible que después explique cómo hacer todo esto desde la shell (atención expertos en python, os sentiréis como en casa), de momento vamos a hacerlo a lo perro (no me seáis malpensado, a partir de ahora en vuestras sucias mentes a lo perro==fácil, sencillo o simple), vamos a utilizar el plugin.

Veamos, ejecutamos desde "Fichero>Nuevo >Proyecto android" el asistente para nuestro nuevo proyecto:

• Nombre del proyecto: nombre del proyecto en eclipse, sin repercusion en la aplicacion pero de alguna forma se tendrá que llamar (por cierto, no duplicar el nombre de los proyectos en eclipse en el mismo workspace). Así se llamará el apk a instalar (el símil de android a los jar de java).
  
• Nombre de la aplicación: nombre con el que se visualizará la aplicacion en el manager de gphone y que la distinguirá de las demás aplicaciones. Este campo es puramente visual, si que se puede repetir, aunque después no podras distinguir cuál es cuál (el que avisa no es traidor).
  
• Nombre de la actividad: nombre de la clase inicial a crear por el asistente.
  
• Nombre del paquete: este es el punto más curioso; debido a que la máquina virtual dalvik cataloga las aplicaciones instaladas en el móvil a través del paquete dentro del cual han sido creadas (lo cual no implica que todas las clases que compongan una aplicacion estén en el mismo paquete, aunque sería recomendable para garantizar la unicidad de las clases, es decir, que no se machaquen por ejemplo arias versiones de una misma clase). Concluyendo, que el paquete es el identificador único de la aplicación, tened cuidado con eso ⁽¹⁾.

Veamos, por ejemplo le pondremos al proyecto:

• Nombre del proyecto: ProyectoTest
• Nombre de la actividad: Actividad.
• Nombre de la aplicacion: AplicacionTest
• Nombre paquete: mi.paquete.test1

Obtendremos la siguiente estructura en el proyecto eclipse 'ProyectoTest':


Y al ejecutarlo como una aplicación android, (Run as>Android Application) el emulador nos devolverá (tras pasar algunos segundos cargando el ojo de cylon⁽²⁾) obtendremos esto:



Bueno, realmente aquí lo que nos interesa es una primera perspectiva de la estructura creada (requerida a menos que generemos nuestro propio constructor):

• src (sources - fuentes): este punto no merecería la pena ser comentado si no fuera porque el asistente se ha sacado de la manga una clase llamada R.java. Esta clase es regenerada en cada actualización en eclipse por la herramienta de sdk aapt⁽³⁾. De momento contiene:
  
  

  
  /* AUTO-GENERATED FILE.  DO NOT MODIFY.
   *
   * This class was automatically generated by the
   * aapt tool from the resource data it found.  It
   * should not be modified by hand.
   */
  
  package mi.paquete.test1;
  
  public final class R {
      public static final class attr {
      }
      public static final class drawable {
          public static final int icon=0x7f020000;
      }
      public static final class layout {
          public static final int main=0x7f030000;
      }
      public static final class string {
          public static final int app_name=0x7f040000;
      }
  }
  

  
  Es decir, una clase por cada carpeta dentro de res que reconozca la herramienta y un identificador numérico único para cada recurso.
• res (resources - recursos): clasifica los distintos recursos de la aplicación que vienen catalogados de acuerdo a lo incluido en R.java. Aunque puede tener más, que veremos en el próximo post, por defecto tiene las carpetas:
• drawable: imagenes (para incluirlas en R NO tiene en cuenta su extensión, así que dos imágenes con la misma extensión serán mal referenciadas por R).
• layout: conjunto de archivos xml para determinar los widgets que estarán incluidos en cada Actividad, es decir, estores de la visualización de los elementos en lugar de hacerlo a través del código.
• values: conjunto de elementos xml utilizados para agrupar valores (lo veremos en el próximo post); de momento sólo contiene el string con el nombre que le pusimos a la aplicacion (AplicacionTest).
• AndroidManifest.xml: este archivo es vital, encapsula toda las información válida de las clases android que compondrán la aplicación. De hecho, si una actividad no está escrita aquí no podrá ser invocada (startActivity o startSubActivity). Este pto lo vemos dentro de dos post (se cumula el trabajo...lalala).
  
• assets (asset- recurso) serán los recursos no catalogados dentro de R, la única diferencia con res (de momento) es que están desestructurados y no poseen referencia algunas; dependerá del programador cómo guardarlos).

Para que este post no se haga eterno, acabo aquí, gracias por aguantar apañaos.

---

⁽¹⁾ - Este puede ser un error muy frecuente y muy tonto: una de las cosas buenas de emulador de la sdk de android es que las aplicaciones instaladas no son eliminadas de la memoria, lo cual permite simular el ciclo de vida completo de una aplicación. Pero, si por un casual se nos ocurre cambiar el nombre del proyecto y ejecutarlo sobre el emulador con el antiguo proyecto cargado, nos surgirá la siguiente advertencia:
WARNING: Package mi.paquete.test1 is already registered by /data/app/ProyectoTest.apk
(ya que al no llamarse igual el plugin de eclipse no lo desinstala en instala como haría en caso normal) y dejando sin cargar la ultima versión en el emulador, aunque éste es lanzado (con la versión anterior todavía instalada).
⁽²⁾ - Ojo de cylon, expresión tomada prestada de la serie BattleStar Galactica, que viene a ser la bolita roja con estela a modo ojo de Kitt del coche fantástico, que han puesto los desarrolladores del emulador para emular que carga (y sé que se toma su tiempo, tened calma).
⁽³⁾ Las herramientas que incluye la sdk las veremos un poco más adelante cuando veamos como construir a mano una aplicación; de momento diremos que es magia.