T rabajo F in al de G rad o
GRADO EN INGENIERÍA ELECTRÓNICA INDUSTRIAL Y AUTOMÁTICA
A. M. Autoescuela Súper Express S.L.
VÍCTOR MANUEL BEA GONZÁLEZ
Tutor
Dr. Bartolomé Jaime Serra Cifre
Escuela Politécnica Superior
Universitat de les Illes Balears
´Indice general
1. Introducci´on y Objetivos 1
1.1. Introducci´on. . . 1
1.2. Objetivos . . . 2
1.3. Estructura de la memoria . . . 2
2. Estado del arte 3 2.1. Bloque 1: Dispositivo m´ovil . . . 4
2.1.1. Mercado . . . 6
2.2. Bloque 2: Sistemas operativos para SmartPhones . . . 7
2.2.1. Mercado actual de los S.O. m´ovil m´as utilizados . . . 7
2.2.2. Caracter´ısticas de los S.O. m´ovil m´as utilizados . . . 9
2.2.3. Versiones Android . . . 10
2.3. Bloque 3: Entorno web . . . 11
2.3.1. WebService . . . 11
2.4. Bloque espec´ıfico (4): Tecnolog´ıas en Android . . . 13
2.4.1. Reproducci´on de v´ıdeo . . . 13
2.4.2. Conexi´on con el servidor. . . 16
3. Requerimientos y herramientas de desarrollo 18 3.1. Requisitos . . . 18
3.2. Herramientas necesarias para el desarrollo . . . 20
3.2.1. Eclipse. . . 20
3.2.2. XAMPP . . . 20
3.2.3. Android Studio . . . 20
3.2.4. Genymotion. . . 20
3.2.5. Advanced Rest Client . . . 21
4. Desarrollo 22 4.1. Resoluci´on de problemas . . . 23
4.1.1. Estudio de funcionamiento de la plataforma web . . . 23
4.1.2. WireFraming . . . 24
4.1.3. Servicio web . . . 27
4.1.4. Base de datos . . . 27
4.1.5. Conexi´on con el servidor. . . 30
4.1.6. Sincronizaci´on . . . 31
4.1.7. Reproducci´on de V´ıdeo . . . 33
´INDICE GENERAL
4.1.8. Carga de im´agenes . . . 34
4.1.9. Listas en Android . . . 34
4.2. Implementaci´on . . . 37
4.2.1. Activity de Presentaci´on . . . 37
4.2.2. Login . . . 38
4.2.3. Actualizaci´on de datos . . . 40
4.2.4. Men´u principal . . . 41
4.2.5. Lista de Temas . . . 42
4.2.6. Lista de Tests . . . 45
4.2.7. Repaso . . . 49
4.2.8. Otras opciones de men´u: d´ıas restantes, sistema de luz verde y salir 50 4.3. Pruebas de campo . . . 52
5. Propuestas futuras y conclusiones 53 5.1. Propuestas futuras . . . 53
5.2. Conclusiones . . . 54
A. iOS 58 A.1. Descripci´on . . . 58
B. An´alisis de la web 60 B.1. Temas . . . 60
B.1.1. An´alisis web de un Tema . . . 63
B.2. Tests . . . 64
B.2.1. Un test . . . 65
B.2.2. Pregunta test . . . 67
B.3. Repaso. . . 67
C. Wireframings 68 D. Sync Service 70 D.1. Descripci´on . . . 70
E. Fragmentos de c´odigo 72
F. Pruebas de campo 80
´Indice de figuras
2.1. Esquema de bloques que ponen de manifiesto las tecnolog´ıas que envuelven
este proyecto. . . 4
2.2. Equipamiento de las viviendas en algunos productos de tecnolog´ıas de in- formaci´on y comunicaci´on. . . 6
2.3. Comparaci´on del mercado de los smartphones y los m´oviles cl´asicos. . . 7
2.4. Comparaci´on usuarios sistema operativo m´oviles y tablets en Espa˜na. . . . 8
2.5. Cuota de mercado Febrero 2016 en Espa˜na. . . 8
2.6. Arquitectura de Android. . . 9
2.7. Versiones Android . . . 11
2.8. SOAP vs REST . . . 12
2.9. YouTube y Vzaar. . . 13
2.10. VideoView vs WebView. . . 14
2.11. Formatos de v´ıdeo soportados en Android . . . 15
4.1. Esquema de la estructura de desarrollo. . . 22
4.2. Estructura solicitada del men´u de la Web . . . 23
4.3. Esquema simplificado de las pantallas (wireframing). . . 24
4.4. Pantalla de actualizaci´on (wireframing). . . 25
4.5. Wireframing de las pantallas principales. . . 26
4.6. Esquema RESTful - HTTP. . . 28
4.7. Esquema de gesti´on de la base de datos SQLite.. . . 29
4.8. Esquema de una funci´on del modelo de datos. . . 30
4.9. Piezas Sync Adapter.. . . 33
4.10. Puntos de posici´on en un Pager. . . 37
4.11. Diagrama de flujo de Login. . . 38
4.12. Captura de la pantalla de Login. . . 39
4.13. Captura de pantalla de la sincronizaci´on. . . 40
4.14. Icono men´u Material Design. . . 41
4.15. Esquema de Activity y Fragments. . . 41
4.16. Captura de pantalla de Temas. . . 43
4.17. Esquema 1 - Un Tema. . . 43
4.18. Captura de pantalla de un tema. . . 44
4.19. Esquema 2 - Un V´ıdeo. . . 44
4.20. Captura de pantalla de un test durante un v´ıdeo. . . 45
4.21. Captura de pantalla de la lista de Tests. . . 46
´INDICE DE FIGURAS
4.22. Captura de pantalla que pregunta al alumno si quiere continuar el test o
abandonarlo. . . 47
4.23. Esquema 3 - Un Test. . . 47
4.24. Estados de radioButtons. . . 48
4.25. Captura de pantalla de una pregunta de test y su acci´on. . . 49
4.26. Captura de pantalla del sistema de luz verde. . . 50
4.27. Captura de pantalla de informaci´on de fecha de caducidad. . . 51
A.1. Arquitectura de iOS . . . 58
B.1. Apartado de Temas en la Web . . . 60
B.2. Indicador de aprendizaje (no estudiado y estudiado). . . 61
B.3. Casu´ıstica de clics en el apartado de Temas. . . 62
B.4. Diagrama de flujo de un v´ıdeo interactivo. 1 - Se pausa el v´ıdeo; 2 -Se muestra la pregunta; 3 - Se realiza el test; 4 - Continua la reproducci´on del v´ıdeo. . . 63
B.5. Dise˜no y acciones en un Tema. . . 64
B.6. Iconos de estado de un test general. . . 65
B.7. Lista de Tests. . . 65
B.8. Flujo de un test. . . 66
B.9. Una pregunta de test en la web.. . . 67
C.1. Pantalla de presentaci´on (wireframing). . . 68
C.2. Pantalla delogin (wireframing).. . . 69
´Indice de fragmentos de c´odigo
4.1. Permisos de conexi´on en Manifest. . . 31
4.2. Interfaz de VolleyCallback. . . 31
4.3. Uso de Glide . . . 34
D.1. Forzar una sincronizaci´on manual del Sync Adapters.. . . 71
E.1. Utiles de preferencias. . . 72
E.2. Control de peticiones permiticas en el servicio . . . 72
E.3. Respuesta JSON desde el servidor . . . 73
E.4. Valores clave de preferencias. . . 73
E.5. DatabaseManager. . . 73
E.6. Tabla TestGeneral . . . 74
E.7. Clase contenidosModelo . . . 74
E.8. Transacciones en Android. . . 75
E.9. Interfaz de VolleyCallback . . . 76
E.10.Ejemplo petici´on POST con Volley . . . 76
E.11.Validaci´on de correo electr´onico. . . 77
E.12.Actualizaci´on de la ProgressBar. . . 77
E.13.Controlador del NavigationView. . . 77
E.14.Polling de v´ıdeo. . . 78
Resumen
La autoescuela S´uper Express solicit´o la creaci´on de una aplicaci´on para dispositivos m´oviles que ofreciera una forma tecnol´ogica de estudiar la parte te´orica del permiso de conducci´on. Para ello, ha sido necesario realizar un estudio en profundidad de las tecno- log´ıas asociadas a los dispositivos m´oviles, y en concreto, de las t´ecnicas de reproducci´on de v´ıdeo.
Esta idea surge de la oportunidad de mercado que supone ofrecer a los usuarios de la empresa una herramienta que se adapte a sus necesidades y costumbres. Estos usuarios son personas j´ovenes, con edades comprendidas entre los 18 y 24 a˜nos mayoritariamente, y cuya vida cotidiana est´a basada en Internet y en las diferentes tecnolog´ıas de la informaci´on y comunicaci´on. Mediante la creaci´on de esta aplicaci´on, se brindar´a la oportunidad a todos aquellos usuarios que lo deseen, de poder estudiar la te´orica de una forma c´omoda y adaptada a sus h´abitos cotidianos, pues lo har´an directamente desde su smartphone y sin necesidad de desplazarse a un centro ni de disponer de conexi´on a Internet.
Para el desarrollo de la aplicaci´on, lo primero que se ha tenido en cuenta es el Siste- ma Operativo que deb´ıa utilizarse. En este caso, se ha desarrollado en Android, pues se trata del sistema operativo l´ıder en el mercado, presente en 8 de cada 10 smartphones.
La ejecuci´on del desarrollo Android ha estado marcada por los requisitos solicitados por la empresa demandante, destacando los apartados que debe contener, el tipo de sincro- nizaci´on, la reproducci´on de v´ıdeo o la conexi´on al servidor. Adem´as, destaca el an´alisis realizado para la reproducci´on de v´ıdeo desde los hostings Vzaar y YouTube.
Concluido el desarrollo, durante las pruebas de campo realizadas mediante encuestas, los resultados muestran que se trata de una aplicaci´on funcional, intuitiva y fluida. Por tanto, ´este proyecto cumple con el objetivo de ser una plataforma de ense˜nanza te´orica para el permiso de conducir, y que gracias a la utilizaci´on del sistema operativo Android logra alcanzar a un gran n´umero de usuarios.
1
Introducci´ on y Objetivos
1.1. Introducci´ on
El transporte de personas y mercanc´ıas tiene sus or´ıgenes desde la existencia del hom- bre, siendo ´este un fen´omeno que involucra temas sociales, econ´omicos, hist´oricos y jur´ıdi- cos.
Es en el a˜no 1948, cuando la Declaraci´on Universal de Derechos Humanos (art. 13.1) [1]recoge el derecho a circular libremente. Es en este momento cuando se toma conciencia de los riesgos que ello comporta, surgiendo as´ı, la necesidad de trabajar para minimizarlos.
Con la llegada de los primeros autom´oviles a Espa˜na, apareci´o un nuevo hobby para la poblaci´on que desencaden´o en numerosos accidentes debido a la falta de normativa.
El 17 de septiembre de 1900 [2] se aprueba el “Reglamento para el Servicio de Coches Autom´oviles por las Carreteras del Estado” y se matricula el primer veh´ıculo, que recibi´o la matr´ıcula PM-1.
No tardaron en aprovechar esta nueva afici´on para abrir los primeros centros de en- se˜nanza, con clases te´oricas y pr´acticas, cre´andose en 1907 la escuela de “chauffeurs” en Barcelona. En la actualidad los centros de ense˜nanza reciben el nombre de autoescuela, defini´endose este concepto por la R.A.E. como:
“Centro para ense˜nar a conducir autom´oviles.”
Actualmente hay un listado de 4.786 autoescuelas o centros de ense˜nanza que imparten clases te´oricas y pr´acticas.
La importancia de este sector se refleja con los propios datos de la DGT, los cuales indican que durante el 2015 en Espa˜na [3]se expidieron un total de 710.532 permisos de conducci´on, de los cuales 465.000 fueron permisos tipo B.
Estructura Introducci´on y Objetivos
Las autoescuelas como centros de ense˜nanza de educaci´on vial apenas han variado su sistema a la hora de impartir conocimientos. Para adaptarse a las necesidades de la socie- dad actual, ´estas, al igual que est´a sucediendo con las dem´as instituciones de educaci´on, deben flexibilizarse [4]y desarrollar v´ıas de integraci´on de las tecnolog´ıas de la informaci´on y la comunicaci´on en los procesos de formaci´on.
La autoescuela S´uper Express se˜nala en sus estudios de mercado que su target se encuentra entre un p´ublico de 18 a 24 a˜nos (tambi´en llamados generaci´on Millennial [5]), para los cuales la tecnolog´ıa no se considera un a˜nadido, sino que forma parte de su estilo de vida. Se trata de una generaci´on que ha crecido con el low cost, las reservas online, los v´ıdeos de YouTube y los comentarios en internet.
Por ello, la autoescuela S´uper Express concluye de sus ´ultimos estudios de mercado que el desarrollo de una plataforma de ense˜nanza del permiso de conducci´on para dispositivos m´oviles ayudar´ıa a satisfacer las necesidades de un alumno nativo digital, surgiendo un posible nicho de mercado en el sector.
1.2. Objetivos
El objetivo consiste en desarrollar una plataforma de ense˜nanza te´orica para el permiso de conducir y que ´esta abarque el m´aximo n´umero de usuarios para la autoescuela S´uper Express S.L.
Esta debe de reproducir los v´ıdeos almacenados en Vzaar y YouTube con la carac-´ ter´ıstica de ser interactivos, realizando preguntas durante la reproducci´on. Adem´as, debe de tener una sincronizaci´on local con el servidor que permita al usuario realizar tests sin conexi´on a Internet a la vez que est´en actualizados.
1.3. Estructura de la memoria
Los diferentes cap´ıtulos que conforman este proyecto son:
Cap´ıtulo 2 - Estado del Arte: Recoge todas aquellas tecnolog´ıas implicadas en el desarrollo de la aplicaci´on. El tipo de dispositivo m´ovil del usuario, su sistema operativo, el servidor de la empresa y las funciones b´asicas necesarias en Android, son los cuatro bloques en los que se ha dividido este cap´ıtulo.
Cap´ıtulo 3 - An´alisis de requerimientos y herramientas de desarrollo: La primera parte de esta secci´on puntualiza los requisitos necesarios que deber´a de cumplir la aplicaci´on, y la segunda parte engloba todas las herramientas que se han utilizado para el desarrollo del proyecto.
Cap´ıtulo 4 - Desarrollo: Muestra las soluciones del proyecto, cubriendo todos los puntos solicitados en el cap´ıtulo 3 y la implementaci´on directa sobre la aplicaci´on m´ovil.
Cap´ıtulo 5 -Propuestas futuras y conclusiones: Se exponen las diferentes l´ıneas de futuro abiertas al proyecto y finalmente, las conclusiones recogidas a lo largo del
2
Estado del arte
Para lograr el objetivo de desarrollar una plataforma de ense˜nanza para la te´orica del permiso de conducci´on, es necesario un estudio previo de las tecnolog´ıas involucradas en el mismo. El siguiente esquema (Figura2.1) representa de forma estructura la implicaci´on de ´estas en el proyecto. Est´a formado por cuatro bloques, los cuales siguen un orden que se inicia en un punto de vista amplio (como los dispositivos m´oviles) hasta uno m´as espec´ıfico (como la reproducci´on de v´ıdeo):
El primer bloque expone la tecnolog´ıa que utiliza el usuario final. En este caso se trata de un dispositivo m´ovil, donde cada uno de ellos contar´a con diferentes especificaciones.
El segundo bloque analiza los posibles sistemas operativos que puede tener el usuario final dependiendo del dispositivo.
El tercer bloque corresponde al entorno web, referente a la utilizaci´on de unservicio web para la comunicaci´on entre la aplicaci´on y el servidor.
El ´ultimo o cuarto bloque comenta las tecnolog´ıas m´as cr´ıticas del desarrollo en Android, ello para el cumplimiento de los requisitos que posteriormente ser´an pun- tualizados (reproducci´on de v´ıdeo y listas).
Bloque 1: Dispositivo m´ovil Estado del arte
Figura 2.1: Esquema de bloques que ponen de manifiesto las tecnolog´ıas que envuelven este proyecto.
2.1. Bloque 1: Dispositivo m´ ovil
Para conocer a qu´e se puede llamar “dispositivo m´ovil”, es importante saber las cuatro caracter´ısticas comunes que los definen [6]:
Movilidad.
Tama˜no reducido.
Capacidad de computaci´on y almacenamiento de datos.
Elementos de entrada y salida (por ejemplo la pantalla o el teclado).
Tipos de dispositivos
En la actualidad siempre se piensa en dispositivo m´ovil como en el actual tel´efono inteligente o tambi´en llamado smartphone. Pero existen otros tipos de dispositivos m´ovi- les que cubren los cuatro puntos mencionados anteriormente. Esta diversidad supone un problema para quien debe desarrollar aplicaciones sobre ellos, debido a que cada uno tiene sus propias caracter´ısticas que lo distinguen del resto. Entre los principales inconvenientes destacan las diferentes capacidades de memoria o interfaces de usuario. Por tanto, dise˜nar un producto a fin a todos ellos resulta una tarea realmente complicada.
A continuaci´on se van a enumerar y describir algunos [7] de los dispositivos que cumplen las caracter´ısticas mencionadas :
Dispositivo de computaci´on.
Bloque 1: Dispositivo m´ovil Estado del arte
Dispositivo de comunicaci´on.
Reproductor/Grabador multimedia.
Consola port´atil.
Tabletas.
Dispositivo de computaci´on
A este grupo, se incluyen aquellos dispositivos que destacan por su capacidad de c´alculo (potencia), a pesar de que los dispositivos de comunicaci´on tambi´en disponen de una capacidad de computaci´on elevada ´esta es m´as limitada. Generalmente cuando se habla de dispositivos de computaci´on hacemos referencia a “laptop” o port´atil. ´Estos ofrecen unas prestaciones muy similares a las de un ordenador de sobremesa y adem´as, suelen utilizar el mismo sistema operativo (Windows, Linux, MAC OSX) [8].
Dispositivo de comunicaci´on
Estos dispositivos suelen caracterizarse por un tama˜no reducido. Est´an dirigidos espe- cialmente a la comunicaci´on por voz, incluyendo comunicaci´on v´ıa SMS, MMS o Internet.
Algunos ejemplos que podemos encontrar son, los m´oviles tradicionales o los actuales smartphones.
Reproductor/Grabador multimedia
Se hace referencia a dispositivos dise˜nados para la reproducci´on o grabaci´on de conte- nidos, tanto de imagen como de sonido. ´Estos no suelen tener un gran tama˜no, y especial- mente si no requieren de una pantalla para la visualizaci´on del contenido.
En esta secci´on se abarcan una gran variedad de dispositivos, como por ejemplo DVD port´atil, reproductor MP3, c´amara de fotos digital o eBook.
Consola port´atil
Se trata de un dispositivo con una funci´on muy clara, proporcionar al usuario una plataforma de videojuego. A diferencia de una videoconsola de sobremesa, los controles, la pantalla, los altavoces y la alimentaci´on (bater´ıas) est´an todos integrados en la misma unidad y todo ello con un peque˜no tama˜no, para poder llevarla y jugar en cualquier lugar o momento.
Tabletas
Esta secci´on surgi´o hace relativamente pocos a˜nos, y una de las primeras marcas que la impuls´o fue Apple, con su dispositivo iPad. Las tabletas no tienen una funci´on muy clara como los otros dispositivos, pero pueden hacer frente a cualquiera de las secciones ante- riores. La diferencia con el resto de dispositivos es que ´estas no pueden realizar llamadas telef´onicas, adem´as pierden el concepto de “handheld” por su tama˜no.
Bloque 1: Dispositivo m´ovil Estado del arte
2.1.1. Mercado
Una vez analizados los diversos conceptos que acoge el termino “dispositivo m´ovil”, se presentar´an dos an´alisis de mercado: el primero de ellos sobre el equipamiento tecnol´ogico de las viviendas y en el segundo la comparaci´on del mercado de los smartphones y los m´oviles cl´asicos.
En el primer an´alisis (Figura:2.2) [9]destaca que el 96,7 % de los hogares dispone de tel´efono m´ovil, como dispositivo principal.
Figura 2.2: Equipamiento de las viviendas en algunos productos de tecnolog´ıas de infor- maci´on y comunicaci´on.
En el segundo an´alisis, realizado en 2015, [10]se observa como actualmente el smartp- hone se convierte en el aut´entico l´ıder, siendo ´esta la combinaci´on de un tel´efono m´ovil y un ordenador “handheld” en un ´unico dispositivo.
Bloque 2: Sistemas operativos para SmartPhones Estado del arte
Figura 2.3: Comparaci´on del mercado de los smartphones y los m´oviles cl´asicos.
Ahora que ya se conocen los distintos tipos de dispositivos m´oviles, mencionar que ´estos se ejecutan en diferentes sistemas operativos y que no todos ellos son igual de aceptados en el mercado, haciendo de la selecci´on del sistema operativo un punto clave. Por lo tanto, siguiendo el esquema 2.1, se analizar´an los sistemas operativos de las tablets y smartphones.
2.2. Bloque 2: Sistemas operativos para SmartPhones
La Real Academia Espa˜nola (R.A.E.) define [11]“sistema operativo” como:
“Programa o conjunto de programas que realizan funciones b´asicas y permiten el desarrollo de otros programas.”
Los sistemas operativos de los dispotivos m´oviles suelen estar orientados a [12] la conectividad inal´ambrica, los formatos multimedia y las diferentes modos de introducir informaci´on en ellos.
2.2.1. Mercado actual de los S.O. m´ovil m´as utilizados
A continuaci´on se va a analizar el mercado y la posici´on actual de los S.O., para luego ver sus caracter´ısticas, se˜nalando sus particularidades y dem´as aspectos.
En la siguiente gr´afica se observa que Android es el sistema operativo m´ovil dominante en el mercado, pasando a segundo puesto iOS, el sistema creado por Apple.
Bloque 2: Sistemas operativos para SmartPhones Estado del arte
Figura 2.4: Comparaci´on usuarios sistema operativo m´oviles y tablets en Espa˜na.
iOS: Es utilizado actualmente en Espa˜na por un 27’58 % (Figura:2.4) de los usuarios.
Su cuota de mercado de ventas en el mes de Febrero fue del 9’1 % [13], valor que no ha variado mucho estos ´ultimos meses.
Android: Es el sistema operativo para smartphones m´as utilizado a nivel mundial y en Espa˜na un 70’69 %(Figura: 2.4) de usuarios con smartphone lo utilizan. Adem´as, tiene una alta cuota de mercado con un porcentaje de ventas en m´oviles del 90 % [13]en el mes Febrero, dato que siempre ha mantenido una tendencia ascendente.
Figura 2.5: Cuota de mercado Febrero 2016 en Espa˜na.
Finalmente, est´an como sistemas operativos “conocidos” Windows Phone y BlackBerry con n´umero de usuario muy bajo y sin apenas ventas [13].
Bloque 2: Sistemas operativos para SmartPhones Estado del arte
2.2.2. Caracter´ısticas de los S.O. m´ovil m´as utilizados
Una vez analizado el mercado de los Sistemas Operativos, se mostrar´an las caracter´ısti- cas de aquellos que abarquen m´as usuarios, es decir, Android e iOS.
iOS
El sistema operativo iOSes el utilizado en los dispositivos de la compa˜n´ıa Apple. Se desarroll´o para el iPhone y despu´es se ha utilizado en otros dispositivos de Apple como iPod y iPad. La caracter´ıstica m´as destacada de este sistema es que no se permite utilizar en un hardware que no sea de Apple.
En al ap´endiceA se describe con m´as detalle el sistema operativo m´ovil de Apple.
Android
Fue iniciado por Android Inc., empresa que Google respald´o econ´omicamente y m´as tarde, en 2005, compr´o.Android [14]estaba inicialmente pensado para tel´efonos m´oviles, al igual que iOS, Symbian y BlackBerry OS. Lo que le distingui´o desde un primer momento fue el hecho de estar basado en Linux, cuyo modelo de desarrollo es de c´odigo abierto, proporcion´andole un n´ucleo de sistema operativo libre, gratuito y multiplataforma. ´Este proporciona todas las interfaces necesarias para desarrollar aplicaciones que accedan a las funciones del tel´efono (como el GPS, las llamadas, la agenda, etc.) de una forma muy sencilla, en un lenguaje de programaci´on muy conocido como es Java. Adem´as, el Sistema permite programar aplicaciones en una variaci´on de Java llamada Dalvik.
Android tiene la siguiente arquitectura (Figura: 2.6):
Figura 2.6: Arquitectura de Android
Bloque 2: Sistemas operativos para SmartPhones Estado del arte
Aplicaciones Las aplicaciones base incluyen un cliente de correo electr´onico, pro- grama de SMS, calendario, mapas, navegador, contactos y otros.
Armaz´on La mayor´ıa de los componentes de esta capa [15] son bibliotecas Java que acceden a los recursos mediante la m´aquina virtual Dalvik.
Los desarrolladores tienen acceso completo a los mismos APIs del framework usados por las aplicaciones base.
Librer´ıas Android incluye un conjunto de bibliotecas [16]de C/C++ usadas por varios componentes del sistema.
Runtime Android incluye un set de bibliotecas base que proporcionan la mayor parte de las funciones disponibles en las bibliotecas base del lenguaje Java. Cada aplicaci´on Android corre su propio proceso, con su propia instancia de la m´aquina virtual Dalvik.
Kernel El n´ucleo de Android [17]est´a basado en el kernel de Linux, en el que se han realizado algunas modificaciones para adaptarlo a las necesida- des de Android. ´Este sirve como capa de abstracci´on del hardware al que tienen que acceder las aplicaciones. De esta manera, si se necesita un elemento hardware, la aplicaci´on simplemente pedir´a el recurso en gen´erico, sin tener que conocer el modelo exacto de hardware.
2.2.3. Versiones Android
Android tiene un largo recorrido a lo que se refiere a las versiones o “API levels” [18]
a pesar de ser un sistema operativo comercializado en el 2008. Su recorrido comienza con la API level 1 llamada “Apple Pie” hasta la actualmente Marshmallow, API level: 23. Una de las curiosidades a comentar es, que todas las versiones de Android reciben del ingl´es el nombre de diferentes postres siguiendo, adem´as, un orden alfab´etico.
En la actualidad, cabe se˜nalar que no todos los dispositivos pueden beneficiarse siempre de las ´ultimas versiones ya que no s´olo depende de Google, sino tambi´en de los fabricantes del dispositivo, haciendo que convivan diferentes versiones en el mercado. En la siguiente tabla, puede observarse un n´umero relativo de dispositivos que ejecutan una determinada versi´on de la plataforma Android [19]:
Bloque 3: Entorno web Estado del arte
Figura 2.7: Versiones Android
Lollipop es la versi´on m´as utilizada actualmente con una cuota de mercado del 35,6 %, seguida de KitKat con 32,5 % y en tercera posici´on Jelly Bean, con una cuota de mercado del 20,1 % .
Finalizado el Bloque 2 sobre Sistemas Operativos parasmartphones, y siguiendo con el esquema de bloques que conforman este proyecto, a continuaci´on se analizar´a la tecnolog´ıa de un servicio WEB.
2.3. Bloque 3: Entorno web
Un servicio Web oWebService [20]es un servicio ofrecido por una aplicaci´on, el cual expone su l´ogica a clientes de cualquier plataforma mediante una interfaz accesible a trav´es de la red utilizando tecnolog´ıas (protocolos) est´andares de Internet.
2.3.1. WebService
La comunicaci´on entre servidor y dispositivo m´ovil requiere la generaci´on de un Web- Service. Para su desarrollo existen diferentes arquitecturas, siendo las m´as comunes SOAP (Simple Object Access Protocol) y REST (Representational State Transfer) [21].
Bloque espec´ıfico (4): Tecnolog´ıas en Android Estado del arte
Figura 2.8: SOAP vs REST
REST Transferencia de Estado Representacional (Representational State Transfer) oRESTes un estilo de arquitectura software para sistemas hipermedia distribuidos como la World Wide Web. REST afirma que la web ha disfrutado de escalabilidad como resultado de una serie de dise˜nos fundamentales clave:
Un protocolo cliente/servidor sin estado: cada mensaje HTTP contiene toda la informaci´on necesaria para comprender la pe- tici´on.
Un conjunto de operaciones bien definidas que se aplican a to- dos los recursos de informaci´on: HTTP en s´ı define un conjunto peque˜no de operaciones, las m´as importantes son POST, GET, PUT y DELETE.
Una sintaxis universal, donde cada recurso es direccionable ´uni- camente a trav´es de su URI.
SOAP Es un formato de mensaje XML utilizado en interacciones de servi- cios web. Los mensajes SOAP habitualmente se env´ıan sobre HTTP o JMS, pero se pueden utilizar otros protocolos. Puede ser utilizado para formar protocolos m´as complejos y completos seg´un las nece- sidades de las aplicaciones que lo implementan. Sus caracter´ısticas principales son:
Extensibilidad (seguridad y WS-routing son extensiones aplica- das en el desarrollo).
Neutralidad (SOAP puede ser utilizado sobre cualquier proto- colo de transporte como HTTP, SMTP, TCP o JMS).
Independencia (SOAP permite cualquier modelo de programa- ci´on).
Siguiendo con el esquema de bloques de la figura2.1, despu´es de mostrar la tecnolog´ıa de un WebService, en el siguiente bloque se detallar´an algunas de las tecnolog´ıas espec´ıficas en Android.
Bloque espec´ıfico (4): Tecnolog´ıas en Android Estado del arte
2.4. Bloque espec´ıfico (4): Tecnolog´ıas en Android
Hay multitud de tecnolog´ıas espec´ıficas en Android como la reproducci´on de audio, la c´amara de fotos, el posicionamiento GPS, la conectividad Bluetooth, etc., pero en este cuarto bloque se describir´an las dos m´as importantes para el desarrollo del proyecto:
Reproducci´on de v´ıdeo(2.4.1) Conexi´on a un servidor(2.4.2)
2.4.1. Reproducci´on de v´ıdeo
Para el desarrollo del proyecto ser´a necesario el estudio de dos plataformas de reproduc- ci´on de v´ıdeo1 (Figura:2.9), la primera y principal es Vzaar(un servicio de alojamiento de v´ıdeo online, el cual permite v´ıdeo en streaming, asi como incrustar, compartir y alojar v´ıdeos) y la otra esYouTube(sitio web en el cual los usuarios pueden subir y compartir v´ıdeos [22]). A continuaci´on se analizar´an por separado:
Figura 2.9: YouTube y Vzaar.
Vzaar
Una de las principales ventajas de Vzaar es que ofrece un sistema deseguridad [23]
basado en un token temporal, ´este permite que el enlace del v´ıdeo sea ´unico y no sea reutilizado (lo cual no quiere decir que no se puedan obtener los v´ıdeos por otras v´ıas alternativas, tan simples como grabar la pantalla, pero al menos no se trata de un enlace p´ublico). Se debe mencionar que actualmente Vzaar no dispone de una API para Android, por lo que ser´a necesario un estudio de las soluciones tecnol´ogicas para la reproducir los v´ıdeos de Vzaar.
Para acceder y reproducir el contenido de Vzaar se han analizado las dos siguientes opciones:
1El uso de dos plataformas, responde a la necesidad de la empresa demandante de contar con un contenido exclusivo para sus clientes, y otro p´ublico para atraer a nuevos
Bloque espec´ıfico (4): Tecnolog´ıas en Android Estado del arte
(i) VideoView (ii) WebView
Figura 2.10: VideoView vs WebView.
(i) VideoView [24]permite cargar contenido desde diversas fuentes (tales como URIs o content providers). ´Esta se encarga de obtener el v´ıdeo de forma que pueda ser utilizada en cualquier “Layout”, y tambi´en proporcionando varias opciones de visualizaci´on como tama˜no o personalizaci´on mediante MediaController (vista que contiene los controles de un reproductor multimedia comoplay,stop, etc).
Adem´as, permite reproducir contenido hospedado en un hosting haciendo Streaming (reproducir un fichero en paralelo mientras se descarga), por tanto, es capaz de aceptar una URI de descarga de v´ıdeo y reproducirlo durante la misma (Streaming). Esta URL no puede ser una cualquiera, debe ser una RTSP(Real Time Streaming Protocol) o una que nos descargue el v´ıdeo.
Una de las principales ventajas de VideoView es que ofrece controles comogetBuffer- Percentage(), getCurrentPosition(), getDuration() y muchas otras funciones que permi- tir´an cubrir una de las principales tecnolog´ıas de la aplicaci´on.
Bloque espec´ıfico (4): Tecnolog´ıas en Android Estado del arte
Pero lo que lo caracteriza es su gran estabilidad, ya que tiene funciones muy ´utiles para nuestro caso que est´an disponibles desde la API level 1, como por ejemplosetVideoURI(), la cual permite recibir una URL y reproducirla en streaming.
Una de sus desventajas es que no todos los formatos son aceptados. A pesar de que ac- tualmente soporta muchos m´as formatos que no las versiones m´as antiguas, se recomienda que los v´ıdeos est´en codificados en H.264 y sean de tipo .3gp o .mp4 [25], garantizando una compatibilidad m´ınima desde Android 3.0
La siguiente tabla proporcionada por Android Developers indica los formatos soporta- dos seg´un las versiones (Figura:2.11):
Figura 2.11: Formatos de v´ıdeo soportados en Android Android Developers a˜nade la siguiente anotaci´on [25]:
“Para el contenido de v´ıdeo que se transmite a trav´es de HTTP o RTSP, existen requisitos adicionales:
Para 3GPP y MPEG-4, el atom moov debe preceder a cualquier atom mDAT, sino que debe suceder al atom de FtyP.
Para 3GPP, MPEG-4, y WebM, los audios y v´ıdeos correspondientes para compensar al mismo tiempo pueden ser no m´as de 500 kb aparte. Para minimizar este / v´ıdeo de la deriva de audio, tenga en cuenta el intercalado de audio y v´ıdeo en tama˜nos de porci´on m´as peque˜no.”
Bloque espec´ıfico (4): Tecnolog´ıas en Android Estado del arte
Actualmente Vzaar ya codifica los v´ıdeos en este formato para ser aceptados desde diferentes medios, de modo que no deber´ıa causar muchos problemas. Respecto al codec, se debe mencionar que H.264/MPEG-4 AVC es una norma que define su compresi´on, al igual que H.265 o MPEG-H Parte2, llamado de forma com´un como High Efficiency Video Coding (HEVC). La diferencia entre H.265 y H.264 est´a en que el primero de ellos tiene una mejor compresi´on, imagen y ahorro de ancho de banda.
(ii) La otra posibilidad para reproducir un v´ıdeo de Vzaar, es embeber unscript HTML ofrecido por ´este a trav´es de la librer´ıa WebView. ´Esta resulta sencilla de implementar siempre y cuando no se requieran funcionalidades espec´ıficas de un reproductor de v´ıdeo.
Una vez analizada la primera plataforma (Vzaar) se estudiar´a que ofrece YouTube para reproducir los v´ıdeos almacenados en su plataforma.
YouTube
ActualmenteYouTube, a pesar de ser una plataforma destinada a hospedar v´ıdeos de usuarios en Internet, se ha convertido para muchos en una red social donde los usuarios pueden subir y compartir v´ıdeos.
Para reproducir contenido de su plataforma en Android,YouTubetiene desarrollada supropia API, la cual se encuentra en su versi´on n´umero 3 [26]. No hay que olvidar que la versi´on anterior (V2) ofrec´ıa algunos servicios que hasta la fecha no los ha introducido en en su nueva versi´on V3, como por ejemplo obtener un enlace de descarga de YouTube para descargar el contenido o realizar streaming, obligando as´ı a la utilizaci´on de su librer´ıa o a embeber los v´ıdeos en un WebView.
Actualmente, la API V3 ofrece diferentes formas de implementaci´on como YouTu- bePlayerSupportFragment, YouTubeStandalonePlayer, YouTubePlayerView o YouTube- Fragment. Este ´ultimo formato es el preferido para reproducir los v´ıdeos de YouTube [27], ya que no necesita extender una actividad proporcionada por la biblioteca, como cuando se usa YouTubePlayerView directamente.
2.4.2. Conexi´on con el servidor
Para la conexi´on a un servidor desde Android se utiliza el est´andar internacional HTTP (Hipertext Transfer Protocol). Este protocolo [28]consiste en reglas sencillas de transfe- rencia de recursos o archivos entre equipos interconectados a una red.
El equipo que hace la petici´on para enviar u obtener datos (dispositivo m´ovil) es llamado Cliente y el que contiene el recurso se le llama Servidor. La comunicaci´on se establece a trav´es de una petici´on de env´ıo, la cual contiene los datos del cliente como el sistema operativo que usa, el navegador web desde donde se hace la petici´on, la ubicaci´on del archivo solicitado (URL), etc.
Bloque espec´ıfico (4): Tecnolog´ıas en Android Estado del arte
Una petici´on puede tener m´ultiples objetivos dependiendo del m´etodo que se elija. Los tipos de peticiones m´as comunes son el Retorno y la Publicaci´on de datos. T´ecnicamente se les conoce como los m´etodosGET yPOST.
Dos ejemplos claros de utilizaci´on de este tipo de peticiones son (i) la b´usqueda de una p´agina web mediante una URL, donde el cliente realiza un GET donde el servidor retorna la informaci´on HTML necesaria para que el navegador la pueda interpretar, y (ii) el m´etodo POST, que es el env´ıo de informaci´on desde un formulario hacia la base de datos del servidor.
A continuaci´on se analizar´a el cliente Http de Volley, desarrollado por Google, el cual est´a totalmente enfocado en las peticiones, evitando la creaci´on de c´odigo repetitivo para manejar tareas as´ıncronas por cada petici´on [29]. Algunas de sus principales ventajas son:
M´ultiples conexiones de red simult´aneas.
Priorizaci´on en las peticiones.
Solicitud de cancelaci´on de la API. Se puede cancelar una ´unica solicitud, o se puede establecer bloques o ´ambitos de solicitudes para ser cancelados.
Implementaci´on de cach´e en disco y memoria.
Depuraci´on y herramientas de seguimiento.
Gesti´on autom´atica de trabajos en segundo plano.
Su principal desventaja es la descarga de datos pesados, ya que su operaci´on se basa en salvaguardas en cache, lo que har´ıa lento el proceso de datos voluminosos.
Una vez concluidos los cuatro bloques del Estado del Arte, los cuales analizan las tecnolog´ıas implicadas en el proyecto desde un punto de vista amplio (como los dispositi- vos m´oviles) y uno m´as espec´ıfico (como la reproducci´on de v´ıdeo), se iniciar´a el primer contacto con el proyecto, necesario para la posterior ejecuci´on del mismo. Dando paso al cap´ıtulo 3, con los requerimientos y herramientas necesarias para el de desarrollo.
3
Requerimientos y herramientas de desarrollo
Continuando con la estructura del proyecto, una vez presentadas las tecnolog´ıas impli- cadas, se inicia este tercer cap´ıtulo previo al desarrollo donde se puntualizan dos aspectos importantes para el mismo: los requisitos solicitados por la autoescuela S´uper Express S.L.
y las herramientas necesarias para ejecutarlos.
3.1. Requisitos
A continuaci´on, se recogen todos aquellos requisitos solicitados por la empresa deman- dante del producto. ´Estos se dividen en dos grupos atendiendo al mayor o menor grado de prioridad.
Los requisitos de mayor prioridad, son los de funcionalidad para el usuario dentro de la aplicaci´on. ´Estos son:
R1 Realizar tests sin conexi´on a Internet: el alumno debe poder realizar todo el curso, exceptuando la reproducci´on de los v´ıdeos, sin necesidad de conexi´on a Internet.
R2 Pantalla de identificaci´on de usuario: el acceso al curso, tanto a los v´ıdeos como a los tests, ser´a solo accesible para usuarios de S´uper Express.
R3 Contar con el apartado de Temas: debe estar presente la misma secci´on de temas que en la p´agina web.
R4 Contar con el apartado de Tests: debe tener la misma vista y contenido que el apartado de TESTS de la web.
R5 Contar con el apartado de Repaso: al igual que en la web, en este apartado el alumno responde a preguntas de test que haya fallado durante el curso.
Requerimientos
R6 Men´u lateral para poder acceder a las secciones de Temas, Tests o Repaso:
para cambiar de apartado se ha de desplegar un men´u lateral accesible desde la esquina superior izquierda.
R7 Seguir el mismo flujo de tests que en la web, con el sistema de doble ronda: la realizaci´on del cada test sigue un recorrido concreto con una reiteraci´on de las preguntas falladas.
R8 V´ıdeos interactivos: durante la visualizaci´on de los v´ıdeos habr´a momentos en los cuales ´este se pause para realizar un peque˜no test al alumno sobre el contenido que se termina de explicar.
R9 Pantalla principal como Temas: cuando el usuario inicie la aplicaci´on normal- mente, la secci´on de Temas debe ser la que se muestre.
R10 Visualizar los v´ıdeos desde los correspondientes hostings: la empresa de- mandante tiene los v´ıdeos almacenados en dos hostings diferentes que se diferencian por ser de acceso privado y p´ublico.
R11 Soportar un gran n´umero de versiones del S.O.: Android tiene muchas ver- siones activas simult´aneamente, lo que puede ocasionar que para algunas versiones no est´en disponibles funcionalidades que en otras si est´an.
R12 Ser lo m´as fiel posible a la web: el alumno no tiene que ver diferencias funcionales respecto de la web para la realizaci´on del curso.
R13 Mostrar al usuario la comprobaci´on de que el curso se encuentra actuali- zado: siempre que el alumno tenga Internet, a pesar de que sus tests se encuentren actualizados, debe mostrarse claramente durante al inicio que se han sincronizado los ´ultimos tests.
R14 Actualizar los tests del servidor: en la base de datos del servidor se encuentran almacenados los test maestros de la empresa, y los cambios que se realicen en ´este deber´an ser reflejados en la aplicaci´on m´ovil.
R15 Fecha de caducidad del curso: El alumno tiene que estar informado de los d´ıas que le quedan de curso online.
R16 Sistema de luz verde: Realizar un seguimiento del progreso del usuario para indicarle cuando est´a listo para ir a examen.
Y en el siguiente grupo, se enumeran aquellos requisitos que no son tan cruciales para el funcionamiento de la aplicaci´on de cara al usuario. ´Estos son:
R17 Una presentaci´on de la aplicaci´on en al inicio: pantallas informativas de la aplicaci´on y/o empresa para el usuario en su primer inicio.
R18 Mantener la seguridad de los v´ıdeos con el hosting de Vzaar: actualmente la web utiliza Vzaar debido a su seguridad, y ´esta debe seguir en la aplicaci´on desde el mismo hosting.
R19 Tiene que ser una aplicaci´on fluida: el usuario no tiene que tener tiempos de espera largos durante el uso de la aplicaci´on.
Herramientas necesarias para el desarrollo
R20 Mostrar las miniaturas de los v´ıdeos e iconos “smyle”: la ayuda visual me- diante estas im´agenes aporta un entorno id´entico a la web.
3.2. Herramientas necesarias para el desarrollo
Este subapartado describe todas aquellas herramientas utilizadas en el desarrollo del proyecto.
3.2.1. Eclipse
Este´ [30]es un IDE (Entorno de Desarrollo Integrado) de c´odigo abierto y multiplata- forma, y se utilizar´a para la implementaci´on del servici´o web.
Eclipse [31]dispone de un Editor de texto con un analizador sintactico. La compila- ci´on es en tiempo real. Tiene pruebas unitarias con JUnit, control de versiones con CVS, integraci´on con Ant, asistentes (wizards) para creaci´on de proyectos, clases, tests, etc., y refactorizaci´on. Asimismo, a trav´es de ”plugins”libremente disponibles es posible a˜nadir control de versiones.
3.2.2. XAMPP
XAMPP es un servidor independiente [32] de software libre que pertenece al gene- ro WAMP (Windows, Apache, MySQL y generalmente PHP) teniendo como significado XAMPP, X para cualquier sistema operativo, A para Apache, M para MySQL, P para PHP y P para Perl. ´Este se utilizar´a para el testeo local del WebService, ofreciendo un servidor para PHP y MySQL.
3.2.3. Android Studio
En Junio de 2013 Google sac´o a la luz su propio IDE llamado Android Studio [33].
Este proporciona las herramientas m´´ as r´apidas para la creaci´on de aplicaciones en cada tipo de dispositivo Android.
Una de sus caracter´ısticas m´as importantes es el editor de c´odigo inteligente. ´Este ayuda a escribir mejor c´odigo, trabajar m´as r´apido y ser m´as productivo, ofreciendo opciones finalizaci´on avanzada de escritura, refactorizaci´on y el an´alisis de c´odigo, tambi´en es capaz de proporcionar sugerencias en una lista desplegable.
3.2.4. Genymotion
Genymotion [34]es un emulador de Android que aprovecha la arquitectura x86 para ejecutar de forma fluida y r´apida distintos dispositivos Android. Cuando se programa en Android, se est´a desarrollando una aplicaci´on que se ejecutar´a sobre dicho sistema operativo, por ello, es necesario simular literalmente dicho sistema en el ordenador si se quiere testear la aplicaci´on, sino tambi´en se puede probar sobre un smartphone.
Herramientas necesarias para el desarrollo
3.2.5. Advanced Rest Client
Para el testeo de la API REST se utilizar´a una extensi´on de Goolge Chrome llamada
“Advanced Rest Client”, la cual ofrece realizar peticiones HTTP de tipo GET, POST, PUT o DELETE, manejando diferentes formatos, entre los cuales est´a JSON.
Una vez conocidas las tecnolog´ıas implicadas, los requisitos solicitados por la empresa y las herramientas necesarias para la elaboraci´on del proyecto, se hace posible la ejecuci´on del mismo. A continuaci´on, se dar´a paso al cap´ıtulo de desarrollo compuesto por las secciones de resoluci´on de problemas, implementaci´on y pruebas de campo.
4
Desarrollo
Ahora que se conocen los requisitos solicitados por la empresa y las herramientas ne- cesarias, se inicia este cuarto cap´ıtulo en el que se expone el desarrollo de la aplicaci´on Android, con una versi´on m´ınima “API Level 17”, abarcando un porcentaje alto de dis- positivos Android. A continuaci´on, se muestra el esquema que estructura dicho desarrollo (Figura:4.1) siguiendo una secuencia temporal y que ser´a reutilizado a lo largo del cap´ıtulo como gu´ıa del contenido:
Figura 4.1: Esquema de la estructura de desarrollo.
El esquema est´a estructurado en tres secciones: laresoluci´on de problemas, laim- plementaci´ony las pruebas de campo. A continuaci´on se desarrollar´an en sus respectivos subapartados marcando losrequisitos de cada contenido mediante una Rroja seguida de un n´umeron.
Resoluci´on de problemas Desarrollo
4.1. Resoluci´ on de problemas
Dentro de esta primera secci´on se resuelven los problemas tecnol´ogicos y funcionales para el desarrollo del proyecto. ´Este sigue la secuencia temporal de desarrollo, que a su vez estuvo marcada por la dependencia, como por ejemplo el hecho de que no puede realizarse la sincronizaci´on sin la conexi´on al servidor.
4.1.1. Estudio de funcionamiento de la plataforma web
Previamente a laimplementaci´on se ha realizado un an´alisis de la web (R7), donde se han anotado los flujos del usuario, las pantallas que ve, los dise˜nos (R12) y las estructuras de las vistas.
Los apartados solicitados por la empresa son analizados (Temas - R3, Tests -R4, Repaso -R5) tanto a nivel de vista (iconos o listas) como de flujo (¿qu´e sucede al finalizar un test? o ¿qu´e sucede al fallar una pregunta?). En el ap´endiceBse desarrollan los an´alisis del esquema4.2.
Figura 4.2: Estructura solicitada del men´u de la Web
Una vez analizados estos apartados, se realiz´o un wireframing para establecer la es- tructura b´asica de la aplicaci´on con unos m´ınimos de dise˜no acorde al contenido y reque- rimientos.
Resoluci´on de problemas Desarrollo
4.1.2. WireFraming
Despu´es de conocer la web (R12) se ha realizado unwireframing (esquema de pantallas como gu´ıa visual que representa el esqueleto o estructura, esquematizando el dise˜no y ordenamiento del contenido, incluyendo elementos de la interfaz y sistemas de navegaci´on).
Este est´´ a dividido en dos partes: la inicializaci´on y el contenido principal. En la figura 4.3se observa como la inicializaci´on contiene una pantalla depresentaci´on (R17), una delogin (R2), una deactualizaci´on(R13) y finalmente el inicio del contenido.
Figura 4.3: Esquema simplificado de las pantallas (wireframing).
(i) Lo primero que se muestra es unapresentaci´on, que aparecer´a ´unicamente la pri- mera vez que el usuario inicie la App. En ´esta se expone el producto o empresa, y suelen tener un m´aximo de 3 pantallas. Adem´as, siempre estar´a presente el bot´on de saltar (skip), por si el usuario desea salir de la presentaci´on (Figura:C.1).
Resoluci´on de problemas Desarrollo
(ii) Despu´es de la presentaci´on aparece la pantalla de login (Figura: C.2) donde el usuario introduce su correo y contrase˜na para acceder al contenido del curso.
(iii) La siguiente pantalla corresponde a una pantalla de actualizaci´on, de forma que el usuario tendr´a la seguridad de tener el contenido m´as reciente siempre que tenga conexi´on a Internet. Su dise˜no es una barra de progreso junto a su porcentaje (Figura:
4.4).
Figura 4.4: Pantalla de actualizaci´on (wireframing).
Finalizada la inicializaci´on de la aplicaci´on, se presenta un wireframing de las pantallas principales adaptando de la mejor forma el contenido de la web (requisitoR7). En la figura 4.5se observa una pantalla con unmen´u(R6) desde el cual se accede a los tres apartados:
temas, tests y repasar. A continuaci´on se describen cada uno de ellos:
Temas Esta est´´ a formada por una lista de ´ıtems que corresponden a los diferentes temas. Cada uno dispone de tres lugares de acci´on: uno para acceder a un dialog de los v´ıdeos sin cambiar de vista (i), otro para acceder al test del tema (ii) y el resto del ´ıtem para mostrar la vista de un tema (iii).
Tests Esta est´´ a formada por una lista de m´as de 55 ´ıtems, y cada uno muestra informaci´on de estado (pendiente, aprobado o suspendido), el n´umero de test y el n´umero de veces realizado. En esta ocasi´on s´olo est´a la pulsaci´on sobre el ´ıtem para iniciar un test.
Repasar Esta no tiene detalle del contenido, ya que se pulsa y se inicia un test´ que recoge las preguntas falladas.
Hay que a˜nadir que la pantalla de un test representa el dise˜no que es com´un a los tests generales (de examen), de tema, de v´ıdeo o de repasar.
Resoluci´on de problemas Desarrollo
Resoluci´on de problemas Desarrollo
Una vez desarrollado elwireframing de la aplicaci´on, le siguen los aspectos m´as t´ecnicos del desarrollo.
4.1.3. Servicio web
El desarrollo del servicio web a sido creado bajo la arquitectura REST, ya que este ofrece simplicidad y rendimiento con la utilizaci´on del est´andar HTTP.
Actualmente existen dos direcciones aceptadas por el servicio (E.2): una para el login del usuario y otra para la actualizaci´on de los datos, y ´estas reciben un JSON con la informaci´on necesaria para poder procesar la petici´on y devolver al cliente el resultado de la misma. La respuesta es proporcionada en un formato JSON junto a un valor de estado, de la familia 2xx, indicando al cliente que la petici´on ha sido exitosa.
En el siguiente fragmento de c´odigo del ap´endice (E.3) se observa la utilizaci´on de JSON en la respuesta del servidor.
Para la verificaci´on del funcionamiento del servicio web, se ha utilizado la herramienta Advanced REST Client, que permite realizar pruebas de peticiones al servidor evitando el tedioso testeo que supondr´ıa hacerlo en un emulador Android.
4.1.4. Base de datos
En este apartado se analizar´a la base de datos del servidor web y del cliente Android, exponiendo la implementaci´on de este ´ultimo con su utilizaci´on y gesti´on de la misma.
BD servidor
De todas las tablas que gestionan el servidor web de la empresa, hay un n´umero determinado que almacenan la informaci´on clave, constituyen los datos maestros necesarios para que el alumno pueda desarrollar el curso desde su dispositivo. Estas son el cat´alogo de tests y de temas, las preguntas y sus respuestas, etc. Todas ellas son independientes de la informaci´on del usuario. A este conjunto lo llamaremos tablasmaestras, y se garantiza su replicaci´on en el dispositivo m´ovil mediante sincronizaci´on.
Resoluci´on de problemas Desarrollo
Por otro lado, existen las tablasno maestras, las cuales dependen del usuario, alma- cenando el progreso de ´este, como respuestas, rondas y dem´as datos que no son maestros que no ser´an sincronizadas.
Una vez se analizada la base de datos de la web, se describe la persistencia de datos en Android.
BD Android
En Android existen dos posibles caminos para la persistencia de datos, mediante la utilizaci´on de la base de datos SQLiteo medianteSharedPreferences.
Figura 4.6: Esquema RESTful - HTTP.
· SharedPreferences
Se trata de un fichero .XML que permite un acceso r´apido a datos que se desean persistir. Su uso est´a indicado para colecciones de datos peque˜nas con una clave asociada a un valor. Por tanto, se le ha dado un uso de no m´as de 10 valores por almacenar, siendo
´estos muy concretos.
Para su uso se ha creado un fichero de preferencias en el cual se almacenan datos del usuario como su Token, su contrase˜na, su fecha de alta y de caducidad, sus datos personales, etc.
Para acceder a ellos se definen las constantes claves utilizadas en el fichero .XML (E.4).
Tambi´en se ha creado una clase que lo gestiona de forma amigable para su utiliza- ci´on llamada UtilesPreferencias. ´Esta contiene funciones est´aticas que permiten obtener o modificar las preferencias seg´un el tipo de valor, que pueden serStrings oBooleans (E.1).
Resoluci´on de problemas Desarrollo
· SQLite
A diferencia de SharedPreferences, SQLite est´a destinado al almacenamiento de gran- des cantidades de datos, siendo ´estos los de tests, preguntas, respuestas y dem´as infor- maci´on necesaria. ´Este requiere de SQLiteOpenHelper, extensi´on que gestiona la versi´on de la base de datos y sus tablas. Por contra, utilizar SQLite requiere un esfuerzo extra, ejecutandogetWritableDatabase() para abrir conexi´on y close() para finalizar conexi´on.
Una vez comprendida su implementaci´on, se ha estructurado la gestion de SQLite de la siguiente forma (Figura: 4.7): (i) una clase para el control de tablas (en nuestro caso llamada DbHelper, la cual extiende de SQLiteOpenHelper), (ii) una clase abstract (llamada DataBaseManager, que gestiona la conexi´on e instancias generales b´asicas de SQLite) y finalmente (iii) una clase para cada tabla que define su estructura. En el ap´endice (E.5) se muestran las lineas m´as relevantes de DataBaseManager y una tabla como ejemplo de la implementaci´on (E.6).
Figura 4.7: Esquema de gesti´on de la base de datos SQLite.
Las clases que contienen la informaci´on de las tablas tienen definidas las variables String como est´aticas para poder acceder desde la capa de modelo, y la variable CREA- TE TABLE contiene el script de creaci´on de la tabla, el cual es llamado desde DbHelper en elOnCreate().
Hay que se˜nalar que, el script del par´ametro String CREATE TABLE de las tablas maestras, no tienenautoincrementen la definici´on de la “ id” (primary-key), ya que ´esta es rellenada desde los datos del servidor web, permitiendo la reutilizaci´on de las IDs asignadas en la base de datos del servidor.
Resoluci´on de problemas Desarrollo
Capa modelo de datos
Una vez finalizada la gesti´on de la base de datos se expondr´a la implementaci´on del modelo de datos. ´Este es el encargado de comunicar la BD mediante funciones de obtenci´on de datos, inserci´on, actualizaci´on o eliminaci´on. A ´esta le acompa˜nan las clases modelo que definen conjuntos de datos manejables para su utilizaci´on como por ejemplo las clases TestGeneral o TemaCursoAlumno, que contienen las definiciones de las propiedades y comportamientos de los mismos.
Figura 4.8: Esquema de una funci´on del modelo de datos.
Como se observa en la figura 4.8 y en el fragmento de c´odigo del ap´endice (E.7), un ejemplo de la capa modelo es la funci´on llamada “obtener preguntas()”, la cual devuelve una lista de la clase modelo “Pregunta”. Por tanto, gracias a la capa modelo, se trabaja con definiciones de instancias modelo y no con Cursores, ya que estos dificultar´ıan la legibilidad del c´odigo.
Una vez se conoce como gestionar los datos, se resuelven los puntos de conexi´on al servidor y posteriormente la actualizaci´on del cliente.
4.1.5. Conexi´on con el servidor
Para la conexi´on al servidor (requisito R14) desde Android (se han a˜nadido los per- misos de conexi´on en AndroidManifest.xml4.1) se ha seguido el protocolo HTTP (2.4.2) utilizando la librer´ıa de Volley.
Resoluci´on de problemas Desarrollo
1 <u s e s−p e r m i s s i o n a n d r o i d : name=” a n d r o i d . p e r m i s s i o n . INTERNET” />
2 <u s e s−p e r m i s s i o n a n d r o i d : name=” a n d r o i d . p e r m i s s i o n .ACCESS NETWORK STATE” />
Listing 4.1: Permisos de conexi´on en Manifest.
Esta se ha implementado mediante la creaci´´ on de tres clases:
1. VolleySingleton: clase con el patr´on singleton, tal y como recomienda Google, restringiendo la instanciaci´on de nuevos elementos. ´Este debe contener como atributo la cola de peticiones y el contexto de la aplicaci´on (no el contexto de la actividad, ya que es necesario establecer independencia de la interfaz por cambios de la misma o rotaciones de pantalla).
2. PeticionesWEB: contiene los m´etodos est´aticos GET y POST accesibles desde cualquier parte del proyecto. En el ap´endiceE.9 se muestra un fragmento de c´odigo de la funci´on post.
3. VolleyCallback: una interfaz (4.2), que se utiliza para comunicar la respuesta del callBack de las funciones GET y POST de la clase peticionesWEB.
1 p u b l i c i n t e r f a c e V o l l e y C a l l b a c k
2 {
3 v o i d o n S u c c e s s ( JSONObject r e s u l t ) ;
4 v o i d o n E r r o r ( V o l l e y E r r o r e r r o r ) ;
5 }
Listing 4.2: Interfaz de VolleyCallback.
Por tanto, para la conexi´on al servidor se han llamado a las funciones est´aticas de la clase PeticionesWEB. En el punto E.10del ap´endice, se muestra un fragmento de c´odigo en el cual se realiza una petici´on POST. Una vez resueltos los puntos de base de datos y conexi´on al servidor se desarrollar´a la sincronizaci´on.
4.1.6. Sincronizaci´on
En este apartado se expone la estrategia de sincronizaci´on y la generaci´on de un Sync Adapter, cumpli´endose as´ı el requisito R14.
La sincronizaci´on de datos es el proceso de copiar autom´aticamente un conjunto de datos entre uno o m´as dispositivos, de tal forma que la informaci´on se encuentre al d´ıa.
En este proyecto se desea que los datos que existen en un servidor sean depositados en el dispositivo m´ovil del usuario. A esto se le llama sincronizaci´on local.
Resoluci´on de problemas Desarrollo
Para la realizaci´on de la sincronizaci´on local, teniendo conocimiento de que los datos maestros del servidor se actualizan en periodos de no menos de una semana y que ´estos no son cr´ıticos en el curso del alumno, se han escogido dos estrategias: (i)sincronizaci´on forzada al iniciarla aplicaci´on y (ii)sincronizaci´on diariamediante un servicio (Sync Service). A continuaci´on se detallar´an cada una de ellas.
· Sincronizaci´on forzada al iniciar
La sincronizaci´on al iniciar la aplicaci´on o sincronizaci´on manual de forma forzada, asegura que durante esa sesi´on de estudio el alumno tendr´a los test actualizados siempre y cuando disponga de Internet. Asimismo hay que se˜nalar que en el primer inicio de la aplicaci´on, seguramente el alumno ha tenido Internet y se habr´an descargado los
´
ultimos datos del servidor. Durante este proceso el usuario tiene una pantalla dedicada a la actualizaci´on mediante la visualizaci´on de unprogressBar.
Por tanto, ´esta aporta ventajas como ahorro de bater´ıa, comprobaci´on en tiempo real y tranquilidad al alumno.
· Sincronizaci´on diaria
La sincronizaci´on diaria se realiza desde un servicio (Sync Service) y para conocer las ventajas que ´este aporta, a continuaci´on se listan algunas de las caracter´ısticas m´as importantes:
Inicio de la sincronizaci´on con la aplicaci´on cerrada.
Posibilidad de sincronizaci´on peri´odica.
Se ejecuta de forma as´ıncrona en periodos de tiempo sin inicio o fin determinados.
Las peticiones Http son manejadas por el mismo SyncAdapter, evitando comprome- ter el hilo principal que procesa los eventos de la interfaz.
Si el dispositivo no tiene conexi´on a Internet se queda como “pendiente de actualizar”
para cuando disponga de conexi´on.
Por tanto, esta forma peri´odica/autom´atica de sincronizaci´on mediante la creaci´on de un servicio (Sync Service), aporta comodidad y ahorro de tiempo al usuario, a diferencia de lasincronizaci´on al iniciar la aplicaci´on, donde el alumno tiene una pantalla dedicada en cada inicio. Otra de las ventajas que se a˜nade es su ejecuci´on as´ıncrona evitando un posible tiempo de espera al alumno, y en caso de iniciar la aplicacion sin conexion a internet, seguramente disponga de los datos acutalizados si ha tenido conexi´on a Internet en alg´un momento (requisitos R1yR14).
Pero una de sus mayores desventajas es su compleja implementaci´on, ya que para la utilizaci´on de un Sync Adapter se necesitan diversas piezas que deben tener el proyecto (Figura: 4.9). ´Estas se agrupan en la necesidad de existir una autoenticaci´on y luego un Sync Adapter:
Resoluci´on de problemas Desarrollo
Figura 4.9: Piezas Sync Adapter.
En al ap´endice D se comenta la figura anterior para la implementaci´on del Sync Service realizado en el proyecto.
Siguiendo el esquema de la resoluci´on de problemas, se desarrollaran los tres ´ultimos apartados independientes a la sincronizaci´on.
4.1.7. Reproducci´on de V´ıdeo
En este apartado se resuelve la reproducci´on de v´ıdeos de YouTube y de Vzaar (R10).
Para la reproducci´on de los v´ıdeos de Vzaar se plante´o en el punto 2.4.1 la opci´on de WebView o VideoView, y para encontrar la mejor resoluci´on del problema se han testeado emp´ıricamente en un dispositivo m´ovil las dos posibles implementaciones. El resultado de dicha comparaci´on ha sido la siguiente (1 muy mala, 2 mala, 3 buena, 4 muy buena):
WebView VideoView
Fluidez 2 4
Personalizaci´on de controles 2 4
Fluidez 2 4
Velocidad de carga 3 3
Aspecto visual 2 4
Cuadro 4.1: WebView vs VideoView
Resoluci´on de problemas Desarrollo
Los resultados de la tabla4.1muestran que la mejor forma de reproducir los v´ıdeos de Vzaar es a trav´es VideoView. Una vez se decidi´o la librer´ıa, se trabaj´o durante semanas para su mejor implementaci´on. Finalmente, se encontr´o en GitHub una librer´ıa llamada JieCaoVideoPlayer [35] la cual proporciona muchas funciones ´utiles para el desarrollo como la inicializaci´on del v´ıdeo, los controles multimedia o el estado del v´ıdeo.
Para los v´ıdeos almacenados en YouTube se ha utilizado su propia API V3 utilizan- do YouTubePlayerFragment (2.4.1). Para su utilizaci´on se extiende de YouTubePlayer- Fragment implementando YouTubePlayer.OnInitializedListener para posteriormente so- breescribir el m´etodoonInitializationSuccess con las funciones de youTubePlayer.play() y youTubePlayer.loadVideo(id en sistema almacenamiento).
4.1.8. Carga de im´agenes
Para la carga de im´agenes existen diferentes librer´ıas que aportan tecnolog´ıas adem´as de ayudar a evitar c´odigos complejos, donde se ofrece funciones para la descarga de im´age- nes, el almacenamiento en cach´e y la reutilizaci´on de las im´agenes.
Para dicho fin, se ha utilizado Glide [36], ya que se caracteriza por la fluidez y el buen funcionamiento en carga de im´agenes sobre listas (scroll), siendo ´esta una vista muy caracterizada en este proyecto. Con Glide, el usuario al desplazarse hacia arriba y abajo en una lista, ver´a que las im´agenes se muestran r´apidamente y con fluidez. Al cargar una imagen, ´este utiliza tres fuentes: la memoria, disco y red (ordenados del m´as r´apido al m´as lento). Finalmente para la utilizaci´on de ´esta, simplemente se llama a una funci´on (4.3) que esconde toda esa complejidad creaci´on de las memorias cach´e inteligente.
1 G l i d e . w i t h (t h i s) . l o a d ( u r l ) . i n t o ( imageView ) ;
Listing 4.3: Uso de Glide
Por tanto, para todas las cargas de im´agenes en la aplicaci´on, se ha utilizado Glide.
4.1.9. Listas en Android
Resoluci´on de problemas Desarrollo
Para la creaci´on de listas se ha realizado un estudio de las dos librer´ıas que destacan en Android en ese ´ambito:
ListView [37].
RecyclerView [38].
ListView
Se trata de un View Group que muestra una lista de contenidos desplazable (scroll).
Esta se inserta de forma autom´´ atica mediante el uso de adaptadores encargados de obtener el contenido de cada elemento de la lista para posteriormente mostrarlo.
Esta librer´ıa aporta los siguientespuntos positivos:
OnItemClickListeners: una de las ventajas que tiene ListView es que dispone AdapterView, el cual permite escuchar los clics del usuario de una forma f´acil para posteriormente controlarlos. Sin embargo, en RecyclerView no se ha anidado dicha clase complicando la escucha de los clics del usuario.
CursorAdapters: esta clase como su nombre indica est´a destinada a la adaptaci´on de un cursor directamente sobre una lista, simplificando muchas veces la creaci´on de listas que cogen informaci´on directamente de la base de datos. Actualmente, RecyclerView no implementa CursorAdapter, a pesar de que se pueden encontrar algunas librer´ıas en GitHub de usuarios que solucionan el problema.
Dividers: conListView la creaci´on de una l´ınea divisora de elementos es muy simple, ya que ´unicamente supone a˜nadir una l´ınea de XML, la cual proporciona una fina separaci´on para cada elemento. Sin embargo, con en RecyclerView se debe dibujar esta peque˜na linea y a˜nadirla como un elemento m´as.
Los beneficios de utilizar ListView no se concentran unicamente en estos 3 puntos descritos anteriormente, pero son los m´as destacables.
A pesar de estos puntos positivos,AdapterView en temas de dise˜no y implementaci´on de efectos, interacciones, transiciones y dem´as efectos decorativos no resulta muy esca- lable, quedando algo obsoleto. Aunque en muchas ocasiones se trate de una muy buena implementaci´on dependiendo de las necesidades. Finalmente otro punto a faltar enAdap- terView es la utilizaci´on deViewHolder, una clase que muestra un desplazamiento de la lista (scroll) mucho m´as suave y agradable.
Despu´es de reflejar algunos pros y contras deListView, se analizar´an las caracter´ısticas que presentaRecyclerView.
RecyclerView
Esta es una clase que hereda de´ ViewGroup, y al igual que ListView y GridView, permite mostrar grandes colecciones o conjuntos de datos, pero con la ´unica diferencia de que s´olo se dedica a reciclar vistas, delegando la tarea de renderizado a otros componentes, que ser´an los que determinen la forma de acceder a los datos y c´omo mostrarlos.
Resoluci´on de problemas Desarrollo
Lasventajas m´as destacables que ofrece son:
Control total de los clics: gracias a ViewHolder ahora el desarrollador es el encargado de crear un listener para cada elemento de una colecci´on, proporcionando una flexibilidad y escalabilidad mucho m´as amplia que ListView.
LayoutManagers: a diferencia de ListView, donde el dise˜no de la distribuci´on ya estaba pre-establecido a un desplazamiento vertical, con RecyclerView se controla medianteLayoutManager y permite establecer un desplazamiento vertical, horizontal o rejillas.
Decoraci´on y animaci´on de elementos: se encuentra con ItemAnimator, una clase abstracta encargada de reflejar los cambios que se hacen a un adapter, permi- tiendo definir las animaciones que ser´an visualizadas en RecyclerView al crear un ItemAnimator.
RecyclerView es una vista con mucho potencial que ha sido dise˜nada con el prop´osito de mostrar vistas de una forma sencilla y eficiente. Por ello, se ha utilizado ´este durante la implementaci´on en la siguiente secci´on de todas las lsitas.
Una vez se han resuelto los diferentes problemas y requisitos de la aplicaci´on, a conti- nuaci´on, se implementan dichas soluciones siguiendo un orden de flujo de ejecuci´on, como si de un usuario se tratara.
Implementaci´on Desarrollo
4.2. Implementaci´ on
Finalizada la resoluci´on de las tecnolog´ıas necesarias para el proyecto como la base de datos, la conexi´on al servidor, la sincronizaci´on o la reproducci´on de v´ıdeo, se crear´an las diferentesactivities yfragments que se ejecutan en la aplicaci´on.
La descripci´on de ´estas sigue la secuencia de flujo de la aplicaci´on: (1) una presentaci´on, (2) un Login, (3) una actualizaci´on, (4) el apartado de lista de temas y luego en su interior la explicaci´on de un tema, (5) el apartado de la lista de tests y luego en su interior la explicaci´on de un test y (6) el apartado de repaso. Adem´as, se˜nalar que su dise˜no est´a basado en loswireframings propuestos en el punto 4.1.2.
4.2.1. Activity de Presentaci´on
Una presentaci´on al iniciar una aplicaci´on se ha convertido en un valor a˜nadido impor- tante. ´Estas se han popularizado a trav´es de las aplicaciones de Google, las cuales siempre cuentan con una. Cumpliendo el requisitoR17 ser´a la primera Activity que se ejecutar´a cuando el usuario inicie la aplicaci´on por primera vez.
Su dise˜no consiste en una serie de Fragments que se visualizan mediante ViewPager dentro de una Activity. Para su implementaci´on se ha utilizado una librer´ıa de GitHub especializada en introducciones para aplicaciones [39]. ´Esta ha simplificado mucho el te- dioso proceso de creaci´on de unViewPager, ya que tiene como ´unica funci´on inflar vistas informativas permitiendo realizarslide entre ellas. Adem´as incluye otras herramientas de control como efectos o un bot´on para salir.
No hay que olvidar, que este tipo de presentaciones suelen incluir alrededor de dos o tres vistas posicionadas mediante un peque˜nos puntos (“dots”) (Figura:4.10):
Figura 4.10: Puntos de posici´on en un Pager.
Implementaci´on Desarrollo
4.2.2. Login
Al igual que en la web, los alumnos deben introducir un email y contrase˜na para el acceso al contenido de la aplicaci´on. Este punto, se sit´ua sobre la primera Activity que aparece al iniciar la aplicaci´on una vez vista laintroducci´on inicial, siempre y cuando no exista unlogin activo. ´Esta presenta el siguiente flujo (Figura : 4.11):
Figura 4.11: Diagrama de flujo de Login.
Implementaci´on Desarrollo
En la imagen 4.11 se inicia el proceso con la comprobaci´on de la existencia de los datos necesarios en SharedPreferences y su caducidad del curso. Los datos co- rresponden a un token, un email, una contrase˜na, un nombre, una fecha de nacimiento y una fecha de caducidad vigente, de no ser as´ı, se iniciar´ıa la vista deLogin. ´Esta tiene dos campos de entrada: un email y un contrase˜na, y una vez introducidos, ´estos pasan por un proceso previo de validaci´on de formato antes de realizar la petici´on al servidor (ejemplo de una de las funciones de verificaci´on,E.11).
Aceptados los InputText, se realiza la petici´on al servidor y ´este realiza todas las comprobaciones y consultas necesarias desarrolladas en el servicio web. Al finalizar, ´este devuelve la informaci´on que se precisa en la aplicaci´on, acompa˜nada de un Token para las futuras peticiones del usuario facilitando el proceso de autenticaci´on, y terminado todo el procedimiento se continuar´a con la ejecuci´on de la aplicaci´on. Por la otra rama, si est´an los datos necesarios y la cuenta sigue vigente, se continuar´ıa con la ejecuci´on realizando lasincronizaci´on local.
Finalmente, respecto al dise˜no (Layout) delLogin, se han utilizado etiquetas flotantes que siguen el nuevo esquema de dise˜no de Google [40]. ´Este hace que cuando el usuario establece el foco en el campo de texto, suhint flota hacia la parte superior proporcionando espacio para el texto. ´Esto asegura que el usuario nunca pierde el contexto del contenido que est´a introduciendo (Figura: 4.12).
Figura 4.12: Captura de la pantalla de Login.
