Android Soporte para Múltiples Pantallas 2/2

Nota: Si aun no has leído la primera parte da clic aquí.
Todas las imágenes son tomadas del IDE Eclipse.

Tamaño de la pantalla: A partir de Android 3.2 se introduce un nuevo enfoque para el tamaño de las pantallas, incorporando nuevos selectores numéricos con respecto a lo que se venía trabajando. descritos por tres números (selectores numéricos) representados de la siguiente manera:

 Width dp: Anchura de la pantalla del dispositivo, el ancho cambia cuando la orientación de la pantalla es cambiada.

Height dp: Altura de la pantalla del dispositivo, esta altura cambia cuando la orientación de la pantalla es cambiada.

Smallest Width dp: El ancho más pequeño del dispositivo, para el diseño de la app este es la menor anchura que se puede encontrar en cualquier rotación de la pantalla siendo este el más importante de los tres números que describen el tamaño de la pantalla.

Los números típicos para el ancho dp en pantallas son:

320: Una pantalla de teléfono
480: Una tablet Tweener
600: Una tablet de 7”
720: Una tablet de 10”

Estos nuevos selectores numéricos pueden seleccionar los recursos de diseño utilizando el Smallest Width dp (sw), Width dp, Height dp o combinaciones entre ellos.

Para ilustrar mejor lo anterior, pongamos un ejemplo; queremos implementar una interfaz para tablet, recordemos que su ancho mínimo es de 600dp, entonces tendríamos lo siguiente:

Primero debemos crear un nuevo archivo XML, para esto nos ubicamos en nuestro proyecto, entramos a File > New (Alt + Shift + N) > Other … (Ctrl + N) > Android; de las opciones desplegadas seleccionamos Android XML Layout File, clic en Next. Nos aparece la siguiente ventana, ingresamos el nombre del archivo, debe ser en minúscula y podemos seleccionar el tipo de elemento, en este caso solo agregaremos el nombre y dejaremos el resto por defecto.

Esta resaltado un Warning generado porque ya existe un archivo con el nombre de activity_main.xml, lo pasaremos por alto. click en Next. Nos aparece la siguiente ventana donde aparecen los calificadores disponibles. 

Seleccionamos el calificador Smallest Screen Width (Resaltado) y clic en el botón de selección (Resaltado). Aparece la siguiente ventana.

Primero debemos agregar el valor para Smallest Screen Width recordemos que queremos dar soporte a una tablet de 7” para ello ponemos el valor de 600 que nos cambia el nombre del calificador escogido a sw600dp y por último no indica el Folder en el cual se va a guardar. Clic en Finish. Al terminar si la carpeta donde va a guardarse no existe la crea y tenemos lo siguiente en la estructura de nuestro proyecto.

Si queremos hacer lo mismo pero para tablet de 10” debes repetir todos los pasos anteriores reemplazando el Smallest Screen Width de 600 por 720 y con esto se adiciona un nuevo recurso:

Para tener en cuenta, Android utilizara el recurso que esté más cerca al ancho más pequeño, del dispositivo sin que el recurso sea más grande.

Para hacer un diseño que nos dé soporte al cambiar de orientación utilizaremos el selector de Ancho (Screen Width) siguiendo los mismo pasos anteriores.

Android Soporte para Múltiples Pantallas 1/2

Primero debes tener claro algunos conceptos.

Densidad de Pantalla: Cantidad de pixels en un área física de la pantalla.

Orientación de la Pantalla: posición con respecto al usuario, Vertical u Horizontal

Pixel independiente de la Densidad (dp): Es una unidad virtual utilizada para definir el diseño de la interfaz. un dp es equivalente a un pixel físico en una pantalla de 160dpi. la conversión de DP a pixel es la siguiente: px = dp * (dpi / 160).

teniendo estos conceptos hay dos puntos en cuanto a las pantallas de los dispositivos que debes tener en cuenta al momento de hacer tus diseños.

La densidad: El primer punto es la densidad que afecta principalmente tus imágenes. Android escala tus recursos drawables en caso de ser necesario, por eso es una buena practica que proporciones los recursos para cada grupo de densidad con el fin de evitar que tus imágenes se vean borrosas, despixeladas o que simplemente no se vean como tu lo esperabas. Android divide los grupo de densidad en 4 principalmente; ldpi, mdpi (Linea Base), hdpi, xhdpi y ahora como están tan populares los dispositivos móviles con altas densidades entonces también es conveniente el xxhdpi; este ultimo es indispensable para tu icono lanzador en tablet con alta densidad. Para conocer que tamaños deben tener tus imágenes para cada grupo ten en cuenta cada factor de grupo.

ldpi(120dpi): tiene un factor de 0.75x, es decir, que 1dp equivale a 0.75 pixel.
mdpi(160dpi): linea base factor de 1x, es decir, que 1dp equivale a un pixel.
hdpi(240dpi): factor de 1.5x, es decir, que 1dp equivale a 1.5 pixel.
xhdpi(320dpi): factor de 2x, es decir, que 1dp equivale a 2 pixel.
xxhdpi(480dpi): factor de 3, es decir, que 1dp equivale a 3 pixel.

¿como obtenemos este factor?

