Your SlideShare is downloading. ×
0
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Introducción a Android: el reto de desarrollar y diseñar.
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Introducción a Android: el reto de desarrollar y diseñar.

976

Published on

El reto de diseñar y desarrollar para Android

El reto de diseñar y desarrollar para Android

Published in: Mobile
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
976
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
16
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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

×