Sólo se le podía ocurrir a un symio

Impresiona como de desafortunadas pueden ser algunas campañas publicitarias, no he contrastado si esto es cierto(es decir, puede que esto sea una leyenda urbana), pero al parecer existe una nueva campaña de symio orientada a la comunidad gay...lo que no sé es si sólo pensaban descartar esta comunidad como clientes en potencia, si es que el concepto de captar clientes no es el mismo que el mío o si la agencia de publicidad al completo bebía demasiado (o demasiado poco)...porque manda cojones la campaña

Hay un segundo ADC

Aparte de la segunda ronda del ADC actual existirá otra, bajo unas condiciones semejantes, a finales de este año, dada la acogida que por lo visto ha tenido el concurso... de acuerdo con uno de los desarrolladores:

"...There are two Challenges, which we call Challenge 1 and Challenge 2. Each

of these is allocated half of the $10,000,000 fund. Challenge 1 is the one
going on right now; Challenge 2 will begin later this year, after Challenge
1 has concluded.

Challenge 1, meanwhile, is broken into two parts and has two deadlines. The
first deadline is for anyone to submit an application (according to the
eligibility rules); this is the April 14th deadline, and we call it Round
1. Judges will then evaluate and choose the best submissions, and those
developers will receive $25,000. They'll also be given a period of time --
which we call Round 2 -- to further polish their applications, and submit
the new versions by a second deadline. The winners of the final, larger
prizes will be chosen out of the Round 2 submissions. Only developers who
are awarded a prize in Round 1 will be eligible to submit for Round 2.

To summarize: Challenge 1 has two phases, Round 1 and Round 2. Only
winners of Round 1 may participate in Round 2. Challenge 2 will begin later
this year, and will be a totally separate event. "

Así que preparaos para lo peor , XDDD

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.

Android 101: receta e ingredientes

Lo prometido es deuda (aunque sólo sea para mi misma), he intentado empezar a escribir esto unas 10 veces, tengo ya varios borradores para post posteriores, pero es que me da siempre la impresión de que si se parte desde cero hace falta tenerlo todo a punto y saber cómo hacerlo.

Para eso os dejo la siguiente receta de cómo poner android a punto, junto con los siguientes ingredientes:

1. Eclipse 3.2 o superior (inferiores abstenerse)
2. Java 5 (no basta sólo con la JDK, ya que el emulador corre sobre java)
3. SDK de android
4. Plugin de android para eclipse (ojo, lo que hay en esta referencia es el repositorio a colocar en eclipse que se explicará más abajo, si lo intentáis bajar no ubicará la página).
5. Buen humor (porqué no)
6. Si teneis Solaris, será necesario que lo hagáis vosotros mismos con la SDK, así que a bajar el código y a compilar con paciencia
   

Pasos:

1. Instalar java [1,2,3]
2. Instalar eclipse [1], en caso de que ya exista en el pequeño universo de tu ordenador, por favor, asegúrate que los plugins de JDT y WST.
   
3. Descomprimir la SDK de android.
4. Abrir eclipse e instalar el plugin:
1. Help > Software updates> Find and install >Search for new features to install> New remote site: y aquí ponemos el repositorio, el resto estoy segura de que es piece of cake para vosotros.
5. Configurar el plugin: no merece la pena asustarse, sólo hay que ponerle la ruta donde se extrajo la sdk (en Windows>Preferences)
6. Et voilá. Para testearlo cread una aplicación, cuya estructura veremos en el próximo post, que es completamente operativa sobre el emulador desde el principio.
   

Sé que para lo que escribí en otros posts que iba a hacer no es demasiado, pero al menos es algo.

Os veo pronto.

Sin palabras

Ordenador android