9 patch action bar adt android android development tools android sdk apps en android density devices eclipse intents java
Si algo nos enseñó la saga original de Superman es que la cuarta parte es la mejor (?). Es por eso que para este nuevo número de la saga dejamos un tema importantísimo al empezar el desarrollo de apps para Android: Como hacer una app para distintos dispositivos.
No perdamos más tiempo y vamos con todo el detalle, como siempre, después del salto.
Les recordamos que este tutorial forma parte de la saga Cómo programar apps para Android, el cual ya tiene dos partes disponible, que pueden ver en este enlace:
Cómo programar apps para Android #1: Descarga, instalación y primera app
Cómo programar apps para Android #2: Ciclo de vida, vistas e interacciones
Vamos con lo primero:
Específicamente, lo siguiente:
Sin más que decir, vamos, manos a la obra:
En muchas ocasiones cuando estemos desarrollando un app, será necesario considerar que habrán usuarios de distintas partes del mundo que la utilizarán, y por ende podrán existir casos en que el idioma por defecto de la app no cubra sus necesidades. Afortunadamente para casos así, no es necesario construir una app para cada posible escenario, basta con que utilicemos la misma para todas, con algunos pequeños ajustes, que nombraremos a continuación:
a) Nunca escribir las cadenas de texto directo en el código, utiliza strings referenciados: En Android, cada cadena de texto que va dentro de la aplicación, desde el texto de un botón hasta una etiqueta de un formulario podemos llenarla utilizando strings referenciados, que es (valga la redundancia) una referencia al archivo strings.xml dentro del directorio values de nuestra aplicación. Por ejemplo, si en ese archivo tenemos lo siguiente:
Y luego en el código de la aplicación ponemos lo siguiente:
TextView text = new TextView(this); text.setText(R.string.hola);
Al momento de ejecutar la app, el texto R.string.hola será reemplazado por el contenido correspondiente que está en el archivo strings.xml
En estos momentos quizás se pregunten cual es la importancia de esto. Y es lo que contestaremos a continuación:
b) Mantener un archivo de strings referenciados por cada idioma que soportará la aplicación: Una vez que todos los textos de la app tienen referencias al archivo de strings, lo que debemos hacer es contar con una versión de este archivo para cada idioma que nuestra app soporte. De esta manera, cuando la app sea ejecutada, automáticamente detectará el idioma del dispositivo y buscará el archivo de textos correspondiente para hacer los reemplazos donde corresponda.
Para ello lo que haremos será tener, dentro del directorio res de nuestro proyecto, un directorio values para el idioma por defecto (español o inglés por ejemplo) y un directorio en formato values-sigla para cada idioma que queramos soportar, dentro del cual irá un archivo strings.xml con el contenido en el idioma que corresponda. Dos cosas a tener en consideración eso si:
Y con esos pequeños ajustes la app tomará el texto del idioma correspondiente según al configuración del dispositivo, y por ende nuestra aplicación ya puede ser considerada como multilenguaje.
Y llegamos finalmente al punto que probablemente más dolores de cabeza da a los desarrolladores, especialmente cuando estamos comenzando. Hace unos números hablábamos de un fenómeno que ocurre en Android llamado fragmentación, que habla de la inmensa variedad de dispositivos que hoy existen en los cuales se corre este Sistema Operativo, cada uno con sus respectivas características.
Cuando desarrollamos una aplicación en Android, tenemos que considerar que está se ejecutará en dispositivos de gama baja, con resoluciones de 240x320px, hasta tablets y teléfonos de gama alta, donde la resolución puede llegar hasta 800x1280px. Teniendo eso en consideración, diseñar pantallas que se vean de manera apropiada en ambos dispositivos puede ser un dolor de cabeza, pero afortunadamente hay herramientas y tips a tener en cuenta que pueden hacer esta tarea un poco más fácil. A continuación nombramos algunos:
a) Construir diferentes layouts: Así como en el punto anterior veíamos que era posible definir un archivo de textos para cada idioma que soportará la app, también es factible crear layouts específicos para cada tipo de resolución (default, small, large, etc), cada uno con sus características propias y que serán llamados dependiendo de la resolución de pantalla del dispositivo que ejecute la app. Para que la aplicación los reconozca, solo debemos mantener una estructura de directorios en la cual indiquemos que layout va para cada tipo de pantalla. De esta misma forma, podemos agregar layouts para orientación vertical (portrait) u horizontal (landscape). Solo debemos guardarlos así dentro del directorio res:
Y dentro de cada uno de esos directorios, los XML correspondientes a ese tipo de layout.
b) No usar medidas en pixeles (px). Usar medidas parametrizadas o pixeles dinámicos (dp): Uno de los errores más comunes, especialmente para quienes vienen de desarrollo Web, es definir medidas en pixeles fijos para algunos recursos gráficos por lo que al ejecutar la app en resoluciones más grandes o más pequeñas, el recurso se ve desproporcionado, ya que lo definimos con una resolución específica en mente. Esto es algo con lo que hay que tener especial cuidado, ya que necesitamos que cada recurso sea proporcional e independiente de la resolución de los dispositivos.
Para lograr esto, Android proporciona 2 técnicas a tener en cuenta: La primera es usar medidas parametrizadas para definir el ancho y alto de los recursos. Específicamente son 3:
Para usar estas medidas parametrizadas, las definimos en el layout, en los atributos de cada objeto, por ejemplo:
android:width=”wrap_content”
android:height=”match_parent”
La segunda técnica es usar una medida especial de Android llamada pixeles dinámicos (abreviados dp). Estos pixeles operan de forma similar a los pixeles normales (px), con la diferencia que aumentarán o disminuirán en una proporción dependiendo de la resolución del dispositivo donde la app sea ejecutada o su densidad (sea ldpi, mdpi, hdpi o xhdpi). Gracias a esto, un recurso que tiene pixeles dinámicos se verá proporcional en cualquier resolución y no se verá poco natural al compararlo en 2 dispositivos de distinta resolución o densidad de pantalla. Esto se utiliza principalmente para los márgenes y paddings de los elementos, ya que para los anchos y altos es más recomendable utilizar las medidas mencionadas más arriba.
Para utilizar pixeles dinámicos, definimos algo así en los atributos de un objeto:
android:layout_marginBottom: 10dp
Esa medida en dp será proporcional en cada una de las resoluciones de pantalla correspondientes.
c) Proporcionar recursos gráficos apropiados para cada densidad de pantalla: En Android los dispositivos, además de contar con resolución (por ej. 480x800px), cuentan con densidad de pantallas, que se refiere a la densidad de pixeles que cada una posee, y eso se mide al menos en 4 niveles: ldpi (densidad baja), mdpi (densidad media), hdpi (densidad alta), xhdpi (densidad extra alta). Cada una de estas densidades tiene una relación o proporción matemática con respecto al resto, siempre usando como base la densidad media o mdpi que podemos decir que corresponde a la proporción 1.0. Las demás se relacionan a ella de la siguiente manera:
Así que por ejemplo, si tenemos una imagen de 100×100 pixeles, deberíamos generar una de 75×75 para ldpi, 150×150 para hdpi y 200×200 para xhdpi. La app reconocerá la densidad de pantalla y obtendrá la imagen correspondiente que estará almacenada en el directorio que corresponda (drawable-ldpi, drawable-mdpi, drawable-hdpi, drawable-xhdpi).
Adicionalmente a los puntos anteriores, hay uno más, que es la creación de imágenes dinámicas mediante una técnica llamada 9-patch, pero que la veremos en un próximo número por si sola, ya que requiere una explicación un poco más detallada y no queremos que se pierda dentro de todo el resto del contenido que vimos acá.
Por ahora lo dejaremos hasta aquí para asimilar bien la información y empezar a retomar los ejemplos prácticos desde el próximo número.
Como siempre, les recordamos que este tutorial ha sido desarrollado, probado y documentado por el equipo de CLH, por lo que cuenta con nuestro sello de garantía:
Esperamos que este tutorial haya sido de utilidad para Uds.
¡Hasta la próxima!
3:42:16 am
Para cuando la siguiente entrega?:D:D
6:10:50 pm
@jennifer: Estamos ad portas de terminar nuestra renovación y lanzar la nueva versión del sitio. Una vez que lleguemos a ese punto renovaremos y continuaremos todas nuestras sagas, así que atenta! 😉
2:02:06 pm
Hola Xabadu, por el tiempo que ha pasado es posible que ya no tenga ninguna respuesta, y más si la nueva versión del sitio implica que ya estáis en otro sitio, y sobre esto quería preguntarte ya que veo que no se ha seguido publicando nada de Android, ¿has seguido publicando algo en otro sitio? O aquí en “comolohago” ha llegado a su fin.