Hace un par de meses atrás (el 19 de septiembre del 2011) se publicó en el blog oficial de Android Developers, una guía técnica orientada a ayudar a los desarrolladores Android a prepararse para la llegada de la nueva versión de Android IceCreamSandwich (ICS). En esta guía se describen algunos de los pasos que habrá que tomar en cuenta para mejorar la adaptación de nuestras interfaces de usuario a cualquier tipo de pantalla soportados por ICS, pese a que aún no estaba clara la interfaz que utilizará esta nueva versión de la plataforma.
Hay que recordar que la idea detrás de ICS es que esta versión pueda utilizarse para cualquier tamaño de pantalla, saltando de Honeycomb que es una versión específicamente para tablets, a una versión que rompa con la fragmentación que ha acompañado a la plataforma Android desde sus inicios a la fecha.
Con el objetivo de compartirles los nuevos lineamientos de los que nos habla el artículo en inglés, he decidido interpretar las partes más técnicas del mismo para que estés listo a la llegada de ICS cuya fecha de lanzamiento fue en el mes de octubre del año 2011.
Haciendo tus aplicaciones Honeycomb solamente para tablets
Si has creado aplicaciones para Honeycomb y no deseas que se utilicen en teléfonos (puede darse el caso de que una aplicación sólo tenga sentido en pantallas grandes) o simplemente necesitas más tiempo para actualizarla, agrega la declaración <supports-screens> dentro de tu archivo AndroidManifest.xml:
Esto describe el soporte de tamaños de pantalla en tu aplicación de dos formas:
- Declara que la aplicación no soporta los tamaños “small”, “normal” y “large”, los cuáles no son tradicionales de las tablets.
- Declara que la aplicación requiere un tamaño de pantalla con una superficie útil de mínimo 600dp.
La primera técnica es para los dispositivos que corren con Android 3.1, porque estos dispositivos declaran su tamaño basados en tamaños de pantalla generalizados. El atributorequiresSmallestWidthDp es para dispositivos que corren con Android 3.2 y posteriores, lo que añade la capacidad a las aplicaciones de especificar sus requerimientos de tamaño basados en un número mínimo de píxeles independientes de la densidad (dp). En este ejemplo, la aplicación declara como requerimiento, un ancho mínimo de 600 dp, que generalmente corresponde a una pantalla de 7” o más.
Por supuesto, el tamaño que elijas puede ser diferente, basado en qué tan bien trabaje tu diseño en diferentes tamaños de pantalla; por ejemplo, si tu diseño funciona bien sólo en pantallas de 9” o más, necesitarías un ancho mínimo de 720 dp.
El detalle aquí es que necesitas compilar tu aplicación en Android 3.2 o superior para poder usar el atributo requiresSmallestWidthDp. Las versiones anteriores no entienden este atributo y se generará un error en tiempo de compilación. La acción más segura por hacer es desarrollar tu aplicación con la plataforma que coincida con el nivel de la API establecido en el atributo minSdkVersion. Cuando te encuentres haciendo los preparativos finales para construir la candidate release de tu aplicación, cambia el build target a Android 3.2 y agrega el atributo requiresSmallestWidthDp. Las versiones anteriores a Android 3.2 simplemente ignoran este atributo en el XML, así que no hay riesgo de una falla en tiempo de ejecución.
Para obtener más información acerca de por qué el “tamaño mínimo” es importante para soportar diferentes tamaños de pantalla, lee New Tools For Managing Screen Sizes (son un montón de cosas que necesitas saber).
Creando layouts con single-pane y multi-pane
La forma más efectiva de optimizar tus aplicaciones, tanto para tablets como para teléfonos es combinar fragmentos de diferentes maneras para crear un layout “single-pane” para los teléfonos y un layout “multi-pane” para las tablets. Hay dos formas de hacerlo:
- Para cualquier pantalla en la que la versión para tablets muestre múltiples fragmentos, usa la misma actividad para los teléfonos, pero muestra sólo un fragmento a la vez – intercambia los fragmentos dentro de la actividad cuando sea necesario.
- Utiliza actividades independientes para alojar cada fragmento en el teléfono. Por ejemplo, cuando la interfaz de usuario de la tablet utiliza dos fragmentos en una actividad, utiliza la misma actividad para los teléfonos, pero agrega un layout alternativo que incluya únicamente un fragmento. Cuando necesites cambiar fragmentos (como cuando el usuario selecciona un elemento), inicia una nueva actividad que contenga el otro fragmento.
El método que elijas depende del diseño de tus aplicaciones y de preferencias personales. La primera opción (actividad individual) requiere que agregues dinámicamente cada fragmento a la actividad en tiempo de ejecución – en lugar de declarar los fragmentos dentro de un archivo de layout de tu aplicación – porque no se puede extraer un fragmento de una actividad si se ha declarado en el diseño en XML. También podría ser necesario actualizar la action bar cada vez que los fragmentos cambien, dependiendo de qué acciones o modos de navegación son proporcionados por el fragmento. En algunos casos, estos factores pueden no tener importancia para tus aplicaciones, así que usar una actividad e intercambiar fragmentos funcionará bien. Otras veces, sin embargo, utilizar una sola actividad e intercambiar dinámicamente fragmentos puede hacer que tu código se vuelva más complicado, porque hay que manejar todas las combinaciones de fragmentos dentro del código de la actividad en lugar de aprovechar las alternativas de los archivos de layout.
Ahora, vamos a hablar de la segunda opción detalladamente. Al principio podrá ser un poco más de trabajo, porque cada fragmento deberá funcionar bien en actividades separadas, pero vale la pena. Esta opción significa que podrás utilizar archivos de layout alternativos que definan diferentes combinaciones de fragmentos, manteniendo lo modular en el código, simplificando la gestión de la action bar y permitiendo que el sistema maneje todo el trabajo detrás de esto.
La siguiente figura muestra cómo una aplicación con dos fragmentos puede utilizarse para teléfonos y tablets cuando se utilizan diferentes actividades para el diseño de los dispositivos:
En esta aplciación, la actividad A es la “actividad principal” y utiliza diferentes layouts para mostrar uno o dos fragmentos a la vez, dependiendo del tamaño de la pantalla. Cuando se trata de una pantalla de teléfono, el layout contiene sólo el fragmento A (una ListView); y cuando se trata de una pantalla de tablet, el layout contiene ambos fragmentos A y B.
Así quedaría el archivo res > layout > main.xml para los teléfonos:
Y así el archivo res > layout > main.xml para tablets:
La manera de cómo la aplicación responde cuando un usuario selecciona un ítem de la lista depende de si el fragmento B está disponible en el layout. Si es así, la actividad A le notifica al fragmento B para que se actualice. En caso contrario, la actividad A inicia la actividad B (que contiene el fragmento B).
Para implementar este modelo en tus aplicaciones, es importante que desarrolles tus fragmentos siguiendo dos reglas generales:
- No manipular un fragmento directamente desde otro.
- Mantener todo el código concerniente al contenido en un fragmento dentro de ese fragmento, en lugar de ponerlo en el código de la actividad dónde se alojará el fragmento.
Para evitar la llamada directa de un fragmento a otro, declara una interfaz de callback en cada clase de fragmento que pueda ser utilizada para disparar eventos en la actividad dónde se encuentren, y que además implemente la interfaz de callback. Cuando la actividad recibe una callback como resultado de un evento (como cuando un usuario selecciona un ítem de una lista), esta actúa apropiadamente en base a la configuración del fragmento actual.
Por ejemplo, la actividad A del ejemplo anterior maneja la selección de items de esta manera:
Cuando DisplayActivity (Actividad B) incia, lee todos los datos recuperados del Intent y los pasa a DisplayFragment (Fragmento B).
Si el Fragmento B necesita entregar un resultado como respuesta al Fragmento A, entonces el proceso funciona de manera similar que la interfaz de callback entre el Fragmento B y la Actividad B. Es decir, la Actividad B implementa una interfaz de callback definida por el Fragmento B. Cuando la Actividad B obtiene la callback, se establece el resultado de la actividad y se termina. Entonces, la Actividad A recibe el resultado y lo entrega al Fragmento A.
Para ver una demostración completa de esta técnica para crear diferentes combinaciones de fragmentos para diferentes tablets y teléfonos, pegale un vistazo al código de este ejemplo actualizado de una galería en Honeycomb (archivo ZIP).
Hacer que la Action Bar funcione en teléfonos
Si has utilizado la implementación de la Action Bar en tus aplicaciones para tablets, la conversión de tablets a teléfonos será indolora. El sistema de Android hará todo el trabajo por ti; todo lo que necesitas hacer es asegurar que el diseño de tu Action Bar es flexible. Estos son algunos tips importantes:
- Cuando establecemos un ítem de menú como un ítem de acción, trata de utilizar valores que no se encuentren tan accesibles en otro tipo de menús de manera repetida.
- Cuando sea posible, proporciona los iconos de todos los ítems de acción y declarashowAsAction=”ifRoom | withText”. De esta manera, si no hay suficiente espacio para el texto, pero es suficiente para el icono, entonces únicamente el icono puede ser utilizado.
- Evite el uso de modos de navegación personalizados en la Action Bar. Utilice las pestañas integradas y los modos desplegables de navegación – que están diseñados para ser flexibles y adaptarse a los diferentes tamaños de pantalla. Por ejemplo, cuando el ancho es demasiado estrecho para ambas pestañas y otros ítems de acción, las pestañas aparecerán debajo de la Action Bar. Si tu aplicación requiere un modo de navegación personalizado en la Action Bar, pruébalo exhaustivamente en pantallas más pequeñas cuando Ice Cream Sandwich esté disponible y realiza los cambios necesarios para que tengas una Action Bar estrecha.
Por ejemplo, las siguientes imágenes muestran cómo el sistema podría adaptar la Action Bar de la aplicación basado en el espacio disponible en la pantalla. En el teléfono, sólo dos ítems de acción se ajustan, por lo que el resto de los elementos se mostrarán en el menú tradicional y las pestañas aparecen en una fila diferente. En la tablet, más ítems de acción y pestañas se pueden ajustar en la Action Bar.
Algunos otros tips
- Cuando trabajes con un ListView, considera cómo podrías proporcionar más o menos información en cada elemento de la lista basado en el espacio disponible. Es decir, puedes crear layouts alternativos para desplegar los elementos de la lista, tomando en cuenta por ejemplo, que en pantallas más grandes puedes mostrar más detalles en cada opción.
- Crea recursos alternativos para guardar valores como integers, dimensiones o booleanos. Utilizando clasificaciones por tamaño de estos recursos, podrás aplicar fácilmente diferentes tamaños de layout, tamaños de letra, o habilitar/deshabilitar características en base al tamaño actual de la pantalla.
Probando tu soporte para dispositivos
A estas alturas debes estarte preguntando: “¿Cómo puedo probar mi layout para pantallas más pequeñas sin un dispositivo que funcione con Honeycomb?”. Puedes comenzar a realizar las primeras pruebas de tus layouts alternativos con un pequeño truco: en lugar de utilizar la clasificación “large” para layouts para tablets, utiliza “land” (es decir, en lugar de utilizar res/layout-large/main.xml usa res/layout-land/main.xml). De esta forma, una tablet con Honeycomb (o emulador) con orientación horizontal usará tu diseño para tablet y el mismo dispositivo, con orientación vertical utilizará el layout para teléfonos. Sin olvidar de volver a hacer el cambio cuando ICS haya llegado.
Reitero, que ICS resulta interesante ir conociendo las nuevas disposiciones que tendremos que adoptar dentro de poco para que nuestras aplicaciones se adopten a los nuevos estándares y puedan migrar de manera satisfactoria al nuevo paradigma de visualización en cualquier tamaño de pantalla.
Espero que esta interpretación te haya sido de ayuda para tener un acercamiento con todo lo que trae la ultima versión de Android: Ice Cream Sandwich.
Referencia | Android Developers
No hay comentarios:
Publicar un comentario