Cuando hay un cambio de orientación, si la actividad no maneja el cambio de orientación, probablemente sea destruida y recreada. Entonces ¿Qué pasa con el ProgressDialog?.

Iniciemos con dos reglas que debemos seguir:

1. Si va a crear el AsyncTask dentro de la actividad como un inner class, asegúrese de que sea estática. Las inner class no estáticas, guardan una referencia de la outer class, en nuestro caso, la Actividad. Esto quiere decir que estamos “filtrando” (leaking) memoria, pues esa referencia de la actividad queda ahi mientras siga vivo el AsyncTask, y esto hay que evitarlo.
2. Para crear el ProgressDialog, utilice los métodos que tiene disponible la actividad. Me refiero a onCreateDialog, showDialog y dismissDialog. Esto por que a la hora de cambiar la orientación de la pantalla y al destruir y recrear la actividad, Android va a mantener el estado de los dialogs que estaban presentes y se encargará de mostrarlos nuevamente cuando la actividad es recreada.

El consenso es utilizar el método onRetainNonConfigurationInstance, para “guardar” la referencia del AsynctTask, así, cuando la nueva actividad es creada, ella se dará cuenta si la tarea todavia está en progreso, para poder “acoplarse” a ella.

public class EjemploProgressDialogActivity extends Activity {
    public static final String TAG = "EXAMPLE_DIALOG";

    public static final int PROGRESS_DIALOG = 1;

    MyTask task;

    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        Log.d(TAG, "onCreate");
        Object obj = getLastNonConfigurationInstance();
        if (obj != null && obj instanceof MyTask) {
            Log.d(TAG, "Tarea previa ejecutandose");
            task = (MyTask) obj;
            task.attach(this);
        } else {
            task = new MyTask(this);
            task.execute(10);
            Log.d(TAG, "Nueva tarea creada y ejecutada");
        }
    }

    @Override
    protected Dialog onCreateDialog(int id) {

        switch (id) {
        case PROGRESS_DIALOG:
            ProgressDialog pd = new ProgressDialog(this);
            pd.setTitle("Trabajando");
            pd.setMessage("Por favor espere...");
            return pd;

        default:
            break;
        }
        return super.onCreateDialog(id);
    }

    @Override
    protected void onPause() {
        super.onPause();
        Log.d(TAG, "onPause");
    }

    @Override
    protected void onRestart() {
        super.onRestart();
        Log.d(TAG, "onRestart");

    }

    @Override
    protected void onResume() {
        super.onResume();
        Log.d(TAG, "onResume");
    }

    @Override
    protected void onStart() {
        super.onStart();
        Log.d(TAG, "onStart");
    }

    @Override
    protected void onStop() {
        super.onStop();
        Log.d(TAG, "onStop");
    }

    @Override
    public Object onRetainNonConfigurationInstance() {
        // Aqui es donde se hace la magia
        if (task != null) {
            task.deattach();
            return task;
        }
        return super.onRetainNonConfigurationInstance();
    }

    private static class MyTask extends AsyncTask {
        WeakReference ctx;

        public MyTask(Activity activity) {
            super();
            attach(activity);
        }

        @Override
        protected void onPreExecute() {
            Activity activity = ctx.get();
            if (activity != null && !activity.isFinishing()) {
                Log.d(TAG, "Mostrando Progress Dialog");
                activity.showDialog(PROGRESS_DIALOG);
            }
        }

        @Override
        protected Void doInBackground(Integer... params) {
            int seconds = params[0];
            try {
                Log.d(TAG, "Tarea va a durar " + seconds + " segundos");
                Thread.sleep(seconds * 1000);
                Log.d(TAG, "Tarea Lista");
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            return null;
        }

        @Override
        protected void onPostExecute(Void result) {
            if (ctx != null && ctx.get() != null) {
                Activity activity = ctx.get();
                if (!activity.isFinishing()) {
                    Log.d(TAG, "Ocultando Progress Dialog");
                    activity.dismissDialog(PROGRESS_DIALOG);
                }
            }
        }

        public void attach(Activity activity) {
            this.ctx = new WeakReference(activity);
        }

        public void deattach() {
            ctx = null;
        }

    }
}

En la línea 14, pueden ver que en el método onCreate se pregunta si se salvó algún objeto previamente y luego se hacen los chequeos respectivos para asegurarse que el objeto sea el AsyncTask. En este ejemplo en particular, se crea el AsyncTask en el método onCreate, por lo que en el caso de que no exista, se crea.

