2. 1. Introduccin a Android: qu es, diseo, fragmentacin 2. El
desafo de disear para Android: pantallas, resoluciones,
proporciones y densidades 3. Fases de desarrollo: desde el
planteamiento de un prototipo a la publicacin de la app en tienda.
4. Monetizacin va compra directa y publicidad. 5. Publicacin en
Google Play. 6. Desarrollo y herramientas. 7. Elementos bsicos de
una App Android: estructura de un proyecto, gua de permisos,
DDPi,s, automatizacin y produccin. Gua 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 aade una capa propietaria que si est cerrada,
y Google puede permitir o no, la inclusin 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
Suean los androides con ovejas elctricas? de Phillip K.Dick, que
despus fue llevada al cine bajo el nombre de Blade Runner. Dato
Gafapaster
5. Diseo: Qu debemos tener en cuenta? Miles de tamaos de
pantalla Miles de tipos de pantallas Miles de dispositivos y
configuraciones distintas
6. Fragmentacin en Android Como sabemos el hecho de que Google
o Apple lancen una nueva actualizacin de sus sistemas operativos
mviles implica la posibilidad de que algunos modelos, normalmente
declarados de forma injusta como obsoletos, queden fuera del
listado de terminales que podrn 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 fragmentacin, que en el
caso de Android, est mucho mas presente que en iOS. La fragmentacin
no es slo algo negativo. Tambin 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 compartirn 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 estndar de diseo
7. 2. El desafo de disear para Android
8. Disear para Android Desarrollemos una solucin especfica para
cada dispositivo (bien sea nativa o versin web) como una global,
los diseadores de interaccin y visual se encuentran ante varios
desafos. Hoy, analizamos algunos de ellos: Tamaos Resoluciones
Proporciones Densidades
9. Tamao de pantallas Cada fabricante disea sus terminales a su
gusto. No existen estndares de pantalla, de modo que a medida que
aparecen distintos diseos en el mercado, se complica an ms el
proceso de diseo. Podemos ver pantallas desde 2,8 hasta 6 en el
caso de mviles, o de 6 a 13 en el caso de las tabletas. Entonces...
cmo ajustamos el tamao de los iconos sin perder usabilidad y
legibilidad? Ejemplo: Un botn de 30x30px se ver muy pequeo en un
mvil de 2,8 y prcticamente no se podr pulsar con un dedo. A
continuacin podemos ver un ejemplo muy visual a travs de las
distintas fragmentaciones que hay en Android y en iOS.
10. Resoluciones, el gran reto En Android hay diversos tamaos
de pantalla, que van desde 240x320 hasta 1080x1920 (2560x1600 en la
Nexus 10). Este es el principal desafo a la hora de disear
interfaces. Por esta razn, debemos olvidarnos del pixel para
definir las interfaces, lo dejaremos slo para algunos detalles
fijos. Debemos empezar a pensar en porcentajes segn 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 ms usadas
en Android tienen dos tipos de proporciones diferentes: 4:3 y 16:9.
Esta proporcin dispar hay que tratarla de una manera natural, no
vale con escalar los diseos achatndolos o estirndolos como si fuera
una imagen... Este tipo de prcticas arruinarn la armona del diseo.
Los diseos deben de ser adaptables manteniendo las proporciones de
los elementos, aunque para ello sea necesario un cambio de
disposicin. Por ltimo y recopilando un poco todas las anteriores
diferencias, las pantallas Android tienen diferentes densidades de
pixels, entendiendo esto como una proporcin entre tamao de pantalla
y resolucin. 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 resolucin 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 proporcin entre tamao de pantalla
y resolucin. 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 resolucin 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. Cmo luchar contra esto Olvidemos el Pixel Perfect Uso de
proporciones en todos los diseos. Diseo responsive Imgenes
responsive tambin (9-Patch)
14. 3. Fases de desarrollo: desde el planteamiento de un
prototipo a la publicacin de la app en tienda.
15. Herramientas de Desarrollo Fase de conceptualizacin, diseo
de interaccin UX, prototipado, diseo visual Planificacin del
desarrollo en base a los flujos y complejidad de la aplicacin.
Identificar grandes bloques de trabajo en la app (gestin del
usuario, bases de datos, flujos ms complejos...etc)
16. Herramientas de Desarrollo Preparacin de plan de ataque lo
ms ordenado posible: Desarrollo basado en tareas y metodologas
giles (SCRUM) SCRUM no es slo para programadores, sino que todo el
equipo incluido el cliente debe entender este tipo de metodologas
no centradas a tener un producto llave en mano sino en ir
aproximando la solucin a lo que el cliente necesita.
17. Herramientas de Desarrollo Divisin del proyecto en
Funcionalidades (Historias de usuario) y stas en tareas asumibles.
Bsqueda de material para ayudar en el desarrollo: Libreras,
ejemplos, experiencias de otros desarrolladores (StackOverflow es
nuestro mejor amigo) No intentes reinventar la rueda! Desarrollo de
la solucin en equipo.
18. 4.Monetizacin de Apps va compra-directa y publicidad.
19. Compra Directa Publicidad In-App Venta In-App PROs
Monetizacin 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 piratera 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 piratera Contras Mrgenes muy pequeos
Amortizacin 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 limitacin) Baja piratera Buen
complemento para la publicidad, especialmente si una de las compras
es quitar la publicidad. El cliente no puede pedir la devolucin del
dinero* Contras Si la app es de pago por descarga, el cliente puede
sentirse defraudado o estafado si le pretendes cobrar tambin en la
app. El cliente no puede pedir la devolucin del dinero.
Monetizacin
20. La tendencia actual apunta al Freemium ms que al pago por
las apps. Caso SwiftKey
http://www.elotrolado.net/noticia_la-aplicacion-de-teclado-swiftkey-se-pasa-al-freemium_24364
Monetizacin
21. El desafo, a futuro, del desarrollo para Android no slo 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
expansin de Android es realmente increble, y no siempre requiere de
interfaces grficas al uso. Variedad de Dispositivos -
Ecosistema
22. 5. Publicacin 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 aplicacin en si, no
hay muchas limitaciones. La poltica 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 cdigo malicioso a
priori ni alguna cosa extraa, y que si hay contenido para mayores
de 18, el desarrollador haya marcado esa opcin. A la hora de subir
se piden datos bsicos como por ejemplo: una descripcin,
clasificacin, y capturas de pantalla: deben de tener una resolucin
estndar (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. Publicacin en Google Play
24. Publicacin 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 das que piden stores como la de Apple (en
buena medida gracias a no requerir una revisin 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, prcticamente,
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
prcticamente todo sin tener permisos de sper- 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 mens de sistema (llevar
al usuario a la seccin de ajustes de wifi por ejemplo) Integrar
funcionalidades externas que las provean otras apps (recorte de
imgenes, enviar datos a otras apps como Whatsapp, Email, etc)
integrndolos 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 programacin: 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 Diseo 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 bsicos de una App Android
31. Elementos bsicos de una App Android Activity En caso de que
la app tenga una interface grfica, 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 clsico dentro del desarrollo de
aplicaciones: Fuente: emezeta
32. Elementos bsicos de una App Android Service Parte de una
aplicacin que necesita persistir en el tiempo y estar en ejecucin,
aunque se cierre la activity principal. Atencin: alto consumo de
batera. Ejemplo: Llegada de un mensaje o Push al terminal como en
Whatsapp. Content providers Parte de la aplicacin 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 aplicacin que debe quedarse latente a la espera de un
evento que la dispare. Bajo consumo de batera. Ejemplo: Hacer una
accin al conectarse a una wifi, o al bluetooth del coche, o incluso
si el nivel de batera se modifica. Muchas de las cosas que se
espera de un servicio, se puede hacer ms 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 travs de un broadcast receiver.)
33. Estructura de un proyecto Android
34. Gua de permisos Manifest Muchas de estas funcionalidades
requieren de permisos especiales que el usuario debe de ver y
aceptar al instalar la aplicacin. 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 pblico...
35. Diseo de Interfaces en XML El editor del plugin de Android
para eclipse, permite arrastrar elementos y definir sus propiedades
visualmente, aunque los programadores ms experimentados suelen
preferir entrar en el cdigo XML a pelo para tener ms control sobre
los elementos visuales y hacer ajustes ms finos. La previsualizacin
permite configurarse para mostrar diferentes modos visuales
(Landscape, Portrait, estilo visual...etc..) y diferentes tamaos 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 tamao para los elementos. Los DPIs son una proporcin entre el
tamao real de la imagen (en cm) y el tamao en pixels. Se da por
supuesto que un botn 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 tamao en la carpeta
dimens.
37. La magia de la automatizacin de las adaptaciones y
localizaciones (carpeta RES). Gracias a la estructura de carpetas
de un proyecto Android, la adaptacin a diferentes terminales es
baste automtica. En principio, cuando la app requiere una imagen
concreta, primero la va a buscar en su carpeta especfica. Ejemplo,
un S5 buscar las imgenes 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 proporcin adecuada. Tambin se puede
distinguir por tamao fsico de la pantalla, aadiendo el tamao 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 diseos con primitivas de dibujo o imgenes
que se pintarn tal cual En el caso de ser una imagen para un
dispositivo pequeo, ir a buscarla a su carpeta o bien a carpetas de
tamao superior hasta que la encuentre y la pintar re-escalndola,
provocando pixelacin.
38. La magia de la automatizacin 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 adaptndose a la pantalla
panormica. En la carpeta values, se guardarn XMLs de datos de
diferentes tipos. Aunque en los proyectos, se suelen meter los
datos en diferentes XMLs segn le convenga al desarrollador, en
tiempo de compilacin, 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 carpetavalues, en el archivo
strings.xml, y los idiomas adicionales, deberan 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 ningn desarrollo manual. Las
estructura de carpetas, entre idioma, densidad, y orientacin,
pueden ser bastante ms 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,...etcque
sirven para diferentes propsitos, pero suelen ser
39. Firma de la App para subirla a produccin Para subir las
aplicaciones a la tienda, se requiere que estn firmadas con una
firma de produccin. Se puede hacer usando keytool de java, o bien
desde el propio eclipse. Para firmar desde eclipse, hay que hacerlo
desde Proyecto (botn derecho) / Android Tools / Export Signed.
Despus hay que seguir las instrucciones en pantalla, que bsicamente
consisten en localizar el keystore con nuestra firma (generada con
antelacin o bien la podemos generar en este momento), escoger la
firma concreta, y firmar el APK. Para ms informacin, 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.