El reto de diseñar y desarrollar para Android

1. www.gowexmobile.com
Introducción a
Android

2. 1. Introducción a Android: qué es, diseño, fragmentación…
2. El desafío de diseñar para Android: pantallas, resoluciones, proporciones y
densidades
3. Fases de desarrollo: desde el planteamiento de un prototipo a la publicación
de la app en tienda.
4. Monetización vía compra directa y publicidad.
5. Publicación en Google Play.
6. Desarrollo y herramientas.
7. Elementos básicos de una App Android: estructura de un proyecto, guía de
permisos, DDPi,s, automatización y producción.
Guía de Contenidos

3. Plataforma Android
• Plataforma desarrollada por Android Inc, empresa que posteriormente Google
compró en 2005. (Android no fue idea de Google…).
• Basado en Linux.
• Es un sistema operativo abierto y sin royalties.
• Google añade una capa propietaria que si está cerrada, y Google puede permitir o
no, la inclusión de esa capa de aplicaciones en los dispositivos (Maps, Gmail,
Google Play, Buscador...etc…), por lo que muchos dispositivos (chinos
principalmente) no tienen esas aplicaciones. Esto ha provocado mucha
controversia al respecto en el mundo del “software libre”.

4. Tanto el nombre de “Android” como el nombre de la gama de terminales oficiales de Google
“Nexus”, hacen referencia a la novela “¿Sueñan los androides con ovejas eléctricas?” de
Phillip K.Dick, que después fue llevada al cine bajo el nombre de “Blade Runner”.
Dato “Gafapaster”

5. Diseño: ¿Qué debemos tener en cuenta?
 Miles de tamaños de pantalla
 Miles de tipos de pantallas
 Miles de dispositivos y configuraciones distintas

6. Fragmentación en Android
Como sabemos el hecho de que Google o Apple lancen una nueva actualización de sus sistemas
operativos móviles implica la posibilidad de que algunos modelos, normalmente declarados de forma
injusta como obsoletos, queden fuera del listado de terminales que podrán recibirla de forma oficial.
Esto, unido a la variedad de fabricantes de Android y a la variedad de dispositivos, hace que se genera
la llamada “fragmentación”, que en el caso de Android, está mucho mas presente que en iOS.
La fragmentación no es sólo algo negativo. También tiene cosas muy positivas para los clientes.
Pros
• Variedad de terminales
• Cubre todo el segmento de
clientes (variedad de precio)
• Muchos fabricantes
(Competencia)
• Adaptable a todo tipo de
dispositivos (TVs, Gafas ,
relojes, … hasta neveras) que
compartirán experiencia de uso
• Si al cliente no le gusta la forma
de uso de un terminal, puede
buscar otro que se adapte
mejor
Contras
• Terminales obsoletos no
actualizables
• Los fabricantes tienen que
encargarse de actualizar sus
terminales
• Hardware muy variado
• Muchas pantallas a las que
ajustarse
• Diferentes experiencias de
usuario dependiendo de la
marca del dispositivo
• No hay un único estándar de
diseño

7. 2. El desafío de
diseñar para Android

8. Diseñar para Android
Desarrollemos una solución específica para
cada dispositivo (bien sea nativa o versión web)
como una global, los diseñadores de interacción
y visual se encuentran ante varios desafíos.
Hoy, analizamos algunos de ellos:
• Tamaños
• Resoluciones
• Proporciones
• Densidades

9. Tamaño de pantallas
Cada fabricante diseña sus terminales a su gusto. No existen estándares de pantalla, de modo
que a medida que aparecen distintos diseños en el mercado, se complica aún más el proceso de
diseño.
Podemos ver pantallas desde 2,8” hasta 6” en el caso de móviles, o de 6” a 13” en el caso de las
tabletas.
Entonces... ¿cómo ajustamos el tamaño de los iconos sin perder usabilidad y legibilidad?
Ejemplo: Un botón de 30x30px se verá muy pequeño en un móvil de 2,8” y prácticamente no se podrá
pulsar con un dedo.
A continuación podemos ver un ejemplo muy visual a través de las distintas fragmentaciones que hay
en Android y en iOS.