En la línea 18 se ejecuta el método attach,para que el AsyncTask tenga la nueva referencia de la Actividad.

En la línea 77 que es el momento en que la actividad da su último suspiro, el AsyncTask se desacopla y se “salva” la referencia al AsyncTask para que la siguiente actividad (si es el caso) la retome, como vimos en el método onCreate.

Si ven la implementación del AsyncTask, primero que todo, se guarda la referencia a la actividad dentro de un WeakReference, para así evitar “filtrar” memoria.

En los métodos onPreExecute y onPostExecute se hacen validaciones para asegurarse de que la referencia de la actividad sea válidad (que exista la referencia y que la actividad no esté en proceso de morirse).

Si ejecutáramos éste código,  sin mover el dispositivo, esta sería la salida en la bitácora:

10-04 21:54:46.254: DEBUG/EXAMPLE_DIALOG(6155): onCreate
10-04 21:54:46.294: DEBUG/EXAMPLE_DIALOG(6155): Mostrando Progress Dialog
10-04 21:54:46.514: DEBUG/EXAMPLE_DIALOG(6155): Tarea va a durar 10 segundos
10-04 21:54:46.514: DEBUG/EXAMPLE_DIALOG(6155): Nueva tarea creada y ejecutada
10-04 21:54:46.514: DEBUG/EXAMPLE_DIALOG(6155): onStart
10-04 21:54:46.524: DEBUG/EXAMPLE_DIALOG(6155): onResume
10-04 21:54:56.518: DEBUG/EXAMPLE_DIALOG(6155): Tarea Lista
10-04 21:54:56.524: DEBUG/EXAMPLE_DIALOG(6155): Ocultando Progress Dialog
10-04 21:55:12.395: DEBUG/EXAMPLE_DIALOG(6155): onPause
10-04 21:55:12.554: DEBUG/EXAMPLE_DIALOG(6155): onStop

Pero si cambiamos la orientación del dispositivo, esto sería el resultado:

te
10-04 21:56:08.584: DEBUG/EXAMPLE_DIALOG(6155): Mostrando Progress Dialog
10-04 21:56:08.754: DEBUG/EXAMPLE_DIALOG(6155): Nueva tarea creada y ejecutada
10-04 21:56:08.754: DEBUG/EXAMPLE_DIALOG(6155): onStart
10-04 21:56:08.754: DEBUG/EXAMPLE_DIALOG(6155): Tarea va a durar 10 segundos
10-04 21:56:08.764: DEBUG/EXAMPLE_DIALOG(6155): onResume
10-04 21:56:10.424: DEBUG/EXAMPLE_DIALOG(6155): onPause
10-04 21:56:10.424: DEBUG/EXAMPLE_DIALOG(6155): onStop
10-04 21:56:10.544: DEBUG/EXAMPLE_DIALOG(6155): onCreate
10-04 21:56:10.544: DEBUG/EXAMPLE_DIALOG(6155): Tarea previa ejecutandose
10-04 21:56:10.544: DEBUG/EXAMPLE_DIALOG(6155): onStart
10-04 21:56:10.704: DEBUG/EXAMPLE_DIALOG(6155): onResume
10-04 21:56:18.755: DEBUG/EXAMPLE_DIALOG(6155): Tarea Lista
10-04 21:56:18.755: DEBUG/EXAMPLE_DIALOG(6155): Ocultando Progress Dialog
10-04 21:56:21.626: DEBUG/EXAMPLE_DIALOG(6155): onPause
10-04 21:56:21.784: DEBUG/EXAMPLE_DIALOG(6155): onStop

Imprimí además cuando se ejecutan otros métodos del ciclo de vida, para tener una referencia de cuando ocurre qué.

El “bug” es que ciertos layouts, pueden provocar que el teclado virtual (o softkeyboard) se active tan pronto como la actividad (o ventana) toma foco (se coloca en la pila de ventananas). Según mis pruebas, (que pueden ver en el post) todo pasa cuando el layout tiene un widget contenedor, llámese un ListView, GridView, Gallery, etc. y debajo de él un campo de texto. Esta combinación, parece provocar, en ciertos devices como el HTC Desire  y el LG GX2, ambos con Android 2.2, la activación del softkeyboad.

El mes pasado puse una pregunta en el grupo de google para Desarrolladores de Android (ver pregunta aquí), pero lo único que me contestaron fue como “mitigarlo”.