Sencillo utiliza la formula de conversión px = dp * (dpi / 160), tenemos que la linea base que es mdpi tiene 160dpi.

px = 1 * (160/160)
px = 1 * (1)
px = 1

Miremos un ejemplo con el icono lanzador que tiene un tamaño de 48 x 48 pixels en mdpi como hacemos para conocer de que tamaño necesitamos la imagen para las demás densidades; solo debes multiplicar el tamaño por el factor.

ldpi: imagen de 36 X 36 no es necesario proporcionar esta imagen ya que Android escalara hacia abajo las imágenes que hayas proporcionado para un grupo de mayor densidad.

mdpi: imagen de 48 x 48
hdpi: imagen de 72 X 72
xhdpi: imagen de 96 X 96
xxhdpi: imagen de 144 X 144

Tamaño de la pantalla: Este es el segundo punto, que veremos en la segunda parte de este post.

Lecturas Interesantes Sobre SCRUM

Quiero recomendarles varias lecturas muy interesantes sobre SCRUM que se encuentran en la pagina de Javier Garzás:

Usando Scrum para evitar malas implementaciones de CMMI

La historia de usuario no es el “requisito” de las metodologías ágiles

Claves para implantar el rol de Product Owner, uno de los roles clave en un desarrollo ágil

y tiene mucho más te invito a que la explores.

Para terminar si te interesa hacer algún curso virtual acá tienes uno.

SCRUM

Se enmarca dentro de las metodologías ágiles en el desarrollo de software. Se puede definir como un marco de trabajo o una metodología de gestión del trabajo, centrado especialmente en el factor humano más que a los procesos, es decir, da mayor valor al individuo, a la colaboración con el cliente y al desarrollo incremental con iteraciones muy cortas. Básicamente se compone como tal de un Equipo y sus Roles; Bloques de Tiempo y Artefactos. Dentro de los Roles encontramos: El Scrum Master, que es el encargado de hacer que el equipo Scrum siga las prácticas y normas de la metodología, El Propietario del Producto, representa la voz del cliente, se asegura de que el equipo Scrum trabaje de forma adecuada desde la perspectiva del negocio y es el responsable de gestionar el Product Backlog, escribiendo historias de usuario y priorizándolas; y El Equipo, que hace el trabajo y desarrolla el producto.

Los bloques de tiempo son: la Reunión de Planificación de la Entrega, la Reunión de Planificación del Sprint, el Sprint, el Scrum Diario, la Revisión del Sprint, y la Retrospectiva del Sprint. El corazón de Scrum es un Sprint, que es una iteración de un mes de duración o menos¹.

Los Artefactos de SRUM son: Product Backlog, Lista de funcionalidades requeridas para la aplicación ordenada de mayor a menor importancia, esta lista no necesariamente debe contener todas las funcionalidades, ya que pueden irse agregando a medida que avanza el proyecto. Sprint Backlog, Del product backlog se toma las primeras funcionalidades, cuya sumatoria del tiempo estimado de C/U no supere el tiempo estimado para todo el sprint, pueden ser descompuestas en tareas y esta lista de funcionalidades es el que se realizara durante el sprint. Carta Burndown o grafica de progreso, muestra la correlación entre el tiempo y el  trabajo realizado.

El texto anterior es extraído del Artículo  DESARROLLO E INTEGRACIÓN DE UNA ONTOLOGÍA Y SISTEMA DE INFORMACIÓN HERBARIO  PARA EL APOYO A LA CARACTERIZACIÓN FLORÍSTICA DE LA ZONA DEL CATATUMBO para ver artículo completo haga clic aquí.

Referencias:
Ken Schwaber y Jeff Sutherland (2008-2011) Scrum. http://www.scrum.org. Pag 5

SCRUM y sus lindas piernas.

En mi corta carrera como desarrollador me he encontrado cara a cara con diferentes metodologías de desarrollo de software tanto pesadas o tradicionales como ágiles pero ninguna llamo tanto mi atención como SCRUM.  Entonces surge aquella pregunta existencial que te eleva sensorialmente a otro lugar tan conocido y tan nuevo a la vez, ¿Porque?, porque llamo mi atención SCRUM? seria por sus lindas piernas o su cabello rubio?; como no quiero cortar tu imaginación tu la puedes o lo puedes imaginar como mejor te parezca. SCRUM es como esa bella chica que tu la miras y es sencilla; tanto que no lo puedes creer, obviamente tiene sus cosas pero que chica no las tiene, y con esto no quiero decir que otras metodología no sean bellas o no cautiven, entre gusto y gusto no hay disgusto dice un adagio popular, pero hablo del mio, del gusto por lo sencillo y lo flexible, por las buenas practicas y la poca documentación, a mi me gusta hacer mas y hablar menos (aunque en este caso seria mejor escribir menos). Definitivamente SCRUM se metió en mi corazón y no es una carta de amor, ella ya sabe que me gusta, es solo que te lo quería comentar quizás a ti también te guste; ella también se comporta como un buen amigo, al que le invitas una cerveza y estará ahí, ella esta aquí y te invito a que la conozcas, habla tu idioma y aquí la puedes conseguir.

Lo mas seguro es que no buscabas tanto dramatismo por eso dejo algo mas técnico aquí.