10. Resoluciones, el gran reto
En Android hay diversos tamaños de pantalla, que van desde 240x320 hasta 1080x1920 (2560x1600 en
la Nexus 10). Este es el principal desafío a la hora de diseñar interfaces.
Por esta razón, debemos olvidarnos del pixel para definir las interfaces, lo dejaremos sólo para algunos
detalles fijos.
Debemos empezar a pensar en porcentajes según las proporciones de pantalla o la dependencia de
unos elementos con otros.
Ejemplo: Un elemento puede ocupar el 75% del ancho del elemento padre.

11. Diferentes Proporciones de pantalla
Las pantallas más usadas en Android tienen dos tipos de proporciones diferentes: 4:3 y 16:9.
Esta proporción dispar hay que tratarla de una manera natural, no vale con “escalar” los diseños
“achatándolos” o “estirándolos” como si fuera una imagen... Este tipo de prácticas arruinarán la armonía
del diseño.
Los diseños deben de ser adaptables manteniendo las proporciones de los elementos, aunque para ello
sea necesario un cambio de disposición.
Por último y recopilando un poco todas las
anteriores diferencias, las pantallas Android
tienen diferentes densidades de pixels,
entendiendo esto como una proporción entre
tamaño de pantalla y resolución.
Los DPIs o puntos de pantalla por pulgada, se
refieren a la cantidad de pixels que hay dentro
de una pulgada de pantalla.
En una pantalla de 4.7” de diagonal con una
resolución de 1280x768 tiene una densidad de
318 DPIs.
En este caso:
•768px de ancho en una pantalla con 2,417” de
ancho da que 768/2,417” = 318 dpi
•En el caso de la altura: 1280/4,03” = 318 dpi

12. Las pantallas Android tienen diferentes densidades de pixels,
entendiendo esto como una proporción entre tamaño de pantalla y
resolución.
Los DPIs o puntos de pantalla por pulgada, se refieren a la cantidad de
pixels que hay dentro de una pulgada de pantalla.
En una pantalla de 4.7” de diagonal con una resolución de 1280x768
tiene una densidad de 318 DPIs.
En este caso:
• 768px de ancho en una pantalla con 2,417” de ancho da que
768/2,417” = 318 dpi
• En el caso de la altura: 1280/4,03” = 318 dpi
Diferentes Densidades de pantalla

13. Cómo luchar contra esto
• Olvidemos el “Pixel Perfect”
• Uso de proporciones en todos los diseños.
• Diseño responsive
• Imágenes responsive también (9-Patch)

14. 3. Fases de desarrollo:
desde el planteamiento de un prototipo a la
publicación de la app en tienda.

15. Herramientas de Desarrollo
• Fase de conceptualización, diseño de interacción UX, prototipado, diseño visual…
• Planificación del desarrollo en base a los flujos y complejidad de la aplicación.
• Identificar grandes bloques de trabajo en la app (gestión del usuario, bases de datos, flujos más
complejos...etc…)

16. Herramientas de Desarrollo
• Preparación de plan de ataque lo más ordenado posible:
• Desarrollo basado en tareas y metodologías ágiles (SCRUM)
SCRUM no es sólo para
programadores, sino que
todo el equipo incluido el
cliente debe entender este
tipo de metodologías no
centradas a tener un
“producto llave en mano”
sino en ir aproximando la
solución a lo que el cliente
necesita.

17. Herramientas de Desarrollo
• División del proyecto en Funcionalidades (Historias de
usuario) y éstas en tareas asumibles.
• Búsqueda de material para ayudar en el desarrollo: Librerías,
ejemplos, experiencias de otros desarrolladores
(StackOverflow es nuestro mejor amigo…) ¡No intentes
reinventar la rueda!
• Desarrollo de la solución en equipo.

18. 4.Monetización de Apps
vía compra-directa y
publicidad.

