introducción a android: el reto de desarrollar y diseñar

40
www.gowexmobile.com Introducción a Android

Upload: ideup

Post on 13-Dec-2014

912 views

Category:

Mobile


0 download

DESCRIPTION

El reto de diseñar y desarrollar para Android

TRANSCRIPT

  • 1. www.gowexmobile.com Introduccin a Android
  • 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.
  • 40. Gracias. www.gowexmobile.com @ideup @gowex