Dentro de las recomendaciones que me hicieron, fue que creara un repositorio con el código, para que otras personas pudieran probarlo. Pueden bajar el código en Github:

https://github.com/fr4gus/AndroidSoftKeyboardBug

Me gustaría saber si alguien más lo puede replicar, con cual o cuales devices y si tiene alguna idea de si es un bug o no.

-f4

El otro tip del que les quería hablar con los AsyncTask es más que todo recalcar la importancia de implementar expícitamente la lógica dentro del método doInBackground que permita cancelar el AsyncTask.

Si recuerdan de la parte uno, el AsyncTask guarda una referencia “debil” de la actividad que lo ejecuta. Además, verifica que la Actividad este siendo ejecutada con normalidad, es decir, que la actividad no esté siendo terminada.

Con el código de la parte uno, si el usuario se sale de dicha actividad, vamos a tener el hilo de la actividad corriendo hasta que termine con lo que estaba haciendo. Esto puede  representar un problema ya que tenemos un AsyncTask ejecutandose sin necesidad. Esto es un gasto tanto en procesamiento, memoria, como en la posibilidad de ejecutar otras AsyncTask (recordemos que existe un límite).

La solución a esto es, si la actividad no ha terminado y ya no la ocupamos más, podamos llamar el método calcel(boolean). Esto provocará que el método isCancelled regrese “true”, además, para asegurar que onCancelled() sea llamado en vez de onPostExecute(Object), es importante checkear isCancelled dentro de doInBackground, asegurando que la tarea termine lo más pronto posible.

Por ejemplo:

public class MyActivity extends Activity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        // Inicialización de la actividad, layout, etc
        MyLongTask task = new MyLongTask(this);
        task.execute("http://blog.fr4gus.com/api/test.json");
    }

    @Override
    protected void onPause() {
        // Persistamos cualquier cosa que ocupemos
    }

    static class MyLongTask extends AsyncTask<String, Void, Void> {
        WeakReference<MyActivity> context;

        public MyLongTask(MyActivity activity) {
            context = new WeakReference<MyActivity>(activity);
        }

        @Override
        protected void onPreExecute() {
            // Avísele al usuario que estamos trabajando
        }

        @Override
        protected Void doInBackground(String... params) {
            while(! isCancelled() ){
            // Aquí hacemos una tarea laaarga
            // Y ademas chequeamos que la tarea no ha sido cancelada

            }
            return null;
        }

        @Override
        protected void onPostExecute(Void result) {
            MyActivity activity = context.get();
            if (activity != null && !activity.isFinishing()) {
                // Aquí actualizamos la UI con el resultado
            }
        }
    }

}

Los AsyncTask son una herramienta muy util, pero también nos pueden perjudicar si no sabemos utilizarlas correctamente. Pueden provocar leaks de memoria, o uso de recursos innecesariamente. El hecho de que para Android Honeycomb hayan regresado al esquema original con un solo hilo, indica que la idea es que hayan pocos hilos actualizando la interface. De todas maneras hay que aprovechar otras herramientas similares como el método runOnUiThread o los Handlers. La idea es minimizar los riesgos y aprovechar los recursos al máximo.

El AsyncTask es ampliamente utilizado para ejecutar tareas “simples” o “atómicas” en un hilo aparte. Su ciclo de ejecución es bastante intuitivo y práctico, comparado con el uso de la clase Handler. En Android 1.5, los AsyncTask eran encolados y un único hilo se encargaba de ejecutarlos uno por uno. A partir de 1.6 hasta Android 2.3.4 (inclusive), los AsyncTask son ejecutados cada uno, por un hilo aparte (sin asegurar su orden). Aqui la clase AsyncTask maneja una cola de ejecución de 10 hilos(dato no confirmado) y una cola de 10 hilos en espera (aunque según Roman Guy aquí, ese límite ya no existe, aunque no indica en que versión :-/), dándonos aproximádamente 20 AsyncTask “simultáneos”. Cuando este límite se excede, se dispara la excepción RejectedExecutionException. Está planeado despues de Honeycomb (Android 3.0), volver a la ejecución sencilla, para evitar los errores de ejecución paralela.

Esta clase es muy útil pero a la vez se convierte, probablemente, en una de las mayores fuentes de memory leaks y application crashes (Force Close) en Android, por parte de desarrolladores que omitan ciertas prácticas a la hora de usar dicha clase. En este primer artículo hablaremos primero sobre los Inner clases y cómo definir una AsycTask adecuadamente.