19. Compra Directa Publicidad In-App Venta In-App
PROs
• Monetización directa
• Las aplicaciones suelen ser
de mejor calidad (y muchos
clientes lo valoran)
• Tranquilidad para el cliente
que espera no ver banners
que ensucien y traben la
experiencia de uso.
• El cliente puede pedir
devolver el dinero en los
primeros 15 minutos de
uso.*
Contras
• El cliente no quiere pagar.
• La experiencia del cliente no siempre
es buena
• Alta piratería
• El precio no puede superar los 2 o 3
euros. Sino se considera “cara”
• El cliente puede pedir devolver el
dinero en los primeros 15 minutos de
uso.*
PROs
• El cliente paga por usarla
sin ser consciente
• El cliente no “arriesga” su
dinero
• Baja piratería
Contras
• Márgenes muy pequeños
• Amortización a largo plazo
generalmente
• Hay formas de bloquear la
publicidad en las apps
igual que en los
navegadores
PROs
• Si es gratuita la descarga,
el cliente descarga y usa la
app sin arriesgar dinero
(aunque haya alguna
limitación)
• Baja piratería
• Buen complemento para la
publicidad, especialmente
si una de las “compras” es
quitar la publicidad.
• El cliente no puede pedir la
devolución del dinero*
Contras
• Si la app es de pago por
descarga, el cliente puede
sentirse defraudado o
estafado si le pretendes
cobrar también en la app.
• El cliente no puede pedir la
devolución del dinero.
Monetización

20. La tendencia actual apunta al Freemium más que al pago por las apps.
Caso SwiftKey
http://www.elotrolado.net/noticia_la-aplicacion-de-teclado-swiftkey-se-pasa-al-freemium_24364
Monetización

21. El desafío, a futuro, del desarrollo para Android no sólo va a quedarse en
Smartphones y tablets…
• Smartphones
• Tablets
• TVs
- TVs nativas
- “Dongles” HDMI
- Consolas (OUYA, MOJO, SHIELD….)
• Gafas
• Relojes
• Navegadores de coche
• Neveras (T9000 Samsung)
• Etc.
La expansión de Android es realmente increíble, y no siempre requiere
de interfaces gráficas “al uso”.
Variedad de Dispositivos - Ecosistema

22. 5. Publicación en
Google play.

23. Para publicar en Google Play primero se debe de
ser desarrollador (es decir, haber hecho el pago
único de los 25€ que cuesta hacerse desarrollador)
En cuanto a la aplicación en si, no hay muchas
limitaciones. La política de google es bastante
“abierta” y no es muy proactiva. Es la misma que en
Youtube, se te deja subir casi todo y si alguien se
queja, lo retiran. Lo que si se hace de manera
automatizada, es revisar que no haya “código
malicioso” a priori ni alguna cosa extraña, y que si
hay contenido para mayores de 18, el desarrollador
haya marcado esa opción.
A la hora de subir se piden datos básicos como por
ejemplo:
• una descripción,
• clasificación,
• y capturas de pantalla: deben de tener una
resolución “estándar” (generadas mediante
capturas del propio terminal) porque sino no te
deja subirlas, y se sugiere incluir capturas para
tablets y en todos los idiomas de la app, aunque
estos últimos son contenidos voluntarios.
Publicación en Google Play

24. Publicación en Google Play
La subida al Google Play
suele tardar unas 4 horas
en estar disponible en
todos los terminales.
Muy alejados de los 15
días que piden stores
como la de Apple (en
buena medida gracias a no
requerir una revisión
manual de todas las apps).

25. 6. Desarrollo y
herramientas

