Programacion Android Studio

Resumen En esta memoria se expone y documenta la creación de una APP para Android, la cual detecta ondas de ultrasonido e indica proximidad a la fuente emisora, además de un producto o marca asociados a dicha señal acústica. Para llevar a cabo este proyecto se utilizan diferentes librerías externas, diferente software para las diversas tareas, se realiza un estudio del consumo de la batería a causa de diferentes modos de la aplicación y se realiza un estudio acústico para comprender que rango de frecuencias es capaz de emitir un altavoz convencional, así como que micrófonos pueden recibir dichas frecuencias mencionadas. Es necesario el conocimiento de conceptos adquiridos en la ingeniería de sistemas de telecomunicaciones, imagen y sonido para la comprensión y seguimiento de este documento. Respecto a los resultados, se comprueba que la detección es satisfactoria a diversas distancias, y con diferentes equipos. En el apartado correspondiente se detallan las pruebas realizadas, junto a los equipos utilizados y los resultados finales. En general, el resultado es positivo y se encuentra en la aplicación una manera práctica y novedosa de realizar compras o de facilitar al usuario información concreta sin necesidad de realizar búsquedas en los buscadores web. Abstract This document describes and explains the creation of an APP for Android, which detects ultrasound waves and indicates proximity to the source, as well as a product or brand associated to the acoustic signal. In order to carry out this project, different external libraries are used. Different software for different tasks. A study of the consumption of the battery is made because of different modes of the application. An acoustic study is carried out to understand which frequency range is capable of emitting a conventional loudspeaker, as well as which microphones can receive said mentioned frequencies. It is necessary the knowledge of concepts acquired in the engineering of telecommunications systems, image and sound for the understanding and monitoring of this document. Regarding the results, it is verified that the detection is satisfactory at different distances, and with different equipment. The corresponding section details the tests performed, together with the equipment used and the final results. In general, the result is positive and is in the application a practical and novel way to make purchases or provide the user with specific information without having to search the web search engines. Palabras clave Ultrasonidos, aplicación, smartphone, Android, IOS, batería, dispositivo, detección, marketing, ventas, XTAudioBeacion, producto, servicio, escucha, actividad, funcionalidad, usuario. Keywords Ultrasound, application, smartphone, Android, IOS, battery, device, detection, marketing, sales, XTAudioBeacon, Product, service, listening, activity, func A los que creyeron, a los que estuvieron ... "Pensar sin aprender es esfuerzo perdido; aprender sin pensar, peligroso". Confucio Agradecimientos A GitHub y Google, fuente de toda sabiduría. A mi familia, por hacer esto posible. A mis amigas y amigos, por creer en mí, más de lo que yo creí. Índice general Capítulo 1. Introducción ............................................................................................ 1 1.1 Motivación....................................................................................................... 1 1.2 Objetivos......................................................................................................... 2 Capítulo 2. Estado del arte........................................................................................ 3 Capítulo 3. Metodología de trabajo ........................................................................... 4 3.1 Metodología .................................................................................................... 4 3.2 Documentación y planificación ....................................................................... 4 3.3 Ágil.................................................................................................................. 4 3.4 MVP................................................................................................................ 5 3.5 MoSCoW ........................................................................................................ 6 3.6 Gestión del proyecto....................................................................................... 6 3.7 Distribución de tareas ..................................................................................... 7 3.8 Diagrama temporal ......................................................................................... 7 Capítulo 4. Conceptualización y diseño .................................................................... 9 4.1 Mapas mentales ............................................................................................. 9 4.1.1 Bocetos del diseño inicial ......................................................................... 10 4.1.2 Wireframes ............................................................................................... 13 4.1.3 Prototipo ................................................................................................... 18 Capítulo 5. Desarrollo.............................................................................................. 22 5.1 Análisis de requisitos .................................................................................... 29 5.1.1 Requisitos funcionales.............................................................................. 29 5.1.2 Requisitos no funcionales......................................................................... 34 5.2 Estudios Realizados ..................................................................................... 38 5.2.1 Estudio acústico........................................................................................ 39 5.2.2 Estudio con materiales ............................................................................. 46 5.3 Herramientas y dispositivos utilizados.......................................................... 46 5.4 Resultados.................................................................................................... 47 5.4.1 Resultados esperados .............................................................................. 47 5.4.2 Resultados obtenidos ............................................................................... 47 Capítulo 6. Consecuencias para la salud................................................................ 48 Capítulo 7. Conclusiones y propuesta de trabajo futuro ......................................... 49 Capítulo 8. Bibliografía............................................................................................ 50 Capítulo 9. Anexos .................................................................................................. 52 Índice de figuras Figura 1. Mapa mental v1 de la estructura de la app. .................................................... 9 Figura 2. Mapa mental v2 con la estructura de la app. ................................................ 10 Figura 3. Vistas iniciales que tendría la aplicación....................................................... 11 Figura 4. Vistas Now y Ajustes que tendría la aplicación............................................. 12 Figura 5. Diseño de logos/iconos iniciales de la aplicación. ........................................ 12 Figura 6. Versión 1 de las vistas de la aplicación con Sketch...................................... 14 Figura 7. Versión 2 de las vistas de la aplicación. Actividades del modo auto apagado. .............................................................................................................................. 16 Figura 8. Versión 2 de las vistas pintadas de la aplicación, actividades con el modo auto activado. ....................................................................................................... 17 Figura 9. Primer prototipo de la aplicación con MarvelApp.......................................... 18 Figura 10. Muestra las opciones cuando accedemos a una de las imagenes............. 19 Figura 11. Configuración de acciones al crear un rectángulo en la imagen. Pestaña Hotspot Destination. ............................................................................................. 19 Figura 12. Configuración de acciones al crear un rectángulo en la imagen. Pestaña Screen Transition. ................................................................................................ 19 Figura 13. Configuración de acciones al crear un rectángulo en la imagen. Pestaña Action.................................................................................................................... 20 Figura 14. Prototipos creados en MarvelApp. .............................................................. 20 Figura 15. Imágenes del prototipo final con MarvelApp. .............................................. 21 Figura 16. Vista de la pantalla principal del prototipo en la versión web de MarvelApp. .............................................................................................................................. 21 Figura 17. Selección de pestaña SDK Manager para configurar el SDK..................... 22 Figura 18. Pantalla de configuración de las versiones del SDK de Android. ............... 23 Figura 19. Pantalla de configuración de las herramientas del SDK de Android........... 23 Figura 20. Configuración de componentes adicionales del SDK de Android............... 24 Figura 21. Primer paso para la creación de un proyecto nuevo en Android Studio. .... 25 Figura 22. Pantalla asignación de nombre del proyecto y directorio............................ 25 Figura 23. Pantalla para la selección de la API mínima que soportará la aplicación... 26 Figura 24. Estadística de las versiones utilizadas en la actualidad. ............................ 27 Figura 25. Tipo de actividad se generará por defecto al crear el proyecto. ................. 27 Figura 26. Asignación de nombre a la Actividad principal............................................ 28 Figura 27. Primera imagen tras crear el proyecto en Android Studio. ......................... 28 Figura 28. Pasos de la detección de los XTAudioBeacons (Ultrasonidos). ................. 31 Figura 29. Esquema donde se muestra el flujo de los datos de la funcionalidad Añadir a favoritos. ............................................................................................................ 33 Figura 30. Pantalla Home con el Modo Auto OFF. ...................................................... 35 Figura 31. Vista de las pantallas cuando el Modo Auto está ON. ................................ 36 Figura 32. Interfazde Firebase. .................................................................................... 36 Figura 33. Vistas del producto detectado..................................................................... 38 Figura 34. Zoom espectro a 20.000kHz. ...................................................................... 41 Figura 35. Información de Play Store sobre Spectrum Analizer. ................................. 41 Figura 36. Información de Play Store sobre Spectrum Analize.................................... 42 Figura 37. Información de Play Store sobre ProSpec Lite. .......................................... 42 Figura 38. Espectro frecuencial del tono s16. .............................................................. 43 Figura 39. Espectro frecuencial del tono s17. .............................................................. 43 Figura 40. Espectro de frecuencias del tono s18. ........................................................ 43 Figura 41. Espectro de frecuencias del tono s19. ........................................................ 43 Figura 42. Espectro de frecuencias del tono s20. ........................................................ 44 Figura 43. Espectro frecuencial del tono s21. ............................................. Figura 44. Espectro de frecuencias del tono s22. ........................................................ 44 Figura 45. Edición de los anuncios insertando el XTAudioBeacon con iMovie............ 45 Índice de tablas Tabla 1. Diagrama con las funciones realizadas por semanas...................................... 7 0 1 Capítulo 1. Introducción 1.1 Motivación La creación de una app para Android no es ninguna novedad y cada vez resulta más complicado ser innovador dentro de este ámbito. Por otro lado, hoy en día, todas las empresas necesitan tener su propia aplicación móvil para la venta o gestión de sus productos y servicios. Parece que si no tienes tu app no existes en el mercado. Una de las intenciones del proyecto es, intentar unificar compras de varias empresas. Es decir, liberar al usuario de tener que gestionar las compras de productos de cada marca con su respectiva aplicación móvil, consiguiendo así una mayor comodidad para realizar compras o acceder a información muy concreta. La innovación viene cuando se utiliza el rango de frecuencias conocido como ultrasonido para despertar una posible compra online en los Smartphone Android. Para hacer esto posible, el Smartphone del usuario debe encontrarse cerca de un emisor, en este caso cualquier altavoz convencional servirá. Cuando el usuario escuche o visualice información sobre un producto o servicio, podrá obtener más información en su móvil simplemente abriendo la aplicación y detectando la huella digital insertada previamente en el anuncio. Si te encuentras en cualquier tienda física, o cerca de ella, desde grandes supermercados, centros comerciales o pequeñas empresas, puedes detectar las ofertas de ese momento, día o temporada, sin tener que estar informado previamente ni tener que estar pendiente de carteles publicitarios, etc. Esto se pretende conseguir únicamente con un altavoz convencional que realice funciones de emisor y un Smartphone que será el receptor. Para conseguirlo se emite un audio que actuará como huella digital, a unas frecuencias comprendidas entre 16 kHz y 22 kHz. 2 1.2 Objetivos El principal objetivo de este Trabajo de Fin de Grado es el de elaborar de principio a fin una aplicación para dispositivo móvil en Android, desde la planificación y diseño, hasta el desarrollo y lanzamiento, que permita conseguir un aprendizaje de los procesos que deben cumplirse desde que se tiene una idea general de lo que se quiere crear hasta que esa idea coge forma y se convierte al final de todas las etapas en una aplicación disponible en Play Store al alcance de cualquier usuario y perfectamente funcional. Por ello, se pretende crear una aplicación para dispositivos Android capaz de ofrecerte productos dependiendo de lo que el usuario escucha o en el lugar donde se encuentre. Cuando el usuario active dicha aplicación, esta deberá detectar un XTAudio, el cual estará asociado a una única oferta/producto. El usuario visualizará la oferta, pudiendo omitirla o comprarla. Además, tendrá la opción de añadirla a favoritos en el caso de que quiera decidirse más tarde. Todo esto se debe conseguir sin la conexión a internet con excepción de realizar la compra, ya que se redirige a la web oficial de la marca. Otro de los principales objetivos de un producto de estas características es la forma de llegar al usuario, implantando una interfaz amigable e intuitiva que permita la facilidad de uso. Por otra parte, se realiza un estudio de fiabilidad respecto al consumo de la batería estando la aplicación en constante escucha. Para ello, es necesario conseguir realizar la detección de esos audios y contar con una base de datos donde poder consultar cada huella digital. En el modo automático, es posible que existe el hándicap, de no tener un correcto funcionamiento de la aplicación por llevar el Smartphone en los bolsillos de los pantalones, bolsos o metidos en algún lugar similar. Se realizará un estudio para comprobar si los XTaudio consiguen penetrar diferentes tejidos. 3 Capítulo 2. Estado del arte En cuanto a la historia de la tecnología utilizada, Google adquiere Android Inc. en el año 2005. Se trataba de una pequeña compañía, recién creada, orientada a la producción de aplicaciones para dispositivos móviles. Ese mismo año, se empieza a trabajar en la creación de una máquina virtual Java optimizada para móviles (Dalvik VM). En el año 2007 se crea el consorcio Handset Alliance con el objetivo de desarrollar estándares abiertos para móviles. Está formado por Google, Intel, Texas Instruments, Motorola, T-Mobile, Samsung, Ericson, Toshiba, Vodafone, NTT DoCoMo, Sprint Nextel, etc. Uno de los objetivos principales de esta alianza es promover el diseño y difusión de la plataforma Android. Sus miembros se han comprometido a publicar una parte importante de su propiedad intelectual como código abierto bajo licencia Apache v2.0. En noviembre de 2007 se lanza una primera versión del Android SDK. Tras un año, aparece el primer dispositivo móvil con Android (T-Mobile G1). En octubre, Google libera el código fuente de Android, principalmente bajo licencia de código abierto Apache (licencia GPL v2 para el núcleo). Ese mismo mes se abre Android Market, para la descarga de aplicaciones. En abril de 2009, Google lanza la versión 1.5 del SDK, que incorpora nuevas características como el teclado en pantalla. A finales de 2009 se lanza la versión 2.0 y a lo largo de 2010, las versiones 2.1, 2.2 y 2.3. Durante el año 2010, Android se consolida como uno de los sistemas operativos para terminales móviles más utilizados, con resultados proóximos a iOS e incluso superando al sistema de Apple en EE.UU. En el año 2011 se lanza la versión 3.x (Honeycomb), específica para tablets, y la 4.0 (Ice Cream Sandwich), tanto para móviles como para tablets. Durante ese año, Android se consolida como la plataforma para smartphones más importante y alcanza una cuota de mercado superior al 50%. En 2012, Google cambia su estrategia en su tienda de descargas online, reemplazando Android Market por Google Play Store, donde en un solo portal unifica tanto la descarga de aplicaciones como la de contenidos. Ese año aparecen las versiones 4.1 y 4.2 (Jelly Bean). Android mantiene su espectacular crecimiento y alcanza, a finales de año, una cuota de mercado del 70 %. En 2013 se lanzan las versiones 4.3 y 4.4 (KitKat). En 2014 se lanza la versión 5.0 (Lollipop). A finales de ese año, la cuota de mercado de Android llega al 85 %. En octubre de 2015 ha aparece la versión 6.0, con el nombre de Marshmallow. En la actualidad está establecida la versión 7.0 llamada Nougat desde finales del 2016. Cada versión de Android lleva asociado un nombre se elige en orden alfabético (en Ingles) y está asociado a un dulce que es su logotipo correspondiente. 4 Capítulo 3. Metodología de trabajo En este apartado se detalla la organización seguida para el desarrollo del trabajo de final de grado así con los tiempos empleados en cada tarea y las personas involucradas para su realización. 3.1 Metodología Para la realización del proyecto se va a seguir una metodología ágil. Se ha elegido utilizar este tipo de metodologías para poder presentar la aplicación con su funcionalidad principal bien implementada y posteriormente se añaden diferentes funcionalidades interesantes para una mejor experiencia de usuario. Se decide seguir esta metodología porque se entiende que un proyecto de este tipo siempre puede mejorarse, hacerlo más eficiente o añadir posibles usos que el usuario pueda darle. Con esto, se consigue centrarse en el objetivo principal y no intentar abarcar muchas utilidades que quizá a la larga no tengan mucho sentido o no se le den uso. 3.2 Documentación y planificación Para empezar, se llevó a cabo una reunión, donde se especificaba que debería hacer la aplicación y cuáles eran las funcionalidades que debía tener. Se investigó sobre la parte acústica del proyecto, y sobre las ondas ultrasónicas que se deberían detectar. En la parte tecnológica, se realizó un curso básico pero completo de Android facilitado por desarrolladores expertos de la empresa Everis Spain. En cuanto a la planificación, se realizó un esquema general donde se organizaban las tareas, desde el diseño inicial hasta el lanzamiento de la app en Play Store o Markets alternativos. Para optimizar los tiempos y ajustarse al plazo de entrega se siguen las siguientes metodologías: - Ágil - MVP - MoSCoW 3.3 Ágil Metodología de trabajo que adapta la forma de trabar a las condiciones que el proyecto requiere consiguiendo flexibilidad para poder cumplir con plazos de entrega incluso si estos se adelantan o retrasan en el tiempo por cualquier tipo de circunstancia. Además, este método, consigue reducir costes e incrementar la productividad de las empresas. Todo esto, se traduce en una mejor satisfacción por parte del cliente, ya que no debe esperar a ver el resultado final, si no que va viendo su evolución en los plazos marcados previamente entre cliente y empresa. También tiene la ventaja de que el 5 cliente pueda opinar en cada plazo y poder decidir un cambio que será más sencillo de solucionar en dicho momento que cuando todo el proyecto esté terminado. Resumiendo, es bueno para todas las partes, la empresa reduce costes e incrementa la productividad, los desarrolladores encuentran una motivación cuando consiguen terminar llegar a su objetivo en cada plazo y el cliente percibe que se está realizando el trabajo por el cual ha pagado y puede conseguir un proyecto con el que estar más contento y de mayor calidad. 3.4 MVP MVP (Minimum Viable Product), que traducido al castellano es Producto Viable Mínimo. Es la versión de un nuevo producto que permite recolectar, con el menor esfuerzo posible, teniendo solamente aquellas funcionalidades que permiten que el producto sea lanzado y la máxima cantidad de conocimiento validado sobre sus potenciales clientes. Existen dos tipos de MVP: 1. Validando el clásico MVP, que consiste en aproximarse a clientes potenciales e intentar venderles un producto que aún no existe, si su respuesta es positiva, se ha alcanzado el éxito y en caso contrario no significa que se haya fracasado. Un claro ejemplo es el video Digg para Dropbox de Drew Houston en marzo de 2008, generando 70K inscripciones para un producto que no había sido lanzado aún. Un fallo de esta prueba no necesariamente significaría que Dropbox no funcionaría, podría significar que el umbral de calidad era mayor de lo esperado, o que los usuarios de Digg no eran los primeros clientes ideales, o que algún otro evento de noticias había distraído a los usuarios de ver o compartir el video. Independientemente, el fracaso de su validación MVP sólo invalida una pequeña forma de adquirir clientes, con un video en Digg, no todo el modelo de negocio. 2. Invalidando el MVP conserje o Mago de Oz, al caer en que se crea un producto mejor a un coste insostenible al personalizarlo para cada cliente. Es hora de seguir adelante si no se puede lograr que la gente pague un precio realista a largo plazo por un producto mejor. Jennifer Hyman y Jennifer Fleiss comenzaron Rent the Runway con este enfoque: proporcionaron un servicio de alquiler de vestidos en persona donde los estudiantes universitarios podían probar vestidos antes de alquilarlos, una experiencia mucho mejor que el alquiler en línea. Si nadie hubiese alquilado esa noche, habrían creído que el alquiler en línea no merecería la pena. Pero el 34% (y luego el 75%) de las mujeres alquiló, por lo que pasaron a validando un MVP, donde el 5% de 1.000 mujeres de su lista de correo alquiló vestidos de un PDF por correo electrónico. Aplicándolo a este proyecto, validando el MVP consistía en una app con la única función de detectar sonido ultrasónico, por su innovación. Invalidando el MVP residió en planificar por funcionalidades, es decir hasta que no estuviese funcionando correctamente la detección no se continuaba a implementar la siguiente. Como se ha comentado la más importante era la detección, luego se continuo por realizar una vista de favoritos, y continuando hasta que el plazo de entrega finalizó 6 Se optó por esta manera, ya que esto permitía tener una estructura de un producto que funcionase constantemente, empezando por la función con mayor potencial y terminando por añadir funciones extra. 3.5 MoSCoW El método MoSCoW es una técnica de priorización de requisitos basada en el hecho de que, aunque todos los requisitos se consideren importantes es fundamental destacar aquellos que permiten darle un mayor valor al sistema, lo que permite enfocar los trabajos de manera más eficiente. Lo que la diferencia de otras técnicas tradicionales como por ejemplo calificar los requisitos como de prioridad alta, media o baja es que en este caso la escala utilizada tiene un significado intrínseco, de manera que el usuario responsable de asignar la prioridad conoce el efecto real que producirá su elección. M (Must): Requisito que tiene que estar implementado en la versión final del producto para que la misma pueda ser considerada un éxito. S (Should): Requisito de alta prioridad que en la medida de lo posible debería ser incluido en la solución final, pero que llegado el momento y si fuera necesario, podría ser prescindible si hubiera alguna causa que lo justificara. C (Could): Requisito deseable pero no necesario, se implementaría si hubiera posibilidades presupuestarias y temporales. W (Won’t): Hace referencia a requisitos que están descartados de momento pero que en un futuro podrían ser tenidos de nuevo en cuenta y ser reclasificados en una de las categorías anteriores. Esta clasificación puede ser modificada durante el proceso de desarrollo y definirse, en el caso de desarrollos iterativos incrementales, prioridades a nivel de iteración. Resumiendo, junto con el cliente, se asigna una prioridad a cada requisito en cada plazo de entrega para que el proyecto cumpla las expectativas mínimas que exige el cliente y posteriormente poder implementar funcionalidades extra que le puede dar al proyecto un valor añadido. 3.6 Gestión del proyecto El proyecto se ha gestionado por Ángel Pozo Puchalt, como estudiante de la Universidad Politécnica de Valencia desde las oficinas de Madrid de Everis Spain S.L.U. Para llevar a cabo este trabajo, ha sido necesaria la ayuda: - Profesores UPV: - José Marín Roig. Asesor. - Paco Camarena. Tutor del TFG. - Gabriel Moreno Ibarra. Cotutor del TFG. - Compañeros Departamento Digital Experience Everis Spain: - Santiago Santamaria. Gerente. - Estefanía Riera. Diseñadora de apps. - Jose Luis Hurtado. Desarrollador Senior. 7 - Ricardo Martin Blanco. Becario. - Jose Javier Montes Romero. Desarrollador junior. 3.7 Distribución de tareas Las tareas las distribuye el estudiante, siendo aconsejado por las personas citadas anteriormente. En términos generales y de manera inicial se marcan los siguientes tiempos: DISEÑO FUNCIONAL Y DISEÑO TÉCNICO (será parte de la memoria del TFG) (16%) - Concebir las especificaciones del proyecto que cubran las necesidades del sistema (40 horas). - Diseño del software. (40 horas) CONSTRUCCIÓN/PRUEBAS UNITARIAS (40%) - Programación del software. (150 horas) - Implementación del sistema completo. (50 horas) PRUEBAS INTEGRADAS (20%) - Evaluación de todo el sistema y corrección de errores. (100 horas) DOCUMENTACIÓN MEMORIA / DEMO (24%) - Redacción de la memoria del trabajo fin de grado. (100 horas) - Demo de presentación (20 horas) Total: 500 horas Como se indica anteriormente, la distribución es aproximada y tras realizar todas las tareas, se realiza el diagrama del siguiente apartado mostrando gráficamente la duración por semanas de cada punto clave del proyecto. El total de horas 8 En el mes de abril, se aprecia que las primeras dos semanas se dedican a la elección del tema para el trabajo de final de grado. En este periodo reflexiono sobre cuál de los diversos proyectos que tengo en mente llevar a cabo. Los dos que más me motivaban eran: - Aplicación para la detección de impacto en vehículos estacionados. - Aplicación capaz de detectar ultrasonidos. Decidí elegir la segunda opción porque encontré la empresa donde desarrollarlo y adquirir mayores cualidades en un entorno de trabajo real. Las siguientes dos semanas me incorporé a la empresa, conocí el funcionamiento interno de la misma y estuve investigando sobre el tema. Además, comencé a repasar los lenguajes de programación que se iban a utilizar y realicé un curso muy completo sobre Android para ponerme en situación de lo que iba a tener que utilizar. Realmente es en el mes de mayo cuando comienzo a decidirle tiempo al inicio de la creación de la aplicación. Decido dedicarle aproximadamente dos semanas para la estructura que va a seguir la aplicación, para hacerla lo más sencilla e intuitiva posible para el usuario. Al diseño le he dedicado un mes, para decidir el diseño final que tendrá, ya que le doy mucha importancia a la parte gráfica y los detalles que pueda tener para impactar visualmente. La parte de desarrollo se divide en dos partes, con estudio me refiero a toda la investigación que he tenido que hacer y la información que he tenido que buscar para conseguir que funcionase cada requisito de la manera esperada. Con producción me refiero a escribir literalmente el código. Se puede observar que, desde el principio hasta el final, ambas tareas han ido prácticamente ligadas, y esto tiene sentido, ya que anteriormente nunca había realizado un proyecto parecido y debía documentarme para avanzar en cada cosa por pequeña que fuera. El siguiente bloque, pruebas y lanzamiento, con pruebas me refiero al tiempo que se ha probado la aplicación con la mayoría de funcionalidades implementadas y cómo se comportaban con el código más complejo cada vez. Y con lanzamiento quiero decir la elección del repositorio/market donde subir la aplicación, así como la subida como tal de la apk de la aplicación, y el proceso de distribución de la misma. Como es lógico, la memoria de este proyecto se decide empezarla casi al final. En mi caso, decido hacerlo de este modo para afianzar cada uno de los conceptos y métodos que se utilizan a lo largo de la creación de la aplicación y tener una visión más general del trabajo realizado. 9 Capítulo 4. Conceptualización y diseño Este paso previo a la programación, es de vital importancia ya que nos ayuda a definir mejor la app tanto visualmente como por la parte de funcionalidad y acabado final de la mima. Los pasos seguidos fueron: 1. Realización de un esquema con BUBBL.US (https://bubbl.us), para obtener un mapa mental de todas las funcionalidades de la app, y también para hacerse la idea del Customer Journey (la experiencia del cliente que se quiere alcanzar) 2. Una vez que se tiene un esquema general, se empieza a dibujar las pantallas con papel y lápiz, sin focalizarse en detalles como iconos, imágenes o textos. 3. Cuando se tiene el número de pantallas previamente dibujadas, se empieza a hacer wireframes con SKETCH. 4. Una vez ya tengamos definidos los wireframes anteriores, se realiza un prototipo para ver el resultado final de cómo debe ser la app. En este caso se exportan los diseños a MarvelApp y se les da vida a las pantallas. 4.1 Mapas mentales Como primera idea se pensó en el siguiente mapa. Figura 1. Mapa mental v1 de la estructura de la app. Tras revisarlo con diseñadores y desarrolladores, se decidió realizar varios cambios, quedando el siguiente mapa. 10 Figura 2. Mapa mental v2 con la estructura de la app. Las diferencias entre ambas figuras, son realizadas para una mejor experiencia de usuario, para hacer la aplicación más intuitiva y más fácil de manejar. Por otro lado, también el mapa mental sufre cambios por motivos de las llamadas guías de estilo de Android. Las guías de estilo son documentos donde se indica el formato y el diseño que deben tener por lo general las aplicaciones de Android. Esto fue un reto para mí, porque soy usuario de iOS desde 2008, con lo cual, tuve que investigar y aprender cómo era el funcionamiento de las aplicaciones en Android, las partes de la pantalla, la función de cada botón, los gestos más comunes, donde colocar el menú y los ajustes, el botón atrás, etc. Junto a la ayuda de diseñadores de aplicaciones de la empresa, se decidió la versión 2 como esquema general para estructurar todas las funcionalidades que tenía pensadas que debía tener la aplicación y tenerlo bien organizado. 4.1.1 Bocetos del diseño inicial Siguiendo el consejo de los diseñadores se dibujó una serie de pantallas con sus estructuras generales y posibles logo de la aplicación. En la siguiente figura se observan cuatro de las seis vistas pensadas para la visual de la aplicación. 11 Se puede observar que la idea es tener un registro del usuario y posteriormente una pantalla principal donde tener diferentes modos junto a las últimas ofertas detectadas. En la vista ofertas se aprecia una Card que dependiendo hacia donde la mueves aceptas o rechazas el producto junto a unos botones de compartir y más información. En la siguiente imagen se encuentran las vistas restantes. Figura 3. Vistas iniciales que tendría la aplicación. 12 Se observa una vista Now la cual al presionar en el centro de la pantalla empezaría la detección junto a un botón de menú y una barra inferior con diferentes opciones de navegación entre actividades. En la vista de Ajustes se encuentras las opciones futuras que podría tener la aplicación. En esta última figura se decide mostrar el aspecto inicial que iba a tener el logo o icono de la aplicación. Como se ven en las figuras anteriores, en un primer se pensó en llamar a la aplicación UltraMarkt por los ultrasonidos y la parte de marketing que tiene, por ese motivo en los siguientes logos se juega, tanto con el nombre como con las iniciales. Figura 4. Vistas Now y Ajustes que tendría la aplicación. Figura 5. Diseño de logos/iconos iniciales de la aplicación. 13 Además de intentar darle sentido con el nombre y sus iníciales, se intenta jugar con el murciélago por dos motivos, es el animal que representa a mi ciudad de origen además de que concretamente los murciélagos utilizan los ultrasonidos para orientarse y gracias a que estas ondas se reflejan en su entorno tienen la manera de percibir objetos u obstáculos, resumiendo es si forma de ver. 4.1.2 Wireframes Llegados a este punto la siguiente tarea consiste en digitalizar las ideas previamente expuestas. Para ello se crea un proyecto con Sketch. En este proyecto se deben dibujar todas las vistas pensadas e introducir mejoras siempre que sea posible. En esta etapa se observa que si volvemos a los mapas mentales de las figuras 1 y 2 la estructura se muestra cambiante entre la versión del mapa uno y la versión del mapa dos. Esto es normal, porque mientras avanza el proyecto se va revisando y comprobando cual es la mejor forma de implementar las cosas tanto por la parte de desarrollo como para la parte de experiencia al usuario. En la siguiente figura se observa las vistas pintadas del proyecto mencionado en su primera versión. 14 Figura 6. Versión 1 de las vistas de la aplicación con Sketch. 15 Una vez, la aplicación ya va cogiendo forma y mayor organización entre vistas, se decide cambiar el diseño para una experiencia mejor por parte del usuario, más llamativa, más moderna y sobre todo más cercana a los estilos de Android llamados Material Desing. Estos modelos son guías que te indican como tienes que ser los textos los iconos, donde debe ir el menú, como deben interactuar entre sí las vistas, etc. Esta parte, para mí fue bastante tediosa y tuve que hacer un ejercicio de investigación importante, porque yo desde 2008 con la salida del iPhone 3G, no había utilizado un Smartphone con sistema operativo Android, es decir, nunca. Así que desde la primera versión pintada hasta la final iba conociendo nuevas partes de las pantallas de Android, lo que se podía y no se podía utilizar, básicamente por la parte de la programación, porque Android para eso es bastante permisivo, permite cualquier estilo que se desee. Pero las ActionBars y las NavgationBars Android siempre las tiene muy presentes y hay que utilizarlas en muchos casos para ciertas acciones. Como resultado de este ejercicio en las siguientes imágenes se muestran las vistas pintadas en formato digital las cuales formaran parte del prototipo explicado más adelante. 16 Figura 7. Versión 2 de las vistas de la aplicación. Actividades del modo auto apagado. 17 En las figuras 7 y 8 se muestran las vistas tanto con el Modo Auto activado como en modo desconectado. La diferencia principal es que la StatusBar que es la barra superior del sistema operativo cambia de color para alertar al usuario de que esta función esta actividad. El icono del micrófono de la pantalla principal también cambia y para que el usuario sepa que tanto desde ahí como del menú que aparece por la parte de la izquierda se puede encender y apagar esta funcionalidad. Figura 8. Versión 2 de las vistas pintadas de la aplicación, actividades con el modo auto activado. 18 4.1.3 Prototipo Es este apartado se muestran los proyectos creados con MarvelApp para diseñar el prototipo que en un proyecto real se enseñaría al cliente previamente a la contratación del servicio y este se hiciese una idea del resultado final. Para llevar a cabo este proyecto se utilizan las vistas pintadas con Sketch de los Wireframes explicados en los puntos anteriores. Con este paso, lo que se consigue es dotar de movimiento a las imágenes dando un efecto similar al que tendría la aplicación una vez estuviese implementada con código. Es importante remarcar que el prototipo no tiene nada de código detrás, únicamente a cada vista se le indica que acción realizar cuando el usuario toque en ciertas partes de la pantalla. Las acciones siempre serán navegar a otras imágenes insertada en el proyecto y se pueden personalizar los lugares donde el cliente puede interactuar y la transición entre imágenes que se desea para dotar de más realismo la demostración. MarvelApp dispone de página web donde se puede realizar todo el prototipo. En primer lugar, se exportan las vistas diseñadas con Sketch y posteriormente se suben a la web de MarvelApp para indicarlas las acciones explicadas. En la siguiente imagen se muestra el primer prototipo con algunas de las vistas que se utilizan. Como se observa se cargan las imágenes, y se exportan en el mismo tamaño que le indicamos que debía tener en Sketch y los mismos títulos para tener una mayor organización. En este caso no es necesario, pero en proyectos reales en este proyecto podemos encontrar cientos de imágenes y puede suponer una labor bastante complicada. La primera imagen es donde subimos el diseño que tendrá el icono de la aplicación. Esto le da un valor añadido porque estos prototipos a través de un link se pueden visualizar en los smartphones independientemente sean Android o IOs, y pueden Figura 9. Primer prototipo de la aplicación con MarvelApp. 19 quedar más reales creando un acceso directo al link en los móviles. Haciendo esto, MarvelApp utiliza la imagen llamada App icon como simulación del icono. Cuando se accede a una de las imágenes se visualiza lo mostrado en la Figura 10. Aquí se puede fijar los márgenes de la pantalla con Fixed header y con Fixed Footer. Con esto, podemos crea sensación de scroll en cuando el cliente este navegando por esta vista, siempre y cuando la imagen sea más larga que el tamaño del dispositivo. Con el botón Play una vez tenemos todo configurado se visualiza como ha quedado la simulación. Dicha simulación se consigue seleccionando diferentes partes de la imagen median recuadros dibujados por nosotros mismos para seleccionar toda la zona que realizar la transición. En la figura 11 se ve la pestaña de Hotspot Destination en la cual se elige la imagen a la que se navega al hacer click en la zona seleccionada. Figura 10. Muestra las opciones cuando accedemos a una de las imagenes. Figura 11. Configuración de acciones al crear un rectángulo en la imagen. Pestaña Hotspot Destination. Figura 12. Configuración de acciones al crear un rectángulo en la imagen. Pestaña Screen Transition. 20 En la figura 12 se muestra la pestaña de Screen transition. Aquí se le indica que efecto se utiliza cuando se lleva a cabo la transición. Figura 13. Configuración de acciones al crear un rectángulo en la imagen. Pestaña Action. En esta figura 13, se visualiza los tipos de acciones que puede realizar el cliente sobre la pantalla y cuando se realice el seleccionado la transición se hará efectiva. Una vez explicado el funcionamiento de esta herramienta, es necesario explicar que las imágenes son del prototipo versión 1. Por cada, wireframe se realizó un prototipo para tener más claro cuál sería el resultado final. En la siguiente figura se muestran los dos proyectos que albergan los dos prototipos.

programacion de android  studio 2018