1. Inner clases

Tal vez la razón número uno de leaks en una aplicación Android son las Inner classes dentro de una clase Activity. Las Inner class, tienen una referencia implícita hacia la Outer class. Cuando se crea un AsyncTask, la tendencia es hacerlas dentro de la Actividad donde la ocupamos. Veamos un ejemplo

public class MyActivity extends Activity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        // Inicialización de la actividad, layout, etc
        MyLongTask task = new MyLongTask();
        task.execute("http://blog.fr4gus.com/api/test.json");
    }

    @Override
    protected void onPause() {
        // Persistamos cualquier cosa que ocupemos
    }

    class MyLongTask extends AsyncTask<String, Void, Void>{

        @Override
        protected void onPreExecute() {
            // Avísele al usuario que estamos trabajando
        }

        @Override
        protected Void doInBackground(String... params) {
            // Aquí hacemos una tarea laaarga
            return null;
        }

        @Override
        protected void onPostExecute(Void result) {
            // Aquí actualizamos la UI con el resultado
        }
    }

}

El problema es que éstas inner classes no-estáticas no tienen un ciclo de vida controlado por el desarrollador. La solución está en hacer las classes Inner, estáticas, y pasarle la referencia de la actividad o contexto, pero envolviéndola dentro de un WeakReference. Esto permitirá al Garbage Collector, liberar la memoria del Activity aunque el AsyncTask siga ejecutándose. Es importante que a la hora de usar el WeakReference, se aseguren que la referencia al Activity sea aun válida, verificando que no sea nula y que la activdad no esta terminando.

public class MyActivity extends Activity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        // Inicialización de la actividad, layout, etc
        MyLongTask task = new MyLongTask(this);
        task.execute("http://blog.fr4gus.com/api/test.json");
    }

    @Override
    protected void onPause() {
        // Persistamos cualquier cosa que ocupemos
    }

    static class MyLongTask extends AsyncTask<String, Void, Void> {
        WeakReference<MyActivity> context;

        public MyLongTask(MyActivity activity) {
            context = new WeakReference<MyActivity>(activity);
        }

        @Override
        protected void onPreExecute() {
            // Avísele al usuario que estamos trabajando
        }

        @Override
        protected Void doInBackground(String... params) {
            // Aquí hacemos una tarea laaarga
            return null;
        }

        @Override
        protected void onPostExecute(Void result) {
            MyActivity activity = context.get();
            if (activity != null &#038;&#038; !activity.isFinishing()) {
                // Aquí actualizamos la UI con el resultado
            }
        }
    }

}

Parte 2

Fuentes

1. Documentación de Android sobre memory leaks http://developer.android.com/resources/articles/avoiding-memory-leaks.html
2. Límite de ejecución de los AyncTask: http://stackoverflow.com/questions/2492909/asynctask-rejectedexecutionexception-and-task-limit
3. Implementación de AyncTaskEx de CommonsGuy: https://github.com/commonsguy/cwac-task

public class MyGallery extends Gallery{

  public MyGallery(Context context, AttributeSet attrs, int defStyle){
    super(context, attrs, defStyle);
  }

  public MyGallery(Context context, AttributeSet attrs){
    super(context, attrs);
  }

  public MyGallery(Context context){
    super(context);
  }

  @Override
  public boolean onFling(MotionEvent e1, MotionEvent e2, float velocityX,
      float velocityY){
    return true;
  }

}

Para que obtengamos el siguiente comportamiento: Fuentes:

1. http://stackoverflow.com/questions/4968426/android-gallery-horrizontal-scroll-rate
2. http://developer.android.com/reference/android/widget/Gallery.html

Botón dentro de un EditText

La respuesta para la ingcógnita de ¿Cómo se hace? es : imposible usando los componentes nativos de Android . Otra opción es que usted sea un experimentado desarrollador, con ganas de crear componentes nuevos podría usted crear un componente propio que lo haga.

¿Qué pasa con el resto de los mortales como nosotros? Podemos usar el siguiente “truco” (con el que se hizo la imagen anterior):

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
	android:orientation="vertical"
	android:layout_width="fill_parent"
	android:layout_height="fill_parent">
	<RelativeLayout
		android:layout_width="wrap_content"
		android:layout_height="wrap_content"
		style="@android:style/Widget.EditText">
		<EditText
			android:hint="Type here"
			android:layout_width="fill_parent"
			android:layout_height="wrap_content"
			android:layout_toLeftOf="@+id/SearchButton"
			android:background="@null"
			android:layout_centerVertical="true"/>
		<ImageButton
			android:layout_width="wrap_content"
			android:layout_height="wrap_content"
			android:layout_alignParentRight="true"
			android:id="@+id/SearchButton"
			android:src="@drawable/ic_menu_search"
			android:background="@null"/>
	</RelativeLayout>