26. ¿Qué puede hacer un desarrollador sobre Android?
• El control que tiene un desarrollador sobre la plataforma es, prácticamente, total.
• En plataformas como iOS, las aplicaciones no pueden acceder libremente a muchas de las
funcionalidades del hardware (memoria interna, acceso a la propia interface, uso de otras apps del
terminal, ..etc.…)
• En el caso de Android, se permite hacer uso de prácticamente todo sin tener “permisos de súper-
usuario (root)”. Esto es muy bueno de cara a la potencia del desarrollo, pero tiene sus contras.
Un ejemplo es el simple hecho de la existencia tanto de los broadcast receivers como de los servicios.
Desde nuestra app podremos hacer cosas como:
 Acceso directo a menús de sistema (llevar al usuario a la sección de ajustes de wifi por ejemplo)
 Integrar funcionalidades externas que las provean otras apps (recorte de imágenes, enviar datos a
otras apps como Whatsapp, Email, etc…) integrándolos de una forma muy natural dentro de nuestra
app.
 Acceso a elementos a bajo nivel (Bluetooth red wifi, ...etc…)
 Posibilidad de

27. Para desarrollar en Android se pueden usar principalmente, dos lenguajes de programación: Java y C++.
IDEs de desarrollo:
Presente: Eclipse, JAVA, SDK Android, ADT: http://developer.android.com/sdk/index.html
Herramientas de Desarrollo

28. Herramientas de Desarrollo
Futuro: Android Studio.
http://developer.android.com/sdk/installing/studio.html
Diseño de 9-Patch
Draw9Patch.bat: Contenido en el propio SDK de
android.
Better9Patch Tool (Para Mac)
http://www.roundrect.kr/desktop/better-9-patch/

29. Arquitectura de Android (Java - Dalvik VM))

30. 7. Elementos básicos
de una App Android

31. Elementos básicos de una App Android
Activity
En caso de que la app tenga una interface gráfica, debe implementarse en una “Activity”.
No todas las aplicaciones lo requieren. Muchas veces solo son servicios o complementos para otras
aplicaciones.La activity tiene un ciclo de vida bastante clásico dentro del desarrollo de aplicaciones:
Fuente:
emezeta

32. Elementos básicos de una App Android
Service
Parte de una aplicación que necesita persistir en el tiempo y estar en ejecución, aunque se cierre la
activity principal. Atención: alto consumo de batería.
Ejemplo: Llegada de un mensaje o Push al terminal como en Whatsapp.
Content providers
Parte de la aplicación encargada de proveer de datos tanto a ella misma como a otras aplicaciones:
Ejemplo: Acceso intensivo a una base de datos.
Broadcast receivers
Parte de una aplicación que debe quedarse latente a la espera de un evento que la dispare.
Bajo consumo de batería.
Ejemplo: Hacer una acción al conectarse a una wifi, o al bluetooth del coche, o incluso si el nivel de
batería se modifica.
Muchas de las cosas que se espera de un servicio, se puede hacer más eficientemente con un
Broadcast receiver (ejemplo de la nueva app de GOWEX, donde el escaneo de nuevas redes, o incluso
el auto-logueo del usuario se van a hacer a través de un broadcast receiver.)

33. Estructura de un proyecto Android

34. Guía de permisos Manifest
Muchas de estas funcionalidades requieren de permisos “especiales” que el usuario debe de ver y
aceptar al instalar la aplicación. Estos permisos se gestionan desde el “Manifest.xml”
Los permisos suelen mostrar advertencias bastante alarmistas a los usuarios.
Escribir / leer un archivo de la memoria interna se traduce en “Acceso a
fotos y archivos multimedia”... parece que tus fotos personales van a ser de
dominio público...

35. Diseño de Interfaces en XML
El editor del plugin de Android para eclipse, permite arrastrar elementos y definir sus propiedades
visualmente, aunque los programadores más experimentados suelen preferir entrar en el código XML “a
pelo” para tener más control sobre los elementos visuales y hacer ajustes más “finos”.
La previsualización permite configurarse para mostrar diferentes modos visuales (Landscape, Portrait,
estilo visual...etc..) y diferentes tamaños y proporciones de pantalla, como por ejemplo Nexus 4, Nexus,
7, Nexus 10...etc…)

