Memoria

Introducción

Con la idea de realizar una aplicación con la que poder experimentar en lo referente a la interacción con el entorno y con el procesamiento de información multimedia, tuvimos la idea de realizar una aplicación que genera sonidos y música a partir del movimiento. El proyecto no debía llevar demasiado tiempo y debían emplearse tecnologías accesibles. Las limitaciones de las tecnologías que empleamos nos hicieron replantear el proyecto hasta un concepto algo más simple que el original, produciendo una aplicación capaz de reproducir sonidos, ya sea una sola vez o en bucle. Se asocian distintos sonidos a distintas zonas alrededor del usuario utilizando para ello el giroscopio.

El uso de tecnologías desconocidas para varios miembros del equipo, junto a la falta de experiencia trabajando en el apartado de procesamiento de multimedia y de control de gestos de un dispositivo, ha producido ciertos problemas en el producto final que no han podido ser solucionados por falta de tiempo. Para que otros puedan saber con antelación lo que a nosotros nos ha llevado aprender semanas, escribimos este documento.

En el punto 3 se describe cronológicamente el desarrollo del proyecto sin entrar en detalle en las tecnologías y metodologías utilizadas. Estas se describen en profundidad en los demás apartados de la wiki.

Desarrollo del proyecto

Brain Storming

Ideas para la aplicación

En una primera reunión entre los miembros del grupo se debate hacia dónde enfocar la aplicación teniendo en cuenta el requisito de utilizar tecnologías multimedia. En este momento surgen dos ideas principales, hacer música con el teléfono móvil mediante gestos o hacer música con el teléfono móvil mediante el mapeo de movimientos del usuario mientras hace “footing”. Entre estas dos ideas se decide llevar a cabo la de hacer música con gestos, ya que nos pareció a los cuatro miembros que se podría hacer una aplicación más entretenida y divertida. La razón de descartar la otra idea es que como se trata de un proyecto en un corto periodo de tiempo nos pareció que iba a ser difícil conseguir un movimiento armónico a partir de los movimiento de un corredor, además de que la música se compondría de forma aleatoria por los movimientos del corredor no permitiendo a este ser partícipe de la creación musical en mayor medida que asignando un ritmo, corriendo más despacio o más deprisa.

En resumen la idea de los gestos permitiría más funcionalidades y más interacción con el usuario, que es el fin de una aplicación multimedia.

Entonces se empieza a pensar en varias funcionalidades que puede tener nuestra aplicación cómo hacer sonidos por gestos o grabar, entre otras. Esta discusión de funcionalidades nos ayuda a elegir mejor las tecnologías que vamos a utilizar,

Tecnologías

Una vez concretada la idea, empezamos a decidir qué tecnologías utilizar o en qué patrones y frameworks nos vamos a apoyar para realizar nuestro proyecto.

Entorno de trabajo

Se utiliza GitHub. Esta decisión viene dada como requisito del proyecto para facilitar el seguimiento del trabajo. Sin este requisito hubiéramos optado seguramente por la misma herramienta o Bitbucket en su defecto.

Aplicación

Desde un principio se decide utilizar el framework React Native para aplicaciones móviles, ya que facilita mucho el desarrollo en nativo, es simple, y dispone de librerías para interactuar con los sensores del teléfono móvil, que es en lo que se basa nuestra aplicación. Además de ofrecer un core común para Android e iOS.

El prototipo

Diseño del prototipo

En esta fase se decide utilizar “Redux” para organizar la arquitectura de la aplicación de manera similar al Modelo-Vista-Controlador, conocido por todos los integrantes del grupo, pero de manera más eficiente.

En un principio la idea es elegir un grupo de sonidos mediante la brújula del móvil y hacer sonar cada sonido de ese grupo mediante el acelerómetro, moviendo el teléfono en horizontal, hacia izquierda, derecha, adelante y atrás.

Bajo esta idea se reparten las tareas de la siguiente manera:

• Arquitectura Redux: Flujo y organización del sistema.
• Pruebas con el giroscopio (Brújula): Elección de sección o grupo de sonidos.
• Pruebas de sonido: Ejecución de sonidos y pruebas de los tipos de archivo de audio.
• Pruebas con el acelerómetro: Elección de gestos y movimientos.
• Interfaz

Se realizan prueba con las diferentes librerías encontrando algunas problemas en:

• Pruebas de sonido
• Pruebas con el acelerómetro

Implementación del prototipo

Organización

• Containers: Segmentamos el desarrollo de la aplicación en diferentes partes o módulos (container) y en cada uno se realizan las pruebas del ámbito de desarrollo (Giroscopio, Acelerómetro, Sonidos). También se crea un container “Prototipo” en el que se integra todo tras hacer las pruebas.

• Ramas de Github: Se crea una rama “master” para subir las versiones (producción). Una “developer” en la que se prueba la aplicación con todos los módulos integrados antes de pasarla a producción. Y ramas “feature-x” en las que cada uno desarrolla su tarea para luego integrarlas en “developer”.