</LinearLayout>

Básicamente lo que se hace en el XML, es aplicar el estilo de campo editable de texto @android:style/Widget.EditText al layout que contiene a los componentes que queremos agrupar, en este caso un EditText y un ImageButton. Luego hay que “quitarle” el fondo al EditText (o ponerle el fondo @null, como gusten llamarlo) para que se vuelta “transparente”.

http://code.google.com/p/android-logger/

Lo estamos usando en un proyecto en Schematic, y permite que usuarios no “techies” nos envíen los logs en caso de algún crash de la aplicación. Como la aplicación está aun en “beta”, y por lo tanto no disponible en el Android Market, se hacía difícil poder dar soporte en caso de errores de la aplicación.

Si es utilizado directamente en un archivo de layout, es probable que no de mucho problema, pero a la hora de crear componentes a base de este layout (utilizando el LayoutInflater) podrá notar que se comporta muy diferente. Particularmente con las alturas “ajustables”.

Buscando la razón me encontre este ticket en los bug reports de Android: http://code.google.com/p/android/issues/detail?id=1394 donde básicamente describen este problema y nos dan la solución. Utilizar altura y ancho fijos.

El siguiente layout

<?xml version="1.0" encoding="utf-8"?>
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
  android:layout_width="50dip"
  android:layout_height="50dip"
>
	<RelativeLayout
	  android:background="#FFFFFF"
	  android:layout_width="fill_parent"
	  android:layout_height="fill_parent">

	  <TextView
	  	android:text="1"
	  	android:textColor="#FF0000"
	  	android:layout_alignParentTop="true"
	  	android:layout_alignParentLeft="true"
	  	android:layout_width="wrap_content"
	  	android:layout_height="wrap_content" />
	  <TextView
	  	android:text="2"
	  	android:textColor="#FF0000"
	  	android:layout_alignParentTop="true"
	  	android:layout_alignParentRight="true"
	  	android:layout_width="wrap_content"
	  	android:layout_height="wrap_content" />
	  <TextView
	  	android:text="3"
	  	android:textColor="#0000FF"
	  	android:layout_alignParentBottom="true"
	  	android:layout_alignParentRight="true"
	  	android:layout_width="wrap_content"
	  	android:layout_height="wrap_content" />
	  <TextView
	  	android:text="4"
	  	android:textColor="#0000FF"
	  	android:layout_alignParentBottom="true"
	  	android:layout_alignParentLeft="true"
	  	android:layout_width="wrap_content"
	  	android:layout_height="wrap_content" />
	</RelativeLayout>
</FrameLayout>

Da como resultado este posicionamiento, normal, en el preview del layout en Eclipse.

Hemos utilizado un GridView con 10 Views que utilizan el layout anterior. Pero en vez de mostrarlo similar que en el preview, se muesta de la siguiente manera en un teléfono:

Como se citó anteriormente, al momento de ponerle altura fija directamente en la configuración del RelativeLayout, se resuelve el problema.

<?xml version="1.0" encoding="utf-8"?>
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
  android:layout_width="wrap_content"
  android:layout_height="wrap_content"
>
	<RelativeLayout
	  android:background="#FFFFFF"
	  android:layout_width="50dip"
	  android:layout_height="50dip">

	  <TextView
	  	android:text="1"
	  	android:textColor="#FF0000"
	  	android:layout_alignParentTop="true"
	  	android:layout_alignParentLeft="true"
	  	android:layout_width="wrap_content"
	  	android:layout_height="wrap_content" />
	  <TextView
	  	android:text="2"
	  	android:textColor="#FF0000"
	  	android:layout_alignParentTop="true"
	  	android:layout_alignParentRight="true"
	  	android:layout_width="wrap_content"
	  	android:layout_height="wrap_content" />
	  <TextView
	  	android:text="3"
	  	android:textColor="#0000FF"
	  	android:layout_alignParentBottom="true"
	  	android:layout_alignParentRight="true"
	  	android:layout_width="wrap_content"
	  	android:layout_height="wrap_content" />
	  <TextView
	  	android:text="4"
	  	android:textColor="#0000FF"
	  	android:layout_alignParentBottom="true"
	  	android:layout_alignParentLeft="true"
	  	android:layout_width="wrap_content"
	  	android:layout_height="wrap_content" />
	</RelativeLayout>
