desarrollo de la aplicación android del blog ...en android, las bases de datos son sqlite....
TRANSCRIPT
Emilio Eguizábal Pérez-Aradros
María Vico Pascual Martínez-Losa
Facultad de Ciencias, Estudios Agroalimentarios e Informática
Grado en Ingeniería Informática
2014-2015
Título
Director/es
Facultad
Titulación
Departamento
TRABAJO FIN DE GRADO
Curso Académico
Desarrollo de la aplicación Android del blog lamaletadeunaaupair.com
Autor/es
© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2015
publicaciones.unirioja.esE-mail: [email protected]
Desarrollo de la aplicación Android del blog lamaletadeunaaupair.com, trabajofin de grado
de Emilio Eguizábal Pérez-Aradros, dirigido por María Vico Pascual Martínez-Losa(publicado por la Universidad de La Rioja), se difunde bajo una Licencia
Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los
titulares del copyright.
Facultad de Ciencias, Estudios Agroalimentarios e Informática
TRABAJO FIN DE GRADO
Grado en Ingeniería Informática
Desarrollo de la aplicación Android del blog
lamaletadeunaaupair.com
Alumno:
Emilio Eguizábal Pérez-Aradros
Tutores:
Maria Vico Pascual Martinez Losa
Logroño, Julio, 2015
3
Resumen La imposibilidad de encontrar un buen trabajo o las ganas de mejorar el inglés hacen a
nuestros jóvenes irse de nuestro país. A veces deciden irse de aupairs, a cuidar niños a otros
países. Mi clienta decidió hacer esto durante un año entero en Estados Unidos.
Este proyecto consiste en una plataforma de gestión de contenido y un cliente Android
que muestre este contenido. El contenido de la plataforma puede ser actualizado desde el
administrador web, y estos cambios en los datos se reflejan en el cliente Android. La
comunicación entre la plataforma, el cliente Android y el servidor se realiza mediante servicios
REST.
El contenido de la aplicación está orientado a ayudar a todos los jóvenes
hispanohablantes que quieran irse de aupair a Estados Unidos. Por esto mismo, está disponible
en dos idiomas, inglés y español.
Summary The impossibility of finding a job or the will of improving their english makes our young
people to leave our country. Sometimes, they decide to be aupairs, taking care of children on
other countries. My client decided to do that over a year in the United States.
This project it’s a CMS(content management software) and an Android client that
shows this content. The content can be updated on a web administrator and this changes are
shown on the Android client. The comunication between the CMS, the Android client and the
server is made with RESTful services.
The content of the application is meant to help all the young spanish speakers whom
want to be an aupair in the United States. It is available on two different languages, english
and spanish.
4
5
Índice
Resumen ................................................................................................................................................ 3
Summary ............................................................................................................................................... 3
Índice ..................................................................................................................................................... 5
Introducción .......................................................................................................................................... 8
Contexto del Proyecto .............................................................................................................................. 8
Objetivo del cliente ................................................................................................................................... 8
Tecnología del Proyecto ........................................................................................................................... 9
Requisitos iniciales ................................................................................................................................... 9
Cliente Android .................................................................................................................................... 9
El servidor .......................................................................................................................................... 10
Administrador web ............................................................................................................................ 10
Estudio de tecnologías ........................................................................................................................... 11
Plan de pruebas ...................................................................................................................................... 12
Planificación ........................................................................................................................................ 13
Diagrama de Gantt ................................................................................................................................ 13
Sprints .................................................................................................................................................... 13
Desarrollo ............................................................................................................................................ 15
Sprint 1: Diseño del Servidor ................................................................................................................ 15
Planificación ........................................................................................................................................... 15
Proceso de diseño ................................................................................................................................... 15
Base de datos ..................................................................................................................................... 15
Clases ................................................................................................................................................. 17
Implementación ..................................................................................................................................... 18
Seguimiento y control ............................................................................................................................ 18
Sprint 2: Servicios del Administrador Web ........................................................................................... 19
Planificación ........................................................................................................................................... 19
Servicios.................................................................................................................................................. 19
Replanificación ....................................................................................................................................... 20
Cambios en las clases básicas y persistencia ......................................................................................... 20
Diseño de los servicios ............................................................................................................................ 20
Implementación de los Servicios ............................................................................................................ 21
Seguimiento y control ............................................................................................................................ 22
6
Sprint 3: Administrador Web ............................................................................................................... 23
Planificación ........................................................................................................................................... 23
Diseño..................................................................................................................................................... 23
Diagrama de casos de uso ................................................................................................................. 23
Interfaz gráfica ................................................................................................................................... 24
Implementación de la Web .................................................................................................................... 24
Diseño de los servicios los datos de usuario ........................................................................................... 25
Seguimiento y control ............................................................................................................................ 26
Sprint 4: Finalización del Servidor ........................................................................................................ 27
Planificación ........................................................................................................................................... 27
Diseño de los servicios de actualización ................................................................................................. 27
Implementación de los servicios ............................................................................................................. 28
Reunión con el cliente y cambios ........................................................................................................... 28
Android, investigación de tecnologías ................................................................................................... 28
Seguimiento y control ............................................................................................................................ 29
Sprint 5: Diseño del cliente Android ..................................................................................................... 30
Planificación ........................................................................................................................................... 30
Diagrama de casos de uso ..................................................................................................................... 30
Diagrama de actividad del primer arranque .......................................................................................... 31
Diseño de la base de datos ..................................................................................................................... 32
Interfaz gráfica ....................................................................................................................................... 32
Diagrama de clases ................................................................................................................................ 33
Seguimiento y control ............................................................................................................................ 34
Sprint 6: Implementación del cliente Android ...................................................................................... 35
Planificación ........................................................................................................................................... 35
Base de datos y persistencia .................................................................................................................. 35
Lógica ..................................................................................................................................................... 37
Interfaz gráfica ....................................................................................................................................... 39
Seguimiento y control ............................................................................................................................ 40
Sprint 7: Finalización del proyecto ....................................................................................................... 41
Replanificación ....................................................................................................................................... 41
Layouts ................................................................................................................................................... 41
ArrayAdapter.......................................................................................................................................... 43
Control del flujo de la aplicación ............................................................................................................ 44
7
Rendimiento de la aplicación ................................................................................................................. 45
Seguimiento y control ............................................................................................................................ 45
Conclusión ........................................................................................................................................... 46
Tiempos reales y planificados ................................................................................................................ 46
Satisfacción del cliente ........................................................................................................................... 46
Conclusion final ...................................................................................................................................... 47
Mejoras del proyecto ............................................................................................................................. 48
Bibliografía .......................................................................................................................................... 49
8
Introducción
Contexto del Proyecto
Mi cliente es el creador y administrador del blog lamaletadeunaaupair.com. Decidió
irse de aupair a Estados Unidos y creó este blog para contar su experiencia e intentar ayudar a
otras personas que quieran irse de aupair a Estados Unidos.
Me ha solicitado la creación de una aplicación Android que le permita a los futuros
aupairs tener información en la palma de su mano, información que les haga más sencilla su
estancia y su preparación para el viaje a Estados Unidos. Este contenido será creado
específicamente para la aplicación sólo por mi cliente. Quiere poder actualizar el contenido en
todo momento y sin tener que depender de nadie.
Su intención es ofrecer esta información en sólo dos idiomas, castellano e inglés. No
tiene intención de dar soporte a otros idiomas u otros países porque sólo habla castellano e
inglés y los trámites administrativos requeridos para cada país difieren mucho de un país a
otro. Pese a que le informé de la posibilidad de utilizar un traductor, mi cliente dejó muy claro
que no quería contar con ello. Que quería hacer las traducciones a mano y centrarse sólo en
esos dos idiomas.
Objetivo del cliente
El objetivo del cliente es una aplicación Android que permita acceder al contenido
creado específicamente para la aplicación por él. Además, este contenido tiene que ser
actualizable por el cliente sin depender de nadie.
Para ello, tras un análisis inicial, mi proyecto va a constar de 3 apartados claramente
diferenciados.
La aplicación Android es básicamente una aplicación enciclopédica. Poseerá cierta
parte de interacción del usuario, no solo para moverse por la aplicación sino también para
aportar contenido.
Como mi clienta no quiere depender de nadie para administrar el contenido en su
aplicación, la opción más sencilla es que pueda subir el contenido mediante una interfaz web a
un servidor, y que el cliente Android se lo descargue.
Para poder subir el contenido creado por el administrador, se creará una web. En esta
web el administrador podrá editar y subir el contenido.
Así, el alcance inicial que planteo para el proyecto es el conjunto de estas tres partes.
9
El cliente Android, que tendrá un sistema de actualizaciones.
El administrador web, que permitirá la subida y edición de contenido
El servidor, que proporcionará y gestionará los datos.
Tecnología del Proyecto
A la hora de abordar el proyecto me he planteado distintas alternativas.
Utilizar un gestor de contenido como Wordpress, era una de mis ideas iniciales. Tengo
prácticamente todo lo que necesito ahí pero es demasiado complejo para adaptarlo en
poco tiempo. Además no he encontrado buenas y gratuitas extensiones para lo que
necesito.
Otra opción que se me ocurrió fué gestionar todos los datos desde xml pero la
complejidad que podían llegar a tener y sobre todo la extensión de los ficheros me
hizo ver que era más cómodo desde una base de datos.
Finalmente, la opción que he escogido es un servidor con servicios REST que me
permita comunicarme con el cliente Android y una web de administración del
contenido. He elegido este tipo de servicios porque tengo experiencia en su uso y
creación y creo que su uso es adecuado para el tamaño del proyecto.
Para ello necesito encontrar una tecnología que me permita crear servicios REST en PHP.
Me centro en el lenguaje PHP porque es la única tecnología para la que he encontrado
servidores gratuitos para la hora del despliegue del proyecto.
Requisitos iniciales
Cliente Android Toda la aplicación estará en dos idiomas, español e inglés. La funcionalidad básica del
cliente Android será la visualización de artículos. Estos artículos estarán clasificados según
secciones y subsecciones. La clasificación, las secciones y los propios artículos son contenido
que vendrá suministrado por el cliente.
Inicialmente existen tres tipos de artículos. El primero de ellos contiene imágenes y
texto, está destinado a los artículos más complejos y con más contenido. El segundo tipo de
artículos es un tipo vocabulario que contendrá una palabra, su traducción y su significado en
inglés. Y el tercer tipo de artículos es una lista interactiva estilo “todo list”. Es la típica lista de
la compra, en la que puedes tachar lo que has hecho.
Algo muy importante es que este tercer tipo de artículos, debería sincronizarse entre
el servidor y el cliente para que en el caso de que el cliente cambiase de móvil o borrase la
10
aplicación, no perdiese estos datos. Aquí es donde aparece la interactividad del usuario y el
servidor.
En cualquier parte de la aplicación debería poderse desplegar desde un lateral el menú
de favoritos, que permite acceder rápidamente a los artículos señalados. Este menú también
se sincronizará con el servidor.
Todos los datos de los artículos deberán estar disponibles offline. Se descargarán una
vez entres al artículo o, estando en una red wifi, automáticamente. Las futuras actualizaciones
se realizarán por internet.
La cuenta de usuario se definirá por el correo electrónico y la contraseña.
El servidor Es necesario un servidor desde el que descargar todas las actualizaciones que incluya
el cliente. Estas actualizaciones sólo pueden ser de contenido, ya que para introducir
funcionalidad se deberá contar con una actualización de la aplicación. Todos los datos
intercambiados entre el servidor y la aplicación o el cliente web se realizarán mediante
servicios REST.
El servidor contendrá todos los datos que se vayan a mostrar en la aplicación y
también los datos de usuario.
La distribución de los datos es igual que en la aplicación Android, se guardan las
secciones y cada tipo de artículo. El cliente detectará los artículos nuevos y el servidor se los
proporcionará para que los descargue.
El servidor tiene que guardar también los favoritos propios de cada usuario y los
artículos tipo lista de la compra que he descrito antes.
Como he explicado, el servidor tiene que suministrar datos a las aplicaciones y
mantener sincronizados los datos de usuario. También tendrá que guardar todos los datos que
el administrador de la aplicación (el cliente) quiera introducir para las actualizaciones.
Administrador web La finalidad del administrador web es que permita al administrador crear, guardar y
editar contenido.
Este administrador se basaría en una interfaz web que permita crear secciones y
artículos. Se podrán guardar borradores de todo tipo y publicarlos. Por supuesto tendrá un
sistema de carga de imágenes para poder incluirlas en los artículos.
Para acceder al sistema tendrá que autenticarse con su usuario y contraseña. Accederá
a un panel de administración que le permitirá añadir contenido. Una vez escrito, podrá
guardarlo en borradores o publicarlo. También puede ver todo el contenido.
11
Estudio de tecnologías Para cada una de las partes de mi proyecto, he analizado varias tecnologías.
Cliente Android
o Entorno de desarrollo: Android Studio
Pese a que haya trabajado ya para Android en Eclipse, Android Studio
ahora es el entorno de desarrollo oficial. Toda la información que he
leído acerca de este entorno es buena. Pese a ello, si me diese algún
problema, el cambio a Eclipse debería ser trivial. El problema es que
los plugins para desarrollar para Android desde Eclipse ya no tienen
soporte oficial. En mi caso esto no debería ser un problema porque mi
equipo de desarrollo tiene una versión muy antigua de Android.
o Tecnología de persistencia: Sqlite
En Android, las bases de datos son Sqlite. Seguramente mi proyecto
necesite una base de datos en el cliente Android pero no lo tengo aún
decidido.
o Versión API Android:
Mi dispositivo de desarrollo es un Sony Xperia U y la versión de
Android que lleva es la 2.3.1 sin opción a utilizar una versión más
reciente. Por eso, no me queda otra opción que utilizar la API 10, que
es una API muy vieja pero la última compatible con mi equipo.
Servidor
o Lenguaje de desarrollo: PHP
Como ya he explicado, el lenguaje que voy a utilizar es PHP. Es versátil,
tiene muchísima documentación muy detallada y existen muchos
frameworks que permiten la creación de servicios REST.
o Entorno de desarrollo: NetBeans
Ya lo he utilizado anteriormente en el Grado, así que lo conozco
perfectamente. Además lo utilicé en la asignatura de Desarrollo de
Aplicaciones Web. También utilizaré este entorno para el
administrador web.
o Tecnología de persistencia: MySql
Con PHP se puede utilizar casi cualquier tipo de base de datos, pero
MySql históricamente ha estado muy ligado con este lenguaje.
Funcionan muy bien juntos y no tengo otra opción ya que el servidor
en el que voy a desplegar la aplicación utiliza PHP y MySql.
o REST:
Aún no tengo claro el framework sobre el que voy a diseñar los
servicios. Conozco varios que permiten este desarrollo. En su
correspondiente Sprint decidiré el que vaya a utilizar.
Administrador Web
o Entorno de desarrollo: NetBeans
o Cliente REST:
12
Existen muchas posibilidades. Dependiendo de la versión de PHP del
servidor que tenga, puedo utilizar cURL, HTTP_Request o algún
framework. Lo decidiré en su Sprint.
Proyecto
o Diseños: ArgoUML y MySqlWorkbench
ArgoUML permite la creación de todo tipo de diseños. También
Poseidón era otra opción, porque ambos los he utilizado en el grado
pero este último es de pago. MySqlWorkbench lo utilizo para la BD.
o Control de versiones y copias de seguridad
Voy a utilizar Git para el control de versiones. Como mi proyecto
consta de varios entornos de desarrollo, sincronizaré los datos con una
aplicación externa a los propios entornos, SourceTree. Además, todo
mi proyecto va a estar alojado en Dropbox.
Plan de pruebas
Las pruebas que voy a ir realizando en varios sprints serán estas:
Pruebas unitarias: Para comprobar el correcto funcionamiento del código y los
métodos de la parte del servidor. Para este tipo de pruebas voy a utilizar la
herramienta PHPUnit. Este tipo de pruebas las integraré en la implementación de toda
la parte del servidor.
Pruebas de integración: Sobre todo para probar la aplicación Android. Existen
frameworks para hacerlo en Android pero son muy dependientes de la versión de la
API que esté utilizando. Estas pruebas las haré a mano.
Pruebas de aceptación: Por supuesto, mi cliente supondrá parte de las pruebas de mi
proyecto. Estas pruebas consisten en que el usuario final de la aplicación la prueba y
decide si sigue o no sus requisitos.
13
Planificación Voy a seguir la metodología SCRUM. Voy a dividir el proyecto en 8 Sprints, todos de 40
horas y el último de 20.
Diagrama de Gantt
Este diagrama refleja la duración de los sprints y su planificación en el tiempo del proyecto. En
total son 300 horas de proyecto.
Sprints Sprint 0:
Este Sprint me sirve para planificar y organizar todo el proyecto. Es el Sprint que estoy
haciendo ahora. También he tenido la primera reunión con el cliente.
En cada uno de los Sprints tendré unas horas para planificarlo y para llevar un
seguimiento y control respecto a la planificación general y a la propia planificación de cada
sprint. Este documento formará parte del entregable de cada uno de los sprints. El entregable
contendrá una explicación extensa de todo lo que se ha hecho en el sprint. Estos entregables
formarán parte de la memoria.
Sprint 1:
Diseño del servidor. Me encargaré del diseño de la base de datos y de las clases
orientadas al funcionamiento interno del servidor. Los servicios los diseñaré e implementaré
específicamente en el sprint dedicado a cada parte. Implementaré la base de datos y las clases
diseñadas.
Sprint 2:
En este sprint diseño completamente los servicios que necesitará el cliente del
administrador web. Para ello decidiré qué tecnología utilizaré en los servicios. También los
implementaré.
14
Sprint 3:
Diseñaré e implementaré el prototipo del administrador web y realizaré las pruebas
pertinentes para su correcto funcionamiento. Tendré también la segunda reunión con el
cliente para que pueda empezar a introducir contenido.
Sprint 4
Terminaré el servidor completamente en este sprint, con los servicios orientados al
usuario. Analizaré bien el cliente Android y elegiré las tecnologías y patrones que vaya a
utilizar. Tendré una tercera reunión con el cliente para evaluar la herramienta del
administrador y que proponga posibles cambios.
Sprint 5
Diseño completo del cliente android. Si en la reunión anterior se han producido
cambios, los realizaré conforme a lo acordado. Este diseño contendrá desde los diagramas de
clases hasta el diseño de la interfaz gráfica.
Sprint 6
Implementación del cliente android. A la hora de implementar el cliente, tendré en
cuenta el rendimiento de la aplicación y su tamaño, para intentar que funcione lo más rápido
posible y en el espacio más reducido posible.
Sprint 7
Finalización de la implementación y finalización de la memoria.
Hasta aquí son 300 horas planificadas. Como añadido al proyecto, voy a planificar 2
sprints extra por si se diese el caso de que me sobrara tiempo.
Sprint 8 extra
Mejorar el administrador web, diseñando una interfaz más amigable y usable. En el
proyecto inicial mi idea del administrador web es que sea un prototipo que visualmente sea
sencillo y que funcione bien. Ahora diseñaré e implementaré un administrador que sea más
sencillo de usar y con un aspecto más atractivo.
Sprint 9 extra
El siguiente paso sería hacer un cliente web para que cualquier usuario pueda acceder
a los datos sólo con un navegador.
15
Desarrollo
Sprint 1: Diseño del Servidor Este Sprint lo dedicaré al diseño del servidor. Contendrá desde el diseño de la base de
datos inicial, únicamente teniendo en cuenta el contenido de la aplicación, hasta la lógica del
servidor. Empezaré con los servicios en el siguiente Sprint.
Planificación Servidor, diseño de base de datos 16 horas
Servidor, implementación de base de datos 4 horas
Servidor, diseño de clases básicas y persistencia 10 horas
Servidor, implementación de clases básicas y persistencia 8 horas
Documentación 2 horas
Total 40 horas
Empiezo por el servidor. Comienzo con la base de datos y a partir de ahí implemento
tanto la base de datos como todas las clases que me permitan acceder a ésta y trabajar con
ella. Estas clases son parte de la lógica de negocio y la persistencia de la aplicación. Este sprint
tiene que estar muy bien diseñado porque todo el proyecto va a depender de ello.
Proceso de diseño
Base de datos
16
Este diagrama lo he creado con el software libre DIA. No lo había especificado antes
porque contaba con que ArgoUML o MySqlWorkbench podían diseñar este tipo de diagramas.
Como no es así, he tenido que buscar una herramienta que cumpliera mis necesidades.
La base de datos contiene los datos necesarios explicados en el Sprint 0. He añadido el
administrador para que se puedan cotejar los datos de usuario y contraseña y que nadie pueda
subir contenido excepto mi cliente.
Como se ve, los 2 idiomas se guardan a la vez en cada tabla en campos separados. Creo
que es la solución más cómoda ya que no deberían ser datos muy extensos y sólo vamos a
requerir uno de ellos cada vez que vayamos a mostrar cualquier artículo. Barajé otras
alternativas para la internacionalización pero mi cliente fue muy claro en este tema, y sólo va a
querer 2 idiomas. De esta manera, la alternativa más barata en recursos es ésta. Al ser un
alojamiento gratuito, el espacio es muy limitado.
Inicialmente, los datos pertenecientes a los usuarios finales de la aplicación no los voy
a tener en cuenta porque los añadiré más adelante, en su sprint correspondiente.
La relación entre las secciones implica la existencia de secciones generales y
subsecciones. Aquellas que no estén relacionadas serán secciones generales. Esto permite
crear una jerarquía dentro de las secciones.
Los artículos tendrán un campo que reflejará si están publicados o no. Este campo
servirá para gestionar los borradores y así permitir la escritura parcial de artículos por parte
del administrador.
Como se puede ver sólo se podrán escribir tres tipos de artículos. Esta herencia es
disjunta y total aunque por limitación del software del diagrama no aparezca. Si es un artículo
con texto e imágenes se utilizará el tipo HTML, si es un artículo tipo lista de la compra se
utilizará Lista y si es vocabulario se utilizará Vocabulario. Este último tipo de artículos tiene
tres campos de contenido. Estos campos se utilizarán para la palabra en castellano, su
traducción directa y su significado en inglés.
17
El paso a tablas del diagrama de entidad relación, queda así.
La entidad sección está transformada como una sola tabla, pese a que la relación que
lleva esta entidad permite hacerlo de otra forma. Esto me genera nulos en el campo
seccionPadre, pero me ahorra una tabla.
La herencia se transforma en una relación entre la tabla padre(artículo) y las hijas. Al
no tener ningún atributo, las entidades lista y vocabulario no se reflejan en la base de datos.
Las entidades vocablo y elemento son las que están relacionadas con artículo al haber
desaparecido lista y vocabulario.
Pese a que esta herencia me permitiría su transformación a tablas de diferentes
maneras, he elegido ésta porque no me introduce nulos.
Clases
He decidido orientar el servidor de la siguiente manera:
Siguiendo la arquitectura de 3 capas, la voy a aplicar al servidor. Ahora solo voy a crear
el modelo y la persistencia, estas dos partes me permitirán acceder y controlar todos los datos
de la base de datos, y controlar la lógica de negocio. La tercera capa, la vista, corresponde con
el cliente Android y al Administrador web. Esa la haré más adelante.
Como se puede ver, la persistencia sólo contiene 2 clases, se encargarán de las
conexiones con la base de datos y de guardar y extraer los datos. He creado también las clases
básicas, son meros accesores de los que tirarán los servicios.Las clases básicas del servidor
permitirán el acceso a la base de datos y el control y uso de todos esos datos.
La clase DBManager será la encargada del guardado de los datos y la extracción de
ellos desde la base de datos. Se apoyará sobre la clase DBConnect para la conexión a la base de
datos.
18
Implementación Para la implementación del servidor, voy a necesitar lo primero el propio servidor
físico. Cuando decidí el lenguaje a utilizar en el servidor, esto también lo tuve en cuenta puesto
que los hostings gratuitos suelen llevar PHP y MySql. Mi idea inicial era utilizar Python para la
programación dado que en las prácticas diseñé e implementé una api REST muy parecida a lo
que necesito, pero dado que no encontré una opción gratuita para un servidor con esta
tecnología, decidí hacerlo en PHP, como ya expliqué.
Por lo tanto, he reservado un servidor en Hostinger y me dispongo a la
implementación. Tener el servidor tan pronto, me permite probar todo en su entorno real y
trabajar con las versiones específicas relativas a cada tecnología que utilice.
La implementación de la base de datos es trivial. La de las clases básicas y la
persistencia es más costosa porque tengo la estructura pero no la funcionalidad.
Seguimiento y control Me dí cuenta que para terminar el Sprint necesitaba más horas así que pese a haber
planificado 40 horas, terminé el sprint en el plazo planificado invirtiendo las horas necesarias.
Planificado Real
Servidor, diseño de base de datos 16 horas 18 horas
Servidor, implementación de base de datos 4 horas 1 horas
Servidor, diseño de clases básicas y persistencia 10 horas 12 horas
Servidor, implementación de clases básicas y persistencia 8 horas 8 horas
Documentación 2 horas 6 horas
Total 40 horas 45 horas
Como se puede ver, el diseño de la base de datos me llevó más tiempo del que había
planificado así como el diseño de las clases básicas, la persistencia y la documentación. Para
los siguientes sprints lo tendré en cuenta. No se ha debido este retraso a nada en especial sino
a intentar hacer las cosas bien y de manera exhaustiva.
La documentación me ha costado el triple de lo que había planificado. Esto es muy
significativo ya que en todos los demás sprints tengo una parte de documentación así que
tengo que tenerlo muy en cuenta en mis siguientes planificaciones.
En cambio, la implementación de la base de datos ha sido muy rápida.
19
Sprint 2: Servicios del Administrador
Web
Este sprint lo dedicaré a los servicios orientados al administrador. Analizaré las
tecnologías que me permiten la creación de servicios REST en PHP y elegiré la adecuada.
Diseñaré esos servicios y los implementaré.
Planificación Servidor, elección y aprendizaje de la tecnología sobre la que sustentar los servicios. 12 horas
Servidor, diseño de los servicios web 6 horas
Servidor, implementación de los servicios web 16 horas
Documentación 6 horas
Total 40 horas
Servicios Para encontrar el framework que necesito he hecho una búsqueda exhaustiva por la
red. He encontrado varios que me podrían servir sin problemas pero sólo necesito uno. He
escogido 4 que parecían apropiados por su gratuidad y su buena fama: Laravel, Slim, Epiphany
y Limonade.
Limonade queda casi descartado desde el principio porque la documentación es escasa
y está bastante desorganizada. Laravel tiene una muy buena documentación pero está
orientado a productos a gran escala. Esta sería una buena opción en caso de que el proyecto
alcanzase un tamaño considerable. Tanto Epiphany como Slim tienen muy buena pinta ya que
los dos tienen muy buena documentación y son muy sencillos de usar. Dado que he trabajado
con un framework REST en python, escojo el que más se parece, Slim.
Este framework permite crear una aplicación que gestiona casi automáticamente los
servicios y me provee de herramientas sencillas para su creación. El primer paso es aprender a
utilizar esta tecnología. Gracias a la extensa documentación existente esto no es un problema.
Ya que una API REST tiene unas propiedades específicas, el diseño de esta api va
también ligado a estas propiedades. Este diseño se basa en que dependiendo de quién realiza
la petición de datos, te proporciona éstos de una manera más simple o más compleja. Si el
administrador quiere editar un artículo, éste deberá recibir el artículo completo con los 2
idiomas. En cambio, un usuario final, sólo debería recibir un idioma, el que haya solicitado.
20
Siguiendo el diseño que he realizado en el Sprint 1, me fijo en que esto no lo tengo
contemplado. Sólo he diseñado las clases básicas desde el punto de vista de la app Android,
del usuario. Tengo que diseñarlo desde el punto de vista del Administrador.
Replanificación He tardado aproximadamente 12 horas en seleccionar y estudiar la tecnología para los
servicios. Ahora tengo que replanificar, cambiar las clases básicas y la persistencia, y continuar
con el sprint.
Planificado Real
Servidor, elección y aprendizaje de la tecnología sobre la que sustentar los servicios.
12 horas 12 horas
Cambio de las clases básicas y la persistencia 8 horas -
Servidor, diseño de los servicios web 6 horas -
Servidor, implementación de los servicios web 16 horas -
Documentación 6 horas -
Total 48 horas -
Cambios en las clases básicas y persistencia Los procesos de carga y guardado de los datos tenían que contemplar el punto de vista
del administrador y del usuario, así que he tenido que crear nuevas clases que permitan el
punto de vista del administrador.
Así, he creado las clases “Completas”, que son clases hijas de
las que ya tenía creadas añadiendo los datos que me faltaban.
Por ejemplo la clase Artículo, desde el punto de vista del
usuario sólo contiene el nombre y el id, para el administrador contiene
los dos idiomas, si está o no publicado y la sección a la que pertenece.
Diseño de los servicios Una vez he terminado con las clases y la persistencia, paso a diseñar los servicios. Estos
servicios que diseño, corresponden a los que van a utilizar el cliente Android y el administrador
web. En total, los servicios van a estar divididos en 3 partes:
Servicios del administrador web: estos servicios permiten acceder y editar los datos
desde el administrador web. También serán usados por el cliente Android para acceder a los
datos.
Servicios de datos de usuario: los utilizará el cliente Android para sincronizar los datos
de los usuarios, como los favoritos.
21
Servicios de actualizaciones: Estos servicios le darán al cliente Android la información
que necesite para, utilizando los demás servicios tener siempre disponible la última versión de
los datos.
Pese a que ahora parezca un poco confuso, aún no tengo decidido cómo van a
funcionar del todo los servicios de actualización. En sus respectivos sprints, los definiré más
detenidamente.
Ya que una API REST tiene unas propiedades
específicas, el diseño se basa en que dependiendo
quién realiza la petición de datos los devuelve de una
forma sencilla o compleja. Si el administrador quiere
editar un artículo, éste deberá recibir el artículo
completo con los 2 idiomas. En cambio, un usuario final,
sólo debería recibir un idioma, el que haya solicitado.
Como ya he explicado los primeros 5 métodos del
servicio dependen de quién los esté utilizando según
authenticate(). Si es el administrador recogerá los datos
“Completos” y si es un usuario final recibirá los datos
más sencillos.
Los demás métodos sólo pertenecen al administrador.
Éstos permiten la modificación e inserción de nuevos
datos.
El sistema de autenticación lo crearé en el siguiente
Sprint.
Implementación de los Servicios Al igual que con la lógica, he utilizado el IDE NetBeans. No he tenido complicaciones
más allá de lo habitual. A la hora de la implementación hay varios métodos del Sprint anterior
que tenían errores en su funcionamiento que no he detectado hasta ahora.
Para ilustrar esta implementación voy a poner un pequeño fragmento de código,
explicando la cabecera de los servicios:
22
Como se ve en la imagen, en la cabecera defino la ruta del servicio y los parámetros
que voy a tener. Directamente ahí le especifico el método que va a realizar, en este caso sólo
devolver un objeto Json con los datos de un artículo.
También he tenido que arreglar unos errores que he arrastrado del sprint 1.
Seguimiento y control Habiendo terminado el sprint, al final he dedicado unas horas extra a la
implementación de los servicios para corregir algunos errores que arrastraba desde el Sprint
anterior que aún no había detectado. Esta es la tabla de tiempos final:
Planificado Real
Servidor, elección y aprendizaje de la tecnología sobre la que sustentar los servicios.
12 horas 12 horas
Rediseño e implementación de las clases básicas y persistencia
8 horas 6 horas
Servidor, diseño de los servicios web 6 horas 2 horas
Servidor, implementación de los servicios web 16 horas 17 horas
Documentación 6 horas 6 horas
Total 48 horas 43 horas
Pese a la replanificación, mi planificación inicial no iba desencaminada. La
replanificación me ha hecho meter unas horas extras, pero como lo he hecho dentro del plazo
establecido, la planificación general no se ha visto afectada.
23
Sprint 3: Administrador Web
Una vez tengo los servicios básicos funcionando, paso a diseñar e implementar el
administrador web. Este administrador va a tener 2 partes muy diferenciadas, un pequeño
cliente de los servicios REST que ya tengo diseñados y la web que va a permitir interaccionar e
introducir infomación al administrador.
Planificación Cliente web, diagrama de casos de uso 2 horas
Cliente web, diseño interfaz gráfica 2 horas
Cliente web, implementación 16 horas
Servicios datos de usuario, diseño 4 horas
Servicios datos de usuario, Implementación 10 horas
Documentación 6 horas
Total 40 horas
Me encargaré del cliente web del administrador. La funcionalidad será el logueo del
usuario y la posibilidad de ver todos los datos y añadir datos nuevos. Una vez acabado este
cliente, me encargaré de finalizar los servicios que quedan propios de los usuarios finales.
Diseño
Diagrama de casos de uso
El diagrama de Casos de Uso sólo refleja lo que el administrador va a poder hacer en su
cliente web. Empezará logueándose en la plataforma y podrá elegir una categoría de las
disponibles o añadir una. Una vez haga cualquiera de las dos cosas, dependiendo de si la
24
categoría tiene subcategorías o no, podrá elegir subcategoría, elegir un artículo o añadir un
artículo. Si elige un artículo podrá editarlo.
Pese a que este diagrama parezca confuso, sólo da todas las opciones que necesita el
administrador.
Interfaz gráfica
Tras el típico formulario de logueo, la interfaz gráfica general he intentado que tenga
todos los datos de un vistazo. Los botones que añaden nuevas categorías añaden un
formulario que permite crear esa categoría. Al seleccionar cada una de las categorías o
artículos recarga la página para cargar los datos .
Soy consciente que no es un buen diseño. Esta versión es un prototipo, lo que me
interesa es que funcione para que le permita a mi cliente meter datos y darme su valoración
sobre las posibilidades que tiene. Si me sobrara tiempo intentaría hacerla más usable para el
administrador.
Implementación de la Web Al igual que con la lógica, he utilizado el IDE NetBeans. No he tenido complicaciones
más allá de lo habitual. A la hora de la implementación hay varios métodos del Sprint anterior
que tenían errores en su funcionamiento que no he detectado hasta ahora.
25
En la implementación he tenido varios problemas: desde problemas con la sesión
activa hasta a la hora de recoger y enviar los datos de los servicios. Para esto, he tenido que
crear un cliente específico de mis servicios utilizando HTTP_request. Había pensado utilizar
algún framework, pero utilizando PHP > 5.x, este tipo de conexiones se ha simplificado mucho
y no ha hecho falta. He solventado todos los problemas dedicando algo más de tiempo del
planificado.
Diseño de los servicios los datos de usuario El primer servicio que he diseñado es el sistema de logueo. Pese a que mi idea inicial
era utilizar algún sistema de seguridad ya extendido como Oauth 2, es demasiado complejo
para un proyecto de estas características. Por tanto he decidido crear un sistema sencillo pero
efectivo de logueo.
Utilizando el usuario y contraseña que manda el cliente, el servidor crea un hash con
esta información y el timestamp actual. Este hash es enviado al cliente y es guardado
temporalmente en la base de datos. Mientras tanto, el cliente manda ese hash en cada
petición para ser identificado. Esta autenticación caduca en 60 minutos. Por supuesto, el
usuario puede cerrar sersión en el momento que quiera.
Por supuesto, este sistema no es seguro a no ser que se utilice sobre ssl. Debido a que
el proyecto hasta ahora es didáctico, no considero necesario probarlo en un entorno real. En
un entorno real, el servidor debería soportar SSL o cambiar el sistema de autenticación.
El resto de los servicios aún no los he acabado porque el mayor problema con el que
cuento es que tengo que diseñar un sistema para mantener el cliente Android actualizado.
Los servicios por parte del cliente Android que sirven para
sincronizar los datos propios del usuario como los favoritos, etc,
ya están diseñados. Los implementaré en el siguiente Sprint.
Estos servicios me permiten recoger y guardar los datos
que el usuario puede modificar. Los tres primeros se centran en
los favoritos y los tres últimos en los artículos tipo lista. Estos servicios me permitirán
sincronizar los datos entre el servidor y el usuario.
Pero el sistema de actualizaciones aún no lo tengo del todo. Aún no tengo del todo
claro cómo lo voy a hacer y si tengo que cambiar el comportamiento que tenía pensado para el
cliente android. En el siguiente Sprint definiré todas las posibilidades y eligiré una de ellas.
26
Seguimiento y control Como se puede suponer por esta documentación, este Sprint ha ido un poco distinto a
la planificación inicial.
Planificado Real
Cliente web, diagrama de casos de uso 2 horas 0.5 horas
Cliente web, diseño interfaz gráfica 2 horas 0.5 horas
Cliente web, implementación 15 horas 16 horas
Servicios datos de usuario, diseño 4 horas 10 horas
Servicios datos de usuario, Implementación 10 horas --
Documentación 6 horas 6 horas
Total 40 horas 33 horas
Pese a que tenía planificado hacer en este sprint la implementación de los servicios de
los datos de usuario decidí dejarlo para el siguiente sprint. Estos días no pude dedicar todo el
tiempo planificado en el sprint y lo iba a dejar a medias.
27
Sprint 4: Finalización del Servidor
En este sprint acabo el servidor. Me encargaré de diseñar los servicios orientados a las
actualizaciones del cliente Android e implementaré los servicios que ya tengo diseñados. Si
tengo tiempo, empezaré investigando sobre las tecnologías que voy a necesitar para el
desarrollo de la aplicación Android.
Planificación Servidor, diseño de los servicios de actualización 10 horas
Servidor, implementación de los servicios restantes 10 horas
Reunión con el cliente 2 horas
Realización de cambios 8 horas
Android, investigación sobre tecnologías 4 horas
Documentación 6 horas
Total 40 horas
Diseño de los servicios de actualización A la hora de diseñar estos servicios tengo que tener en cuenta que también tengo que
especificar el sistema de actualización por parte del cliente.
Mi idea principal era que el cliente Android se conectara a internet para descargar las
actualizaciones y quería que parte del contenido viniese instalado. Voy a cambiar esto para
hacerlo más sencillo. Voy a hacer que todo el contenido se descargue del servidor, pero que se
mantenga en el móvil a no ser que el contenido cambie. Esto permitirá al usuario utilizar la
aplicación aunque no tenga internet.
Para lograr mi idea debería hacer un sistema más complejo de lo que tengo hasta
ahora, y sobre todo, debería hacer un cliente Android bastante pesado que contenga toda la
información. Por lo tanto voy a hacerlo de otra manera.
Toda la información va a estar siempre en el servidor. El cliente Android, dependiendo
del lenguaje que se haya escogido, irá descargando sólo la información que necesite. Toda esta
información se guardará localmente lo que ahorrará datos al usuario. Si el dispositivo está en
una red wifi, descargará toda la información que le sea posible sólo mientras se esté usando la
aplicación.
Para llevar todo eso a cabo, el servidor y el cliente tienen que saber lo que necesita el
cliente. Lo que voy a hacer es poner una fecha de modificación en toda la base de datos que
me permita seleccionar los datos modificados desde cierta fecha.
28
Teniendo en cuenta que el cliente no va a tener ningún solo dato desde el principio, lo
primero que hará será pedir las categorías principales, y a partir de ahí irá pidiendo todos los
artículos de cada categoría. Así conseguirá todos los datos.
Para este sistema tengo que añadir varios servicios más, uno por cada tipo de
contenido que me devuelva los identificadores de cada información cambiada desde cierta
fecha.
Por lo tanto, los servicios que necesito quedan diseñados así:
Tengo que poder acceder a los artículos y las secciones,
así que tengo que tener gets de los dos tipos de contenido. Estos
servicios me devolverán identificadores de cada uno de los
contenidos y con esos identificadores podré recoger la
información completa con los servicios que ya tenía hechos.
Implementación de los servicios Como ya es el segundo sprint que dedico a los servicios, esta implementación ha sido
bastante sencilla y rápida. No he tenido prácticamente ningún problema y lo he hecho en
bastante menos tiempo del planificado.
Reunión con el cliente y cambios En la reunión con el cliente le he enseñado el funcionamiento del administrador web.
Le he enseñado a utilizarlo y de momento no ha sugerido ningún cambio.
Android, investigación de tecnologías Para mi proyecto y su sistema de datos, lo más lógico sería realizar una réplica de la
base de datos en cada uno de los dispositivos para poder acceder localmente a estos datos. La
base de datos será una Sqlite y es muy posible que acompañaré la aplicación de algún tipo de
guardado de opciones.
Para el guardado de los datos, Sqlite es la única opcion que permite el manejo con
comodidad de muchos datos. Y teniendo en cuenta que necesito guardar todos los datos de un
idioma en la aplicación, es la mejor opción. Por supuesto, con archivos XML también se podría
hacer, pero serían poco más una réplica de la base de datos en XML y dependiendo de la
cantidad de los datos o el tamaño, no sería funcional.
A la hora de guardar algún tipo de configuración tenemos 2 opciones: XML y
Preferences. Como Preferences está orientado a este tipo de datos, voy a usarlo. Consiste en la
gestión de pares, clave y valor. Pese a que con los XML también me serviría prefiero usar una
herramienta ya destinada para ello.
29
He estado investigando llamadas a las api del sistema para saber cuándo estoy
conectado por wifi o datos, o para poder hacer tareas con la aplicación cerrada.
Seguimiento y control Planificado Real
Servidor, diseño de los servicios de actualización 10 horas 10 horas
Servidor, implementación de los servicios restantes 10 horas 6 horas
Reunión con el cliente 2 horas 2 horas
Realización de cambios 8 horas 0 horas
Android, investigación sobre tecnologías 4 horas 4 horas
Documentación 6 horas 6 horas
Total 40 horas 28 horas
Este Sprint ha sido más corto de lo habitual. Analizar y diseñar los servicios de
actualización es lo que más me ha llevado. La implementación de estos servicios ha sido
mucho más liviana de lo que creía y el hecho de no haber tenido cambios en el cliente web me
ha ahorrado mucho tiempo. Pese a ello, he decidido comenzar el siguiente sprint según lo
planificado porque tampoco he tenido mucho tiempo de sobra.
30
Sprint 5: Diseño del cliente Android
Con este Sprint comienzo el cliente Android. Empezaré diseñando todo lo relativo al
cliente e intentaré llegar a una mínima implementación. Tengo que tener varias cosas en
cuenta.
Intento buscar la optimización y el ahorro de espacio dentro del dispositivo móvil, ya
que aunque ahora sean máquinas bastante potentes, estoy desarrollando con un móvil
bastante viejo. Esto me obliga a utilizar una API de Android antigua, en mi caso la 10. Va a ser
un problema para utilizar ciertos controles. Por lo tanto, todas las decisiones de diseño y
funcionamiento del cliente Android están basadas en esta premisa.
Planificación Cliente Android, diagrama de casos de uso 4 horas
Cliente Android, diagrama de actividad de primer arranque 2 horas
Cliente Android, diagrama de base de datos 6 horas
Cliente Android, interfaz gráfica 10 horas
Cliente Android, diagrama de clases 12 horas
Documentación 6 horas
Total 40 horas
Voy a intentar hacer completo el análisis y diseño del cliente Android. Una parte muy
importante, que es la gestión de actualizaciones, ya la tengo definida de sprints anteriores. Si
llegase a sobrarme tiempo intentaría empezar con la implementación de la base de datos y
diagramas de clases.
Diagrama de casos de uso Una vez me pongo con el cliente Android, lo más importante es tener una manera
31
sencilla para que el cliente pueda acceder a todo. La usabilidad debe ser ligera e intuitiva. Por
lo tanto el diagrama de casos de uso refleja todo esto.
Para no estar navegando entre todas las secciones de toda la aplicación, el acceso a los
favoritos tiene que ser muy sencillo. Deslizando desde la izquierda te saldrá el típico
“hamburguer menu” que permitirá acceder a los favoritos. También pulsando en el botón de
este tipo de menús.
Diagrama de actividad del primer arranque
Al ser el primer arranque, tengo que especificar cómo voy a hacer la selección de
idioma y sobre todo, cómo el servidor también depende de ello. El logueo y registro dentro del
sistema también se realizará justo al principio aunque será totalmente opcional.
32
Diseño de la base de datos La base de datos del cliente va a ser una réplica de la base de datos del servidor, pero
más sencilla.
Como se puede ver el cambio más significativo, a parte de no incluir los dos idiomas, es
la inclusión de la entidad Favorito. Como ya he explicado, sólo incluyo un idioma para hacer la
aplicación más ligera. La entidad Favorito es la que se encarga de guardar los favoritos de cada
usuario, y los sincronizará con el servidor.
La transferencia a tablas de este diagrama es igual que en el caso del servidor. La única
diferencia es la entidad favoritos, que conforma una nueva tabla con un sólo campo, el id de
los artículos que serán favoritos para el usuario.
Interfaz gráfica
En esta imagen
podemos ver el menú
principal, que contará con
todas las secciones
principales, y el menú de
favoritos, que como ya he
explicado se mostrará
deslizando desde la
izquierda y pulsando sobre
el botón de menú.
33
Aquí muestro la
pantalla propia de cada sección
y de cada subsección. Se puede
ver que cada artículo se podrá
añadir a favoritos usando la
estrella que tiene al lado de su
nombre.
Y aquí debajo muestro
las vistas pertenecientes a cada
uno de los tipos de artículos.
No he utilizado los botones
para navegar en pantalla
porque para ir hacia atrás ya
existe el botón físico.
Diagrama de clases Mi diagrama de clases se basa en el del servidor para poder gestionar los datos de la
misma manera. Tendré una persistencia que utilizará la base de datos sqlite diseñada. De esta
persistencia, tirarán las clases de la lógica de negocio. Estas clases serán las mismas que en el
servidor con algunas variaciones.
34
Como se puede ver, parece una réplica del diagrama del servidor. El cambio más
significativo es el nuevo paquete de Utilidades.
La clase JAdapter se encargará de comunicarse con el servidor y recoger todos los
datos que necesite la aplicación. Parseará toda la información que recoja de los servicios y
enviará los datos al servidor para guardar los favoritos y para la gestión del usuario. Esta clase
se utilizará cuando la base de datos no tenga los datos a los que el usuario está intentando
acceder y cuando existan nuevos datos que descargar.
La clase JUpdater se encargará de gestionar la actualización de los datos. Utilizará la
clase Jadapter para acceder a los datos desde los servicios y los guardará utilizando la
persistencia.
Seguimiento y control Planificado Total
Cliente Android, diagrama de casos de uso 4 horas 2 horas
Cliente Android, diagrama de actividad de primer arranque 2 horas 2 horas
Cliente Android, diagrama de base de datos 6 horas 4 horas
Cliente Android, diseño de la interfaz gráfica 10 horas 12 horas
Cliente Android, diagrama de clases 12 horas 8 horas
Documentación 6 horas 6 horas
Total 40 horas 34 horas
Pese a que se me ha quedado un poco escaso de horas, ya sabía que la interfaz gráfica
me iba a costar bastante. He ahorrado bastante tiempo en la base de datos y en el diagrama
de clases porque no son más que una modificación de lo que ya tenía diseñado para el
servidor.
35
Sprint 6: Implementación del cliente
Android
Planificación Cliente Android, implementación de la base de datos 8 horas
Cliente Android, implementación del diagrama de clases 20 horas
Cliente Android, implementación de la interfaz gráfica 6 horas
Documentación 6 horas
Total 40 horas
Pese a que la conversión de la base de datos a sqlite debería ser trivial, nunca he
utilizado una base de datos de este tipo por lo que podrían surgir problemas. La
implementación de las clases va a ser bastante costosa por la clase jadapter, que se encargará
de acceder a los servicios. La implementación de la interfaz gráfica no espero que me dé
tiempo. La terminaré en el siguiente Sprint.
Por supuesto, para el desarrollo en Android utilizaré java con una versión específica de
SQL para Sqlite, una versión simplificada.
Base de datos y persistencia A la hora de implementar la base de datos hay que tener en cuenta varios factores. El
lenguaje compatible con sqlite es mucho más sencillo que el compatible con mysql. Esto no me
permite exportar los datos directamente desde MysqlWorkbench a Android.
Lo que he tenido que hacer es adaptar el código que he exportado desde
mysqlworkbench a sqlite. Ha sido bastante sencillo y sólo he tenido que dejar poco más que el
esqueleto de la tabla. Por ejemplo la tabla sección queda así:
CREATE TABLE IF NOT EXISTS 'seccion' ( 'idseccion' INT NOT NULL,
'nombre' VARCHAR(45) NULL, 'seccionPadre' INT NULL, PRIMARY KEY
('idseccion'), FOREIGN KEY ('seccionPadre') REFERENCES 'seccion'
('idseccion') ON DELETE NO ACTION ON UPDATE NO ACTION)
En las demás tablas el código es prácticamente igual.
A la hora de crear la base de datos, en Android es totalmente diferente que en
cualquier otra plataforma que haya trabajado. Normalmente, se crea la base de datos desde
un intérprete sql y se conecta con el servicio de base de datos desde la aplicación. En Android,
no funciona así.
36
Hay que crear la base de datos desde una clase que implemente SQLiteOpenHelper. En
esta clase hay que implementar los métodos onCreate y onUpgrade.
El método onCreate(SQLiteDatabase db) se ejecutará para crear la base de datos. Ahí hay que ejecutar las consultas necesarias para crear las tablas e insertar los datos. El método onUpgrade, se ejecutará cuando pidamos una versión nueva de la base de
datos. Aquí tendremos que meter el código necesario para poder actualizar la base de datos.
Una vez tenemos la clase que implementa SQLiteOpenHelper, para utilizarla sólo
necesitamos crear una instancia de ella y utilizar el método getReadableDatabase o el
método getWritableDatabase. Eso nos devuelve un objeto SQLiteDatabase, ya sea sólo
en modo lectura o en modo lectura y escritura. Ya podemos utilizarlo para nuestra clase de
persistencia.
Mi clase DBManager me permite acceder a
todos los datos. Tiene los métodos para acceder,
añadir y eliminar todo el contenido.
La peculiaridad de estos métodos es el
acceso a los datos en sí. Tengo que utilizar un
cursor para ello.
Por ejemplo en la clase artículo, para extraer el artículo con un determinado id.
Creamos un cursor que nos dé los datos de la tabla, con los campos que queremos, la
condición y los argumentos necesarios. Después recorremos todo el cursor rellenando el
objeto.
Para los demás objetos es muy parecido. El objeto sección, por ejemplo, tiene varias
llamadas a la base de datos para rellenar las listas de artículos y subsecciones.
37
Lógica La implementación de las clases ha sido muy sencilla hasta llegar a la clase jadapter.
Las clases son bastante triviales y ya las he implementado
antes en otro lenguaje. Son distintas a las que implementé en php
básicamente porque para poder acceder a la persistencia, tengo
que pasar la base de datos por el constructor de cada una de las
clases.
De este modo, en la clase artículo tengo varios
constructores pero el que me permite rellenarla con los campos
de la base de datos queda así:
Esto me permite desde la base de datos general, tener acceso desde cualquier clase.
A la hora de acceder a los datos de los servicios he tenido que depender de varias
clases.
La clase HttpClient me permite realizar una petición get a mi servicio de acceso al
artículo. Esta petición get la configuro con la url de mi servicio y con el header de json. Una
vez realizada la petición recojo los datos como JSONObject y extraigo los datos según su tipo e
identificación.
38
A la hora de realizar otra petición get, cuando tengo que recoger los datos de un vocabulario,
hay que tener en cuenta que hay varios elementos en cada petición y que vienen en forma de
JSONArray.
Las peticiones para insertar nuevos datos son más complejas, como podemos ver con el
método de control de los favoritos.
El mayor problema es
tener en cuenta que los
métodos que hacen
cambios en la base de
datos, necesitan una
autenticación específica.
También algunos
métodos que recogen
datos necesitan este tipo
de autenticación que me
da el header
Authorization.
Una vez hecho esto, sólo
tengo que transformar
los datos que quiero
enviar al servicio, en un
tipo JSON. En este caso
utilizo un objetoJSON
y un arrayJSON.
Controlo además que la
respuesta del servidor
sea correcta.
39
Interfaz gráfica La interfaz gráfica voy a hacerla de dos maneras, con activities y con fragments.
Técnicamente siempre uso activities pero quiero hacer dos clasificaciones.
Los activities son las “pantallas” de las que se compone una app. Tienen tanto su parte
de lógica, la clase, y la párte gráfica, el xml.
Los fragments son componentes que funcionan dentro de una activity y que nos
permiten mostrar varios en una sola activity con interacción entre ellos. Representan una
porción de la interfaz de usuario asociada a una activity.
Voy a tener 2 activities y tantos fragments como sean necesarios. Las 2 activities
comprenden la activity principal, que me permitirá acceder a todo el contenido, y la activity de
opciones, en la que incluiré el apartado de gestión de cuenta y lenguaje.
Todo el resto de la aplicación se gestionará mediante fragments. Es la única manera de
poder tener siempre el menú de favoritos a mano. Para ello, la disposición de los fragments
será la siguiente.
Fragment NavigationDrawer: Es el fragment que siempre estará cargado,
muestra el menú de favoritos.
ActivityMain: Permite la carga de todos los demás fragments. Este fragment es el
principal, contiene el fragment del menú lateral y un FrameLayout, que me permite cambiar el
contenido de la pantalla en cualquier momento.
Esta disposición me permite acceder al contenido sin tener que cambiar de actividad y sin
perder el menú lateral.
Para poder hacer funcionar este
método de los fragments,
desde la activity principal tengo
que controlar a dónde voy a ir.
Para ello tengo que poder
pasarle a cada uno de los
fragments el contenido que
necesiten.
Tengo que crear una función de este tipo por cada uno de los fragments que vaya a tener.
40
Seguimiento y control Planificado Total
Cliente Android, implementación de la base de datos 8 horas 9 horas
Cliente Android, implementación del diagrama de clases 20 horas 18 horas
Cliente Android, implementación de la interfaz gráfica 6 horas 6 horas
Documentación 6 horas 6 horas
Total 40 horas 40 horas
41
Sprint 7: Finalización del proyecto
En este Sprint acabo el proyecto. Según mi planificación general, debería invertir en
este sprint 20 horas. Como necesito más tiempo para terminar el proyecto, voy a replanificar
este sprint a 40 horas. Hasta aquí he invertido un poco más de 260 horas. El cómputo global de
horas prácticamente no se va a ver afectado porque actualmente he invertido algunas horas
menos de las planificadas.
Replanificación Finalización de la implementación de la interfaz gráfica 22 horas
Rendimiento de la aplicación 6 horas
Finalización de la documentación 12 horas
Total 40 horas
Layouts He creado un layout para cada
uno de los fragments que voy a utilizar.
Para hacerlos proporcionales a las
dimensiones del móvil, y que no se
vean mal en pantallas de distinto
tamaño a la de prueba, tengo que
utilizar porcentajes. En Android no se
puede hacer directamente, hay que
utilizar el peso (weight) de cada una de
las componentes.
En este caso, muestro parte del
layout del menú principal. Como se
puede ver, le estoy dando a los
componentes la altura o la anchura de
0. Esto lo hago para que tenga en
cuenta el peso como tamaño, y
dependiendo del peso me los haga más
grandes o más pequeños. Según el
peso que tengan, distribuye los
componentes. El peso es un valor
proporcional a su tamaño en pantalla
con respecto a los demás elementos.
En el ejemplo, que es un fragmento del código real, todos tienen el mismo peso
excepto el textView de abajo. En ese caso, el textView lo pondrá el tamaño de su contenido, y
42
el resto de componentes del layout las pondrá de un tamaño igual ya que todas pesan 1. Si
alguna pesase más de 1, esa componente sería más grande que las demás, tantas veces más
grande como el propio peso.
Todo esto, me permite que la interfaz gráfica se vea exactamente igual en cualquier
dispositivo Android.
La interfaz final del menú principal queda así:
43
ArrayAdapter Para que los layouts muestren en sus listas los datos que me interesan, tengo que
crear y modificar Adapters. Un adapter me permite “adaptar” un ListView para que muestre
imágenes u otro tipo de controles.
En varios layouts he necesitado crear ArrayAdapters.
Como se ve, el ArrayAdapter que creo para mostrar los datos de la
interfaceArticuloSeccion, contiene un TextView y un ImageView. Con esta
clase, le puedo dar el aspecto que quiera, y en el fragment, usarlo para la ListView.
Como se ve en la imagen superior, estoy utilizando una interfaz poco menos que llamativa:
interfaceArticuloSeccion. Pese a que desde el punto de vista de la lógica esta
interfaz no tenga sentido, me es necesaria para el uso en arrayList. Esta interfaz se
implementa en la clase Sección y Artículo. Tiene 3 métodos, getId, getNombre y
getTipo. getTipo devuelve el tipo de cada uno de los artículos y también, si es una
subsección me devuelve este valor. Esto me permite a la hora de cargar una imagen en el
Adapter, que la imagen sea personalizada dependiendo del tipo de la interfaz. Es una
aplicación del patrón Factoría.
44
Control del flujo de la aplicación Como ya he explicado en el sprint anterior, la aplicación va a gestionarse con métodos
públicos llamados desde el activityMain. Estos métodos permitirán acceder a todos los
fragments, y cargarán la información antes de acceder a ellos.
Pero a la hora de volver atrás, la aplicación debería recordar la selección de fragments
que he ido haciendo. Para eso, he implementado una pila que almacena el fragment en el que
estoy, y me permite desapilar a la hora de ir hacia atrás.
Este código no me es necesario a la hora de volver atrás con el activity de las opciones,
ya que el propio flujo de los activitys lo hace automáticamente.
45
Rendimiento de la aplicación Para que la aplicación Android funcione lo más fluida posible, he tenido que diseñarla y
hacer cambios que en otro tipo de aplicaciones serían perjudiciales. Suelen ser bastante
comunes este tipo de arreglos para una aplicación móvil.
Por ejemplo, en la base de datos, he creado un campo en la tabla artículos que me dice
el tipo de artículo que es cada uno. De esta manera me ahorro una operación bastante costosa
y la sustituyo por un dato bastante pequeño.
También, varios tipos de datos los he sustituido por enumeraciones. A la hora de
mostrar los tipos de artículos, en una enumeración aglutino su tipo y la imagen asociada.
El rendimiento con el fragment lateral también lo he revisado quitándole
transparencias y consiguiendo de esta manera que sea más fluido.
Seguimiento y control Planificado Total
Finalización de la implementación de la interfaz gráfica 22 horas 18 horas
Rendimiento de la aplicación 6 horas 4 horas
Finalización de la documentación 12 horas 12 horas
Total 40 horas 34 horas
Con este Sprint doy por finalizado el proyecto.
46
Conclusión Antes de explicar detenidamente las conclusiones de mi proyecto, voy a revisar cómo
he gestionado los tiempos dentro de la planificación general de mi proyecto. También voy a
hablar sobre la satisfacción de mi cliente.
Tiempos reales y planificados
Como está explicado en el diagrama de Gantt y en los sprints, he seguido siempre la
planificación general. Siempre que el Sprint ha sido más grande de lo planificado, lo he
terminado en el plazo, con una excepción. En el sprint 3, hubo un apartado planificado que no
me dió tiempo a realizar en el plazo. Este apartado fué integrado en el Sprint 4.
Creo que a la hora de seguir el proyecto he hecho bien en no dejar las cosas para el
siguiente sprint y acabarlo en el plazo. Pero esto tiene una desventaja, que a la hora de
adelantar trabajo, por seguir la planificación general, no lo he hecho. Es posible que en
proyectos futuros tenga menos en cuenta el calendario en esa segunda parte, ya que el tiempo
que gane adelantando trabajo nunca sabes cuándo te va a hacer falta.
Satisfacción del cliente Mi cliente ha quedado bastante satisfecho con el proyecto. Pese a ello, ya me ha
indicado mejoras y cambios que puedo realizar. El primer cambio es la interfaz del
administrador web.
Mi cliente ya sabía que iba a ser un prototipo, ya que su objetivo era la app Android.
Por eso, mi orientación a la hora de realizar el proyecto fue hacer una interfaz sin
complicaciones y que hiciese su trabajo.
Por eso mismo, el primer cambio va a ser esta interfaz.
47
El resto del proyecto, le ha gustado mucho. En especial, tanto el menú principal como
la opción de acceder a los artículos favoritos desde cualquier parte de la aplicación.
Conclusion final Este proyecto presentaba hasta tres partes muy diferenciadas. En las tres puedo decir
que he cumplido con los objetivos requeridos.
El uso de la metodología SCRUM me ha permitido avanzar rápidamente en el
desarrollo y a la vez corregir fallas de anteriores sprints. Al presentarle al cliente el
administrador web, ha permitido que de su confirmidad con el desarrollo hasta ese momento,
dando por bueno el diseño del servidor. Podría haber introducido cambios y hasta ese
momento no habrían sido demasiado costosos. Además, el realizar los servicios por partes me
ha dado la posibilidad de pensar con calma esa parte y de entender perfectamente el
funcionamiento del framework sin perder tiempo.
A la hora de la planificación, sí que han existido varios Sprints en los que he tenido una
variación significativa entre lo planificado y lo real. Pese a ello, he conseguido terminar el
proyecto según lo planificado.
Siempre es muy interesante aprender acerca de nuevas tecnologías y, pese a que la
mayoría de las que he utilizado ya las conocía, he podido profundizar en ellas. El uso de
fragments en Android o el uso de frameworks como SLIM son ejemplos de ello.
Por todo esto creo que ha sido un buen proyecto y además es un proyecto que puede
tener un futuro comercial.
48
Mejoras del proyecto Pese a que los objetivos del proyecto se han cumplido, siempre existen mejoras que se
pueden realizar en un futuro.
Interfaz gráfica: como ya he explicado, el primer cambio sería rehacer la interfaz
gráfica del administrador web. También se podría mejorar la del cliente Android.
Creación de un cliente Web: puede que sea la más necesaria, ya que algunos artículos
podrían ser demasiado grandes para leerlos cómodos en el móvil. Además, le daría más
sentido a la sincronización de los datos entre el cliente y el servidor.
Versión del cliente a Windows Phone y IOS: Android es la plataforma mayoritaria, pero
también sería una opción crear los clientes para estas dos plataformas. Se podría reutilizar la
gran mayoría de código excepto el que se encarga de la interfaz gráfica. Además, existen
herramientas que te hacen estas versiones automáticas sin apenas perder tiempo.
Funcionalidad en el Cliente Android: otra mejora sería el permitir comentarios y subida
de fotografías en el apartado de recetas o manualidades. Le daría un componente de
interacción entre usuarios muy interesante.
49
Bibliografía
Android Developers
http://developer.android.com/guide/index.html
StackOverflow
http://stackoverflow.com
SLIM
http://docs.slimframework.com/
PHP Documentation
http://php.net/manual/en/