• Travis: A mitad del proceso de implementación del prototipo se empieza a utilizar Travis consiguiendo montar la aplicación en un servidor para hacer pruebas de compilación del mismo. Solo se admiten pull request de las ramas si Travis ejecuta de manera satisfactoria sus pruebas.

Tareas

• Arquitectura e integración
• Giroscopio
• Sonido
• Acelerómetro
• Interfaz

Desarrollo de tareas

Durante el desarrollo nos encontramos con algunos problemas minoritarios como la recogida de datos del acelerómetro, la cual es diferente en iOS y Android.

Aplicación final

Brain storming

Una vez entregado el prototipo se vuelve a una fase de Brain-Storming en la que se debaten las nuevas funcionalidades o mejoras para añadir al prototipo.

Por un lado se piensa en mejoras de funcionalidad:

• Inclusión de nuevos gestos.
• Mejora de la interfaz
• Inclusión de varias retículas, cada una con diferentes sonidos.

Por otro lado se piensa en añadir nuevas funcionalidades y posibilidades para el usuario:

• Sonidos personalizados mediante grabación.
• Realidad aumentada.

Investigación

Se investigan las nuevas funcionalidades, Realidad Aumentada y personalización de sonidos. La realidad aumentada se descarta debido a la complejidad y al tiempo hasta la entrega del proyecto. Junto con otras asignaturas se hace imposible implementar esa función.

Implementación de la aplicación final

Tareas

• Inclusión de nuevos gestos
• Mejora de la interfaz
• Inclusión de varias retículas, cada una con diferentes sonidos.
• Personalización de sonidos.

Desarrollo de tareas

Para desarrollar estas nuevas tareas seguimos la misma organización que en el prototipo. El único problema que encontramos en la implementación de las mejoras es que Android tiene dificultades para correr la aplicación correctamente con varias retículas mientras que en iOS funciona a la perfección.

Análisis postmórtem

Durante el desarrollo del proyecto se ha ido documentando la Wiki con las tecnologías y los métodos utilizados en el proyecto así como actualizando la descripción de la aplicación cuando surgieron cambios.

Una vez acabada la aplicación se ha revisado la wiki y completada junto con la memoria o análisis postmortem.

Análisis de las causas de los problemas

• Acelerómetro: Se ve la dificultad para mapear los sonidos ante una aceleración espontánea en uno de los ejes. Esto es debido a que el valor de la aceleración sube y baja demasiado rápido al realizarse en un periodo de tiempo de 1 segundo o menos, y por otro lado a que es difícil que el usuario haga el movimiento siempre con la misma aceleración. Los valores suben y bajan tan rápido que ni siquiera nos da tiempo a verlos en la interfaz para poder establecer un rango en el que cambiar de sonido.

• Sonido: Se encontró que algunos tipos de archivos no son reproducidos por la librería RNSound, funcionando MP3 y WAV. Otro problema encontrado fue una incompatibilidad entre iOS y esta librería, que necesita el uso de “require” para la inclusión de los sonidos.

• Mapeo acelerómetro iOS/Android:También nos encontramos con que iOS y Android no recogen los mismos valores del acelerómetro. Mientras que para iOS la gravedad tiene un valor 0.98, para Android el valor es 9.8.

• Realidad Aumentada: Las tecnologías de AR son complejas para conseguir integrarlas en nuestra aplicación en el tiempo estipulado.

• Varias retículas en Android: En Android la aplicación funciona demasiado lento cuando se utilizan cuatro retículas debido a la carga de procesamiento.

Impacto y daños causados

• Acelerómetro: El mapeo de los datos del acelerómetro tuvo un impacto importante en el desarrollo del proyecto ya que nos obligó a cambiar el diseño de la aplicación respecto a cómo reproducir los sonidos.Esto implicó utilizar los gestos de otra manera, obligando también a disminuir la posibilidad de sonidos. Se pasa de utilizar una retícula con 4 sonidos en cada sección a utilizar una retícula con un sonido en cada sección. Por otro lado el equipo se dió cuenta de esta limitación en una primera fase de pruebas antes de empezar a desarrollar la aplicación. De esta manera el efecto fue solo cambiar de idea de diseño, sin tener que volver a implementar ninguna parte de la aplicación.

• Sonido: Los formatos de los archivos de audio provocaron una reducción de las posibilidades que había. La mayoría de los samples tienen formatos que no son aceptados por la librería usada. El problema del “require” fue importante, pues no se podía reproducir ningún sonido en iOS.

• Mapeo acelerómetro iOS/Android: Nos damos cuenta de este error en la integración de los módulos debido a que las pruebas se realizaron con Android y en la integración al utilizar iOS fallaba. Rápidamente se reconoce el fallo y se arregla por lo que el impacto es mínimo.

• Realidad Aumentada: EL impacto de la complejidad de la tecnología nos obliga a eliminar esta funcionalidad de nuestros objetivos centrándonos en los demás. Aunque se ha invertido tiempo en la investigación de la tecnología no se ha derrochado en su implementación por lo que el impacto respecto al tiempo es pequeño.