</FrameLayout>

Dando como resultado, el layout esperado:

Otra nota curiosa, es que esto solo es posible verlo en telefonos reales, ya que en los emuladores este problema no es posible replicarlo. Personalmente había visto este problema ocurrir solo en Android 2.1 (Eclair), pero a la hora de preparar este ejemplo, lo pude replicar tanto en un telefono con Eclair como con FroYo.

Introducción

Durante el Google IO 2010, una de las charlas que más me interesó fue la impartida por Justin Mattson llamada “Casting a wide net: how to target all Android devices” que trató de como hacer aplicaciones, que puedan ser usadas exitosamente, en todos los dispositivos Android. Puede que suene un poco audaz, pero sí es posible. Tenemos que tener claro que no para todas las aplicaciones es posible, pero se pueden tomar algunos consejos para poder permitir a la aplicación ser ejecutada, al menos, en la mayor cantidad de dispositivos posible.

Lamentablemente la charla fue corta, para la importancia del contenido por lo que quiero hacer esta serie de entradas, para explicar un poco más a detalle lo explicado en la presentación, basado tanto en el contenido de la misma, como en mi experiencia. Para ello, les explicaré con un ejemplo llamado Blue Monkey Eyes, una aplicación que hice para poder entender bien estos conceptos. La aplicación es bastante absurda, ya que no hace más que hacer ruidos, pero lo que veremos es el cómo se hizo.

Para esta primera parte discutiremos lo siguiente:

• Densidad o DPI (de sus siglas en inglés Dots per Inch)
• Resolución de pantallas (alto por ancho)
• Orientación (horizontal y vertical)

Densidad de Pantallas

En pocas palabras, cuantos puntos por pulgada hay en una superficie (dpi). No hay que confundir pixeles por pulgada (ppi). La importancia de la densidad es que esto permite que al crear una  imagen o texto tenga el mismo tamaño real, sin importar la resolución o tamaño físico de la pantalla. Veamos la siguiente imagen:

Ejemplo de independencia de densidad en WVGA de alta densidad (izq), HVGA media densidad (centro), y QVGA baja densidad (der). Tomado de Android Support Screens

Es importante que a la hora de diseñar los recursos de la aplicación, se defina bien los tamaños que se soportarán para así determinar la densidad o densidades y hacer un conjunto de recursos por cada uno. La plataforma Android nos permite definir carpetas por densidad de pantalla usando “calificadores” o “sufijos”. Para la densidad, están definidos 4 calificadores para la carpeta drawable:”-hdpi”, “-mdpi”, “-ldpi” y “nodpi”. Simplemente creamos las carpetas “drawable-[hpdi|mdpi|ldpi]” según las densidades que se soportarán. Es importante que los recursos mantengan el nombre a travéz de los folders, para que así la plataforma pueda hacer la selección sin problemas.

Estructura de carpetas

Existe una “pulga” o “bug” en la version 1.5 (SDK 3), ya que esta estructura de carpetas fue introducida hasta la versión 1.6. El problema con 1.5 es que puede escoger inadecuadamente el recurso, aunque éste se encuentre en la carpeta “drawable”. Para resolver esto, se debe agregar otro sufijo (después de -[hdpi|mdpi|ldpi]) a las carpetas que serán utilizadas para soportar diferentes densidades en dispositivos mayores a la version 3 del SDK. El sufijo a utilizar es “-v[4...n]” donde n es el número de SDK mínimo que la aplicación soportará para multi densidad y se deja “drawable” para que el SDK 3 tome las imágenes. Creo que esta mejor explicado en http://developer.android.com/guide/practices/screens_support.html#qualifiers.

Resolución de Pantallas

Actualmente, diferentes compañías han adoptado Android para la fabricación de dispositivos móviles, algunos de ellos son HTC (que sacó el primer dispositivo Android), Samsumg, Motorola entre otros. Debido a que no existe una estandariación en cuanto al hardware que soporta Android, tenemos a disposición diferentes modelos para diferentes necesidades. La visión de Google en cuanto dejar abierto a la innovación queda muy claro a este punto.  Tenemos los dispositivos tipo tablets a la vuelta de la esquina y no muy lejos Google TV que también se basará en android.