36. Uso de DDPis
En Android, se suele usar los DPIs como medida de tamaño para los elementos.
Los DPIs son una proporción entre el tamaño real de la imagen (en cm) y el tamaño en pixels.
Se da por supuesto que un botón de 2 Cm debe de ser igual de grande en cm, en todos los dispositivos.
Si en una tablet debe de verse mas grande hay que modificar su medida a mano (hacer un layout nuevo
o bien modificar la constante que defina su tamaño en la carpeta “dimens”.

37. La magia de la automatización de las adaptaciones y
localizaciones (carpeta “RES”).
Gracias a la estructura de carpetas de un proyecto Android, la adaptación a diferentes terminales es
baste automática.
En principio, cuando la app requiere una imagen concreta, primero la va a
buscar en su carpeta específica.
Ejemplo, un S5 buscará las imágenes en “drawable-xhdpi”, y si no la
encuentra, irá a la carpeta “drawable-hdpi” y la pintará escalada (efecto
borroso), y en caso contrario irá a carpetas inferiores hasta que la
encuentre y la escalará en la proporción adecuada.
También se puede distinguir por tamaño físico de la pantalla, añadiendo el
tamaño al nombre de la carpeta: Ejemplo “drawable-large-mdpi”
La carpeta “drawable” se usa para elementos que no deben de ser re
escalados, como por ejemplo XMLs de diseños con primitivas de dibujo o
imágenes que se pintarán “tal cual”
En el caso de ser una imagen para un dispositivo pequeño, irá a buscarla
a su carpeta o bien a carpetas de tamaño superior hasta que la encuentre
y la pintará re-escalándola, provocando pixelación.

38. La magia de la automatización de las adaptaciones y
localizaciones (carpeta “RES”).
Lo mismo ocurrirá en el resto de casos. Por ejemplo, para cargar un layout en landscape, irá a la carpeta
“layout-land” y si no lo encuentra, irá a la carpeta “layout” normal (la usada en portrait) y lo pintará
adaptándose a la pantalla panorámica.
En la carpeta “values”, se guardarán XMLs de datos de diferentes tipos. Aunque en
los proyectos, se suelen meter los datos en diferentes XMLs según le convenga al
desarrollador, en tiempo de compilación, todos esos datos se meten juntos como si
estuvieran en un único archivo.
En el caso de los idiomas, se espera que el idioma “por defecto” esté en la
carpeta“values”, en el archivo “strings.xml”, y los idiomas adicionales, deberían de
estar en la carpeta “values-[LOCAL CODE]“: Ejemplo: values-es”,”values-us”,”values-
fr”...etc…
De esta manera, cuando el usuario cambie el idioma de su dispositivo, si nuestra app
está traducida para ese idioma, se mostrará en ese idioma sin hacer ningún desarrollo
manual.
Las estructura de carpetas, entre idioma, densidad, y orientación, pueden ser
bastante más compleja, encontrando carpetas como por ejemplo: “values-large-hdpi-
land-es”,aunque es bastante raro que una app requiere de tanta profundidad de
detalles en su estructura de carpetas.
Hay otras subcarpetas en “RES” tales como “raw”,”xml”,...etc…que sirven para
diferentes propósitos, pero suelen ser

39. Firma de la App para subirla a producción
Para subir las aplicaciones a la tienda, se requiere que estén firmadas con una firma de producción.
Se puede hacer usando “keytool” de java, o bien desde el propio eclipse.
Para firmar desde eclipse, hay que hacerlo desde “Proyecto (botón derecho) / Android Tools / Export
Signed….”
Después hay que seguir las instrucciones en pantalla,
que básicamente consisten en localizar el keystore
con nuestra firma (generada con antelación o bien la
podemos generar en este momento), escoger la firma
concreta, y firmar el APK.
Para más información, seguir este tutorial:
http://developer.android.com/tools/publishing/app-
signing.html
La subida a Google play se hace como se ha
explicado anteriormente, rellenando los campos que
se piden y usando una cuenta de Google (Gmail), con
el pago de desarrollador.

40. Gracias.
www.gowexmobile.com @ideup @gowex