• Varias retículas en Android: Durante las pruebas no se encuentra este error al haberse hecho con iOS, encontrándonos con el fallo en la integración de los módulos y al probarlo con Android. Debido al tiempo esto provoca que la demo en la presentación no funcione como se esperaba y se tenga que hacer solo con una retícula.

Acciones tomadas ante los problemas

• Acelerómetro: La brújula se utilizará para elegir un sonido u otro de una única retícula y el acelerómetro se encargará de reproducir ese sonido. La diferencia es que en vez de captar el aumento de la aceleración en un eje (x,-x,z,-z), se captará el cambio de la aceleración de un eje a otro. El eje que apunta hacia el suelo siempre tendrá un valor entorno a 9,8 por la fuerza de la gravedad. De modo que es fácil mapear el movimiento del teléfono cuando pasa de vertical a horizontal, y por lo tanto, la fuerza de la gravedad pasa de un eje a otro.

• Sonido: La solución a los formatos fue buscar siempre archivos WAV o MP3, aunque el primero sea propietario. También, para poder usar los samples que estaban en un formato no aceptado, se usó un programa de edición de audio para cambiar el mismo del que fuese a mp3. Para solucionar el problema del “require” se añadieron las rutas relativas de los samples.

• Mapeo acelerómetro iOS/Android: La solución a este problema es simplemente multiplicar por 10 la variable cuando estamos el iOS.

• Realidad Aumentada: No implementar AR.

• Varias retículas en Android: Por falta de tiempo la corrección de este problema se realiza disminuyendo el número de retículas de Android e iOS de cuatro a sólo dos. Con más tiempo para desarrollar o corregir se hubiera procedido a una optimización del código que permitiera el uso de cuatro retículas en los dos sistemas.

En esta tabla se recogen los problemas y el impacto que han tenido en un rango de 0 a 5. Se tiene en cuenta tanto el impacto en el diseño y la implementación como en el tiempo perdido.

Problema	Impacto (Implementación)	Impacto (Tiempo)
Acelerómetro	4	2
Sonido	1	1
Mapa Acelerómetro	2	1
RA	3	3
Varias retículas	4	2

Conclusiones

¿Qué se hizo bien?

• Organización GitHub
• Organización de la aplicación en módulos (containers) para desarrollar las diferentes tareas.
• Pruebas con las librerías antes de comenzar con la implementación
• Patrón Redux

Al querer realizar una aplicación que fuese multiplataforma y que pudiera accederse sin problemas a recursos como el sistema de archivos del sistema, la elección de React Native como framework de desarrollo fue un acierto. Junto a este, la elección de librerías para el acceso a los recursos que necesitábamos para poder ofrecer las características que se buscaban también ha sido un acierto, y es que, aunque no hay muchas alternativas a aquellas que hemos escogido, las librerías elegidas han cumplido con las expectativas que teníamos.

El paso al Git Workflow también resultó en una mejor organización y administración del trabajo entre los distintos integrantes del equipo, trabajando de forma más independiente cuando así era necesario. En conjunto con el Git Workflow, el uso de Issues en Kanban, permitió la comunicación entre el equipo a la hora de administrar los problemas y comprobar el estado actual del proyecto en todo momento de una forma más rápida y cómoda.

La organización de Github y de los módulos independientes para el desarrollo también ayudó en gran medida a facilitar la integración de la aplicación y el trabajo en paralelo.

¿Qué se hizo mal?

• No contamos con que algunos miembros utilizaban Android mientras que otros iOS por lo que al repartir las tareas y al hacer las pruebas cada uno utilizaba el sistema del que disponía. Esto supuso que algunos errores, como la diferencia de datos del acelerómetro entre iOS y Android, no se encontraran hasta el momento de integrar todas las partes y probarlas en los dos sistemas. En resumen se debería haber sido más riguroso en las pruebas de las librerías y de cada funcionalidad con ambos sistemas, iOS y Android.
• Debido a la organización del tiempo y a la confianza por haber realizado pruebas de cada módulo antes de la integración se fijó poco tiempo para las pruebas de integración encontrando algunos errores, que aunque resueltos, se podía haber propuesto soluciones más eficientes y eficaces. Aunque en general no supuso un problema mayoritario, podía haberlo sido.

Lecciones aprendidas

• Metodología de trabajo en grupo y utilización de github para realizar las tareas
• Conocimiento de tecnologías para el desarrollo de aplicaciones móvil (Librerías, Framework, Patrón de diseño).

Futuro

• Optimización del código para que todo funcione en tiempo real de manera adecuada.
• Inclusión de tecnología AR para ver los instrumentos.
• Mayor funcionalidad:
  • Inclusión de más retículas y más sonidos.
  • Inclusión de más gestos.
  • Inclusión de una librería de sonidos en la que el usuario pueda guardar nuevos sonidos, ya se por grabación o añadiendo el archivo de audio a la aplicación desde el dispositivo, y utilizarlos posteriormente.
  • Posibilidad de guardar las melodías creadas.