En la documentación oficial de Android se encuentra disponible una guía para poder soportar múltiples pantallas (http://developer.android.com/guide/practices/screens_support.html). Ahí definen “cajones” de como se dividen las pantallas y como se distribuye las densidades en ellas formando la siguiente matriz:

Android ofrece los calificadores “small”, “normal” y “large” para poder separar los recursos de acuerdo al tamaño de la pantalla.

Orientación Horizontal y Vertical

Tal vez una de las cualidades más discutidas en la comunidad Android, es la capacidad de cambiar el aspecto cuando se tiene el dispositivo de forma vertical o horizontal. Dentro de las preguntas más frecuentes que se puede leer en el grupo de usuarios de Android es como desactivar esta facilidad. Lo que recomienda Google es no pelear con él sino aprender a manejarlo.

Hay que tener bien claro que estoy no aplica para todas las aplicaciones. Por ejemplo, algunos juegos ocupan que a pesar de que se cambie la orientación del dispositivo, se mantenga todo como está, para evitar una experiencia de usuario pobre y por que el game play lo requiere así.

Si su aplicación requiere que se maneje tanto una orientación vertical (portrait) como horizontal (landscape), puede utilizar los calificadores “-port” y “-land” para la carpeta de layout.

La carpeta debiera verse así:

Folders Layout con calificador -land

Dando como resultado que la aplicación se vea así en ambas posiciones:

Posición por defecto, Vertical

Horizontal

Aqui el XML de ambos layouts.

Layout por defecto de Obey the Monkey

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
	xmlns:app="http://schemas.android.com/apk/res/com.fr4gus.android.blueeyesmonkey"
	android:orientation="vertical"
        android:layout_width="fill_parent"
	android:layout_height="fill_parent">
	<com.admob.android.ads.AdView android:id="@+id/ad"
		android:layout_width="fill_parent"
		android:layout_height="wrap_content"
		app:backgroundColor="#000000"
		app:primaryTextColor="#FFFFFF"
		app:secondaryTextColor="#CCCCCC"
		app:refreshInterval="15"
		app:keywords="Android Silly Application" />

	<ImageView android:id="@+id/ImageMonkey"
		android:layout_width="wrap_content"
		android:layout_height="wrap_content"
		android:src="@drawable/monkey_inactive"
		android:baselineAlignBottom="true"
		android:layout_gravity="center_vertical|center_horizontal" />

	<LinearLayout android:id="@+id/ButtonsLayout"
		android:layout_width="fill_parent"
		android:orientation="vertical"
		android:layout_height="wrap_content"
		android:layout_gravity="bottom|center_horizontal">
		<Button android:id="@+id/ObeyButton" android:layout_width="fill_parent"
			android:layout_height="wrap_content"
			android:text="@string/obeyButtonLabel"
			android:gravity="center_horizontal|center_vertical"
			android:background="@drawable/button_states"
			android:textColor="#FFFFFF" />
		<Button android:id="@+id/ListenButton"
			android:layout_width="fill_parent"
			android:layout_height="wrap_content"
			android:text="@string/listenButtonLabel"
			android:typeface="normal" android:textColor="#FFFFFF"
			android:background="@drawable/button_states" />
	</LinearLayout>
</LinearLayout>

Layout en modo landscape de Obey the Monkey

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
	xmlns:app="http://schemas.android.com/apk/res/com.fr4gus.android.blueeyesmonkey"
	android:orientation="vertical" android:layout_gravity="center_vertical|center_horizontal"
	android:layout_height="fill_parent" android:layout_width="fill_parent">
	<com.admob.android.ads.AdView android:id="@+id/ad"
		android:layout_width="fill_parent" android:layout_height="wrap_content"
		app:backgroundColor="#000000" app:primaryTextColor="#FFFFFF"
		app:secondaryTextColor="#CCCCCC" app:refreshInterval="15"
		app:keywords="Android Silly Application" />
	<LinearLayout android:id="@+id/contentLayout"
		android:layout_width="wrap_content" android:layout_height="wrap_content"
		android:orientation="horizontal" android:layout_gravity="right|center_vertical">
		<ImageView android:id="@+id/ImageMonkey"
			android:layout_width="wrap_content" android:layout_height="wrap_content"
			android:src="@drawable/monkey_inactive" android:layout_gravity="center_horizontal|center_vertical"></ImageView>
		<LinearLayout android:id="@+id/ButtonsLayout"
			android:layout_width="wrap_content" android:layout_height="wrap_content"
			android:orientation="vertical" android:layout_gravity="right|center_vertical">
			<Button android:id="@+id/ObeyButton" android:layout_width="fill_parent"
				android:layout_height="wrap_content" android:text="@string/obeyButtonLabel"
				android:gravity="center_horizontal|center_vertical"
				android:textColor="#FFFFFF" android:layout_gravity="center_vertical|center_horizontal"
				android:background="@drawable/button_states"></Button>
			<Button android:id="@+id/ListenButton" android:layout_width="fill_parent"
				android:layout_height="wrap_content" android:text="@string/listenButtonLabel"
				android:textColor="#FFFFFF" android:typeface="normal"
				android:layout_gravity="center_vertical|center_horizontal"
				android:background="@drawable/button_states"></Button>
		</LinearLayout>

	</LinearLayout>
</LinearLayout>

Resumen

La importancia de poder soportar diferentes pantallas, radica principalmente en el mercado meta de su aplicación. Entre más dispositivos soporte, a más usuarios podra llegar. Pero debe tomar en cuenta los requerimientos de la aplicación así como velar que la experiencia de usuario sea grata también.

Para la segunda parte revisaremos como manejar las diferentes versiones de SDKs y como podemos afrontar el problema de objetos o métodos disponibles en uno e innexistentes en otros.

Calificadores vistos:

Links importantes

• [Inglés]Proveyendo Recursos: http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources
• [Inglés]Mejores Practicas – Soportando múltiples pantallas: http://developer.android.com/guide/practices/screens_support.html
• [Inglés]Justin Mattson – “Casting a wide net: how to target all Android devices“ https://wave.google.com/wave/#restored:wave:googlewave.com!w%252BfZ2urbZk7o

Ayer recién llegaba de la extraordinaria conferencia Google IO 2010. Definitivamente fuimos muy afortunados los que tuvimos el privilegio de asistir, y no sólo por los dos teléfonos que nos regalaron: Un Motorola Droid (Verizon) y un HTC Evo 4g (Sprint), sino también por la cantidad de información que recibimos, así como los anuncios sobre lo que tiene Google para este año, como el Google TV y Android 2.2 (FroYo).

Mi interés en esta conferencia se centra particulamente en el tema de Android, ya que por ahora es en lo que me quiero enfocar y por lo tanto será el tema principal de este post, si quieren tener información más detallada de lo demás que se habló en esta conferencia, no duden de visitar la pagina principal de la conferencia aquí. Por aquí me encontré el Live Blog de Endgadget del Keynote del Segundo día.

Lo más destacable de la conferencia, en cuanto a android fue el gran anuncio de la más reciente actualización llamada FroYo, cuya versión numérica es 2.2 ( y para el SDK versión 8). Adjunto aquí un resumen de las características:

1. Compilador Just-in-Time (JIT) que incrementara la velocidad del sistema de 2x a 5x.
2. Alrededor de 20 características empresariales, incluyendo una mejor integración con Exchange, un API para  administración del dispositivo (por ejemplo políticas de seguridad), respaldo de datos personales para transferirlos a otro dispositivo android.
3. Nuevo API para mensajería Cloud-to-Device, algo más allá de notificaciones push.
4. WiFi tethering y WiFi HotSpot. Esto permitirá que dispositivos con capacidad WiFi puedan conectarse al dispositivo Android y poder acceder a Internet a través de él (usando la conexión de datos del servicio móvil).
5. Además, actualización al Android Market para poder buscar mejor las aplicaciones. Android Market también podrá ser accedido mendiante una computadora. Pero aun mejor usted podrá bajar la aplicaciónes a su PC  e instalarlas inmediatamente a su dispositivo Android de su elección, sin ocupar conectar el Andriod a su PC (ambos ocupan conexión de datos a Internet).
6. Es importante recalcar que Google TV soportará aplicaciones Android y estará integrado igualmente con Android Market, por lo que la funcionalidad anterior también estará disponible para Google TV.

Durante el resto de los días estas fueron las charlas relacionadas a Android:

También me parece importante rescatar la actividad que hubo el Miércoles después de las charlas, de verdad una actividad para socializar muy interesante y entretenida.

Aquí termina mi resumen de Android en Google IO 2010. No quise hacer un post muy largo, para motivarlos a buscar información detallada en el sitio de Google y otro montón de fuentes disponibles en la Web.

Espero volver el próximo año y seguir trabajando en aplicaciones para Android, y tal vez algún día llegar como expositor u orador.