Desarrollo e implementación de una solución completa para empresas de mensajería/paquetería utilizando dispositivos Android y la nube de dispositivos de Digi Autor/es
Rubén Moral Miera Director/es
Angel Luis Luis Rubio García García Facultad
Facultad de Ciencias, Estudios Agroalimentarios e Informática Titulación
Grado en Ingeniería Informática Departamento
Curso Académico
2012-2013
Desarrollo e implementación de una solución completa para empresas de mensajería/paquetería utilizando dispositivos Android y la nube de dispositivos de Digi, Digi, trabajo fin de grado de Rubén Moral Miera, dirigido por Angel Luis Rubio García (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.
El autor Univ Univer ersi sida dad d de La Rioj Rioja, a, Se Serv rvic icio io de Publ Public icac acio ione nes, s, 2013 2013 publicaciones.unirioja.es E-mail: [email protected]
GROALIMENTARIOS OS E INFORMÁTICA FACULTAD DE CIENCIAS, ESTUDIOS AGROALIMENTARI
TRABAJO DE FIN DE GRADO GRADO EN INGENIERÍA INFORMÁTICA
Desarrollo e implementación de una solución completa para empresas de mensajería/paquetería utilizando dispositivos Android y la nube de dispositivos de Digi – Aplicación Móvil Autor: D. Rubén Moral Miera
Director: D. Ángel Luis Rubio García
Departamento de Matemáticas y Computación Curso 2012/2013
II
Antes de comenzar quiero quiero dar las gracias a mi director, Ángel, por su dedicación, dedicación, su ayuda, sus consejos consejos y su colaboración a lo largo de estos últimos años.
III
Resumen Actualmente, existen multitud de empresas que ofrecen servicios de paquetería y mensajería urgente (Correos, Seur, FedEx, UPS, DHL…). Todas ellas operan a nivel nacional o internacional; sin embargo, existen muy pocas que trabajen en el ámbito de una ciudad y sus suburbios, donde en vez de utilizar el coche o la furgoneta para repartir los paquetes se use una bicicleta. La idea del proyecto, propuesto por la empresa Digi International Spain como parte de su oferta de prácticas para Grado, ha sido desarrollar un sistema destinado a este tipo de empresas pequeñas, donde con una bicicleta y un tablet baste para realizar todas las tareas de reparto. Palabras clave: sistema multiplataforma, servicios de paquetería, reparto en bicicleta.
Abstract Currently, there are many companies offering delivery and courier services (Correos, Seur, FedEx, UPS, DHL…). They all operate at national or international level; however, there are very few that work in the area of a city and its suburbs, where deliverers use a bicycle instead the car or van to deliver the packages. The idea of the project, proposed by the company Digi International Spain as part of their practices offered to Computer Engineering Degree, has been the development of a system intended for this kind of small companies, where with a bicycle and a tablet is enough to perform all delivery tasks. Keywords: cross-platform system, delivery services, bicycle messenger.
Estructura del proyecto .......................................................................................... 40
2.3.4.
Desarrollo de las aplicaciones .................................................................. ............... 42
Fase 1. Adaptación del código, incidencias y servicios y horas límite ............................... 42 Fase 2. Sincronización .............................................................................. .......................... 44 Fase 3. Creación de las interfaces de la nueva aplicación ................................................. 46
V
Fase 4. Funcionalidad de la aplicación para los clientes.................................................. .. 48 2.4.
Índice de figuras Figura 1. Arquitectura del sistema.................................................................. ................................ 8 Figura 2. Comparación entre tareas creadas y tareas resueltas. ...................................... ........... 13 Figura 3. Diagrama de estados de las tareas. ............................................................................... 15 Figura 4. Diagrama de casos de uso para la aplicación de repartidores. ..................................... 19 Figura 5. Diagrama de casos de uso para la aplicación de clientes. ............................................. 21 Figura 6. Diagrama de actividad del caso de uso [Localizar pedido]. ........................................... 23 Figura 7. Diagrama de actividad del caso de uso [Crear nuevo pedido]. ..................................... 25 Figura 8. Diagrama de actividad del caso de uso [Iniciar sesión]. ................................................ 27 Figura 9. Interfaces al comienzo del proyecto. .................................................................... ......... 28 Figura 10. Evolución de la pantalla de inicio................................................................................. 29 Figura 11. Evolución de la pantalla de detalles de la tarea. ....................................................... .. 29 Figura 12. Pantalla inicial. ............................................................................................................. 30 Figura 13. Pantalla del primer paso de nuevo pedido. ................................................................. 31 Figura 14. Arquitectura en capas y niveles. .................................................................................. 33 Figura 15. Diagrama de paquetes. .......................................................................... ...................... 36 Figura 16. Diagrama de clases del modelo de objetos. ................................................................ 36 Figura 17. Diagrama de clases de la capa de lógica de negocio. .................................................. 37 Figura 18. Diagrama de clases de la capa de persistencia................................................ ............ 37 Figura 19. Diferencia entre Java VM y Dalvik VM. .............................................. .......................... 39 Figura 20. Contenido de la carpeta /src. ......................................................................... .............. 41 Figura 21. Contenido de /res. ....................................................................................................... 41 Figura 22. Excepción que aparecía al arrancar la aplicación. ..................................... .................. 42 Figura 23. Implicaciones de ambos modos de conexión. ............................................................. 45 Figura 24. Estructura de los layouts de la aplicación.................................................... ................ 46 Figura 25. Comparación de ambas vistas. ................................................ .................................... 49 Figura 26. Vista de las direcciones almacenadas y la información de la empresa. ...................... 51
Capítulo 1. Introducción La presente memoria trata de recoger los aspectos más importantes del trabajo realizado por Rubén Moral en el proyecto “Desarrollo e implementación de una solución completa para empresas de mensa jería/paquetería utilizando dispositivos Android y la nube de dispositivos de Digi – Aplicación Android ”, realizado en el ámbito de la empresa Digi International Spain S.A.U.
1.1. Antecedentes Durante los últimos años y gracias a la expansión de Internet, cada vez más personas en el mundo realizan sus compras a través de la red. Debido a este hecho, las empresas de paquetería y servicio urgente están proliferando, ya que son una de las bases del comercio electrónico. La mayoría de ellas operan a nivel nacional o internacional; sin embargo, existen muy pocas que trabajen en el ámbito de una ciudad y sus suburbios, donde en vez de utilizar el coche o la furgoneta para repartir los paquetes se use una bicicleta. Por otra parte, las tecnologías móviles también crecen rápidamente. Los nuevos teléfonos inteligentes (conocidos como smartphones) son capaces de realizar actividades semejantes a las que se pueden hacer con un ordenador a muy bajo coste, con la ventaja de la gran movilidad que permiten. La idea de este proyecto ha sido unir los dos hechos anteriores, es decir, desarrollar un sistema que permita a pequeñas empresas de paquetería realizar todas las funciones necesarias sin necesidad de contar con herramientas complejas, simplemente con un smartphone o un tablet . El proyecto en sí empezó a realizarse en septiembre de 2012, en el periodo de Prácticas I. Puesto que su tamaño era demasiado grande, ya que no solo incluía la aplicación Android sino también la creación de un portal web para clientes y administradores, se decidió dividirlo en dos componentes: Web y Android1, cada una de ellas desarrollada por un alumno de prácticas. El proyectante escogió la segunda parte, ya que sentía curiosidad por algo en lo que no había desarrollado nunca. El proyecto se planificó para ser realizado desde septiembre de 2012 hasta mayo de 2013, englobando las asignaturas de Prácticas I, Prácticas II y Trabajo de Fin de Grado.
SOBRE DIGI
Digi International es una empresa norteamericana centrada en la industria del hardware. Combina productos y servicios M2M (Máquina a Máquina) para gestionar de manera eficiente las empresas. Entre 1
La componente Web está formada por la aplicación web para el personal de administración de la empresa y el portal para los clientes. Mientras, la componente Android engloba la aplicación destinada a los trabajadores de la empresa y la aplicación para los clientes.
7
INTRODUCCIÓN
Antecedentes
sus productos más importantes destacan: sistemas embebidos, conectividad inalámbrica, Zero-Clients, servidores de consola, video/sensores y conectividad serie y USB. Digi además posee una nube pública para la gestión de redes de dispositivos, Etherios Device Cloud . Proporciona mensajería segura entre aplicaciones, almacenamiento de datos y gestión de dispositivos para redes cableadas y dispositivos celulares. Una red de dispositivos, también referidas en ocasiones como M2M, permite que sistemas cableados o inalámbricos se comuniquen con otros dispositivos o aplicaciones a través de diferentes tipos de red. Por ejemplo, un dispositivo (como un sensor) captura un evento (como un cambio de temperatura) y lo envía a tr avés de una red a una aplicación, que lo traduce en información útil (como una alerta por cambio de temperatura). Gracias a este proyecto Digi podrá demostrar, a través de una aplicación real, las características y la multitud de posibilidades que ofrece su nube de dispositivos, pudiendo llevar a cabo cantidad de proyectos que hagan uso de ella.
*** En el caso que nos ocupa, la red está compuesta por dispositivos Android, que se conectan a la nube a través del Cloud Connector for Android (conjunto de librerías, plug-ins y herramientas diseñadas para facilitar el desarrollo de aplicaciones Etherios en dispositivos Android). Cada repartidor de la empresa de paquetería posee un dispositivo Android (bien un smartphone o bien un tablet ), que tiene instalada la aplicación desarrollada y el Cloud Connector for Android . La aplicación sube archivos a la nube y llama a servicios web del servidor para gestionar todas las tareas requeridas. En la Figura 1 se puede observar la arquitectura global del sistema completo.
Figura 1. Arquitectura del sistema.
8
INTRODUCCIÓN
Objetivos
El funcionamiento del sistema es el siguiente: cuando un cliente acceda al portal web o a su aplicación Android y solicite un envío, se generará en el servidor una tarea, que se asignará de forma automática al repartidor adecuado (según su posición y la carga de tareas en ese instante). La aplicación de este recibirá dicha tarea, que contendrá la información necesaria para poder ser llevada a cabo. Todos los cambios, tanto en el estado de la tarea como en la posición donde se encuentre el repartidor, serán actualizados en el servidor en el momento en que se produzcan. La tarea finalizará cuando el paquete se entregue al destinatario y firme en el dispositivo la recogida. Esta firma se digitalizará y se incluirá en la factura que se le envíe al cliente. La Device Cloud de Etherios permite el almacenamiento de datos en la nube (fichero con la localización de los trabajadores, firmas digitalizadas de los clientes…), la comunicación bidireccional entre ambas aplicaciones y el envío de notificaciones dese el servidor a la aplicación móvil. Durante los periodos de Prácticas I y Prácticas II (de septiembre a diciembre de 2012), el proyectante comenzó a diseñar el sistema, aprendiendo primero los fundamentos básicos de Android, y empezando más tarde a desarrollar la aplicación destinada a los trabajadores de la empresa de paquetería. Se definieron los tipos de tarea (envío y recogida) y se implementaron las actividades para mostrar tareas, para interactuar con ellas, para recibir mensajes de la empresa y para mostrar el perfil del trabajador. Se creó también un servicio de localización en tiempo real, una actividad para trazar rutas entre la posición del trabajador y el destino, una actividad para recoger la firma del usuario a la hora de entregar el paquete y una actividad para asociar un código QR a una tarea. La aplicación anteriormente mencionada está destinada a los trabajadores de la empresa, es decir, a los repartidores. Por otro lado, existe otra aplicación, esta para los clientes, a través de la cual pueden realizar un pedido, hacer el seguimiento del mismo o ver el historial de pedidos. De este modo, las tareas para este trabajo han sido terminar y re-implementar la aplicación para los repartidores (puesto que desde la empresa se dio libertad a la hora de desarrollarla y no se siguieron estrictamente las fases de desarrollo de software) y realizar la aplicación para los clientes siguiendo la metodología Scrum.
1.2. Objetivos El objetivo general de este proyecto es desarrollar un sistema completo y fácil de usar que se encargue de la logística necesaria para el buen funcionamiento de una empresa de paquetería a pequeña escala. Otros objetivos también importantes, relativos al sistema global, son:
Comunicación bidireccional entre las dos plataformas (Web y Android), ya sea directamente entre ellas o a través de la nube de dispositivos. Demostración del funcionamiento del sistema completo al personal de la empresa Digi.
9
INTRODUCCIÓN
Planificación
Comprobación del correcto funcionamiento del sistema mediante la realización de tests, llevados a cabo por los dos alumnos y por el equipo de test de la empresa Digi. Realización de un vídeo promocional, donde se expliquen las principales características del sistema.
Por otro lado, los objetivos específicos de la plataforma Android son:
Terminar y mejorar determinados aspectos de la aplicación para los trabajadores. Diseñar e implementar una aplicación con la que cualquier cliente pueda: realizar un pedido, hacer el seguimiento del mismo y ver el histórico de pedidos. Las aplicaciones deben tener una interfaz de usuario intuitiva y fácil de usar, tanto para los trabajadores como para los clientes. Las aplicaciones deben estar realizadas para dispositivos que tengan al menos la versión 2.3.3, Gingebread, según los datos que se muestran en el primer informe de 20132. Las aplicaciones se deben ajustar a pantallas de entre 3,2 y 7 pulgadas, bien sean smartphones o tablets.
1.3. Planificación Como se ha comentado anteriormente, el sistema se empezó a diseñar en septiembre de 2012, ya que el proyecto estaba pensado para ser realizado en ocho meses. Aunque la frontera entre qué corresponde a Prácticas externas y qué al Trabajo de Fin de Grado es algo difusa, este último comenzó a desarrollarse el 21 de enero de 2013, fecha en la que comenzó el segundo cuatrimestre. En la siguiente lista se muestra la descomposición de tareas del proyecto: 1. Gestión del proyecto, 57 horas. a. Reuniones con el tutor y la empresa (22 horas). Cada último martes de mes, a partir del mes de enero, tendrá lugar una reunión en la Universidad con el tutor Ángel Luis Rubio para ir mostrándole el avance del proyecto. También habrá una reunión con la empresa cada miércoles de las semanas pares, con el mismo objetivo. b. Creación de los objetivos y redacción de la introducción (10 horas). Durante las dos primeras semanas se confeccionarán los objetivos que deberá cumplir la aplicación para los clientes. También se redactará el resumen y la introducción de la memoria. c. Elaboración de la memoria (25 horas).
2
El primer informe de 2013 realizado por Google indica que el 88,2% de los dispositivos Android utilizan como mínimo la versión 2.3.3 (API Level 10). Es la versión más utilizada a esa fecha (47,4%), seguida por la 4.0.3 (29,1%).
10
INTRODUCCIÓN
Seguimiento del proyecto
2. Aplicación para los repartidores, 46 horas. a. Análisis (4 horas). Se analizará la situación de la aplicación realizada en el periodo de Prácticas y se establecerán una serie de directrices para la finalización de dicha aplicación. b. Diseño (4 horas). Se establecerán unos criterios para realizar el cambio en las interfaces de la aplicación. c. Implementación (35 horas). Se construirán los tres módulos restantes: incidencias, servicios y horas límite y sincronización. d. Pruebas (3 horas). Se realizarán pruebas unitarias de los módulos construidos y pruebas de integración. 3. Aplicación para los clientes, 192 horas . a. Análisis (15 horas). Se identificarán los participantes del sistema, se establecerá el catálogo de requisitos y se crearán los diagramas de casos de uso. b. Diseño (30 horas). Se elaborarán los prototipos de la nueva aplicación, se establecerá cómo deben almacenarse los datos, se creará el diagrama d e clases y se diseñará el plan de pruebas. c. Implementación (144 horas). Se crearán las interfaces de usuario y se construirán las clases de las tres capas de la aplicación. d. Pruebas (3 horas). Se realizarán pruebas unitarias de los módulos construidos y pruebas de integración. 4. Material promocional del sistema completo, 5 horas . a. Elaboración del vídeo (5 horas). Se creará un vídeo promocional del sistema, donde se expongan todas las características del mismo.
Duración total ESTIMADA: 300 horas
1.4. Seguimiento del proyecto El seguimiento del proyecto se ha realizado a través del software JIRA. Es una aplicación basada en web para el seguimiento de errores, de incidencias y para la gestión operativa de proyectos. Además, permite utilizar metodologías ágiles como Scrum (la que fue elegida para llevar a cabo este proyecto). La principal característica de Scrum es que es un proceso iterativo e incremental. Sin embargo, para este proyecto no se han seguido rigurosamente los principios y recomendaciones de Scrum, sino que esta metodología solo se ha tomado como base de la gestión.
11
INTRODUCCIÓN
Seguimiento del proyecto
Los roles para este proyecto se dividieron de la siguiente manera:
ScrumMaster (director del proyecto): Diego Escalona (desarrollador en Digi). ProductOwner (dueño del producto): Pedro Pérez (responsable de Digi International Spain). Team (equipo de trabajo): César Estebas y Rubén Moral.
La implementación del proyecto comenzó el 25 de febrero. Durante los dos primeros días se estableció la pila del producto y las características de los sprints. Se decidió que estos tuviesen una duración de 2 semanas, iniciándose los miércoles (coincidiendo con la reunión bisemanal en la empresa). A continuación se muestra una breve descripción del desarrollo del proyecto por cada sprint:
Primer sprint (27/02/13 – 13/03/13), 19 horas:
Segundo sprint (13/03/13 – 27/03/13), 22 horas:
Diseño del layout para la sincronización. Implementación de la sincronización offline. Internacionalización. Test de funcionalidad. Prueba de la aplicación en varios dispositivos.
Tercer sprint (27/03/13 – 10/04/13), 40 horas:
Adaptación del código a la versión 4.x de Android. Cambio en el diseño de las interfaces. Arreglo de bugs encontrados. Implementación del sistema de notificación de incidencias. Implementación de los tipos de servicios. Implementación de las horas límite. Modificación de la lista de tareas para mostrar primero las prioritarias.
Diseño del layout para la pantalla de inicio. Diseño del layout para la pantalla de login. Diseño del layout para la pantalla de “Seguimiento de un pedido”. Diseño del layout para la pantalla de “Mis pedidos”. Diseño del layout para la pantalla de “Nuevo pedido”.
Cuarto sprint (10/04/13 – 24/04/13), 82 horas:
-
Implementación de la pantalla de inicio. Implementación de la pantalla de login. Implementación de la pantalla de “Seguimiento de un pedido”. Implementación de la pantalla de “Mis pedidos”. Implementación de la pantalla de “Nuevo pedido”.
12
INTRODUCCIÓN
Seguimiento del proyecto
Internacionalización. Test de funcionalidad. Pruebas en varios dispositivos.
Quinto sprint (24/04/13 – 8/05/13), 18 horas:
-
Vídeo corporativo. Prueba global del sistema.
Figura 2. Comparación entre tareas creadas y tareas resueltas.
Las estimaciones iniciales no fueron del todo exactas, puesto que el tiempo total de dedicación al proyecto ha sido un 2% superior al estimado. A continuación se puede observar las desviaciones en cada apartado del proyecto: Tarea Gestión del proyecto
+5 en Creación de los objetivos Aplicación para los repartidores
+3 en Implementación
Horas estimadas
Horas reales
Desviación
57
62
+5 h.
46
49
+3 h.
192
181
-11 h.
5
15
+10 h.
300
307
+7 h.
Aplicación para los clientes
+8 en Análisis +6 en Diseño -25 en Implementación Material promocional TOTAL
13
Capítulo 2. Desarrollo 2.1. Análisis Esta especificación tiene como objetivo analizar y documentar las necesidades funcionales que deberán ser soportadas por el sistema a desarrollar. Para ello, se identificarán los requisitos que ha de satisfacer el nuevo sistema mediante el estudio de los problemas de las unidades afectadas y sus necesidades actuales. Además de identificar los requisitos se deberán establecer las prioridades, lo cual proporciona un punto de referencia para validar el sistema final que compruebe que se ajusta a las necesidades del usuario.
2.1.1. Identificación de los usuarios participantes Los objetivos de esta tarea son identificar a los responsables de cada una de las unidades y a los principales usuarios implicados. En la organización se identificaron los siguientes usuarios:
Clientes finales: Son aquellos a los que va dirigido el servicio de reparto. Pueden realizar un pe-
dido a través del portal web o de la aplicación móvil que se desarrollará en este trabajo. Repartidores: Son los encargados de realizar las tareas de recogida y entrega de paquetes. A ellos va destinada la aplicación desarrollada en el periodo de Prácticas. Personal de administración : Son los que trabajan en la sede de la empresa y controlan las asignaciones de tareas y la posición de los repartidores.
2.1.2. Catálogo de requisitos del sistema i.
Definiciones, acrónimos y abreviaturas
Tarea: Unidad básica de trabajo. Es creada a petición de un usuario, y contiene la siguiente información: identificador, tipo, estado, datos del emisor, datos del receptor y detalles. En el ámbito de los clientes, tarea es sinónimo de pedido. Estado: Situación en que se encuentra una tarea en un momento determinado. Existen un total de 7 estados, que son los siguientes:
New (nueva): La tarea ha sido creada pero aún no se ha iniciado. Pickup in progress (recogida en progreso): La tarea está siendo realizada; el repartidor va en camino hacia el cliente para recoger el paquete. Delivery in progress (entrega en progreso): La tarea está siendo realizada; el repartidor va en camino hacia el cliente para entregar el paquete.
14
DESARROLLO
Análisis
Paused (pausada): La tarea había sido iniciada pero se ha parado. La causa de este hecho es bien porque el repartidor ha iniciado otra tarea o porque el paquete no debe entregarse en el día de recogida y se ha guardado en el almacén. Finished (finalizada): El paquete ha sido entregado y la tarea se ha completado con éxito. Incidence (incidencia): La tarea no ha podido finalizarse correctamente debido a una incidencia. Canceled (cancelada): La tarea ha sido cancelada.
Figura 3. Diagrama de estados de las tareas.
Tipo: Clase de una tarea, que engloba a una serie de estados. Toda tarea, a lo largo de su vida, necesariamente tiene que tener los siguientes tipos:
Pickup (recogida): Acción en la que el repartidor recoge un paquete de un cliente. Delivery (entrega): Acción en la que el repartidor entrega un paquete a un cliente.
Tipo de servicio: Está asociado a la urgencia que tiene una tarea. Es elegido por el cliente a la hora de crear el pedido. Existen 4 tipos, ordenados de mayor a menor urgencia/coste:
2 horas: El paquete se entregará antes de 2 horas a contar desde el instante de la creación del pedido. 6 horas: El paquete se entregará antes de 6 horas a contar desde el instante de la creación del pedido. Madrugador: El paquete se entregará antes de las 20 horas del día en el que se haya creado. Siguiente día: El paquete se entregará antes de las 14 horas del día siguiente al de creación.
Hora límite: Fecha y hora máxima que tiene un repartidor para finalizar la tarea y entregar el paquete. Se calcula en base al tipo de servicio contratado por el cliente.
15
DESARROLLO
Análisis
Número de seguimiento: Código único asociado a una tarea que permite al cliente visualizar el estado del pedido.
ii.
Descripción general
Esta sección nos presenta una descripción general del sistema con el fin de conocer las funciones que debe soportar, los datos asociados, las restricciones impuestas y cualquier otro factor que pueda influir en la construcción del mismo. Las funciones que debe realizar el sistema se pueden agrupar de la siguiente manera:
Seguimiento de un pedido : La aplicación permitirá que el usuario pueda ver dónde y en
qué estado se encuentra su pedido, a través del número de seguimiento generado a la hora de crearlo.
Historial de pedidos : La aplicación permitirá que el usuario pueda ver una lista con todos
los pedidos creados hasta ese momento. Permitirá acceder a cada uno de ellos y ver todos sus detalles.
Realización de pedidos: La aplicación permitirá que el usuario cree un nuevo pedido. Este
deberá introducir sus datos si todavía no está registrado, así como los del emisor y el receptor del paquete. También deberá seleccionar el tipo de servicio y el método de pago. iii.
Requisitos funcionales
En esta sección se listan los requisitos funcionales de las aplicaciones. Los siguientes corresponden con los requisitos restantes de la aplicación para repartidores: A. Incidencias. Debe ser posible que el repartidor pueda notificar una incidencia o una cancelación si ocurre algún problema en el transcurso del proceso. Es posible que cuando vaya a entregar un paquete no haya nadie en el hogar de destino, o la dirección sea incorrecta. Por ello, se le facilitará una lista con una serie de incidencias predefinidas, aunque también se permitirá que él mismo redacte una. B. Servicios y horas límite. La lista de tareas del repartidor estará ordenada según el tipo de servicio y la hora límite. Hasta ahora, las tareas estaban ordenadas según su fecha de creación. Cuando la aplicación recibía una tarea nueva, la insertaba al final de la lista. Sin embargo, algunas tareas son más urgentes que otras (para ello el cliente paga más si quiere que su paquete llegue al destino a las dos horas en vez de al día siguiente). Por lo tanto, todas las tareas deberán contener el tipo de servicio y la hora límite de entrega, de modo que cuando vayan llegando nuevas tareas a la aplicación se ordenen según esos pará metros.
16
DESARROLLO
Análisis
C. Sincronización offline. Será posible que el trabajador pueda seguir usando la aplicación en zonas donde no haya 3G o WiFi. Cada vez que se produce un cambio en alguna tarea (inicio de la tarea, cambio de estado, firma del cliente), la aplicación comunica dicho cambio al servidor, por lo que es necesario que tenga conexión a Internet. De este modo, se permitirá que el repartidor llegue a lugares donde no haya cobertura (puesto que generalmente estará conectado a la red a través de 3G). La aplicación guardará todos los cambios en la memoria del dispositivo y los actualizará en el servidor w eb cuando se vuelva a conectar a Internet.
A continuación se enumeran los requisitos de la aplicación para clientes a realizar en este trabajo, ordenados de mayor a menor importancia: A. Seguimiento de un pedido. Será posible que el usuario pueda localizar un pedido en curso, bien introduciendo el número de seguimiento o escaneando un código QR. La aplicación mostrará todos los detalles del pedido asociado a ese código, así como una tabla donde se muestren los estados por los que ha ido pasando. Si el usuario está autenticado, no hará falta que introduzca el número de seguimiento, puesto que se mostrará una lista con todos los pedidos en curso que disponga en ese instante. B. Autenticación. Debe existir la posibilidad de que el usuario se autentique antes de realizar cualquier operación. Esta función sirve para evitar que usuarios registrados tengan que introducir sus datos constantemente cada vez que realicen una operación. El sistema mostrará el formulario de acceso y realizará la autenticación. Una vez hecha, mantendrá la sesión abierta hasta que el usuario la cierre manualmente. C. Creación de un nuevo pedido. Debe ser posible que cualquier usuario pueda crear un nuevo pedido. El sistema mostrará un formulario para que este introduzca los datos de origen, de destino y el tipo de servicio. Una vez que acepte el pedido, si no se ha autenticado antes, el sistema abrirá el formulario de acceso. Tras iniciar sesión, se mostrará un resumen con los datos del pedido para que el cliente lo confirme. D. Historial de pedidos. El usuario podrá ver un listado con sus pedidos realizados. Una vez que se haya autenticado, el usuario podrá ver una tabla con todos los pedidos que haya realizado hasta ese momento, incluyendo tanto los finalizados como los que estén en progreso. Clicando sobre cada uno de ellos podrá acceder a la información concreta de ese pedido.
17
DESARROLLO
iv.
Análisis
Requisitos de usuario y tecnológicos
Requisitos de usuario: Existen dos tipos de usuario que van a hacer uso de estas aplicaciones: empleados de la empresa y clientes. Ambas interfaces deben ser intuitivas, fáciles de usar y amigables. El funcionamiento de la aplicación para los repartidores es más complejo, por lo que requerirá un manual de usuario detallado; sin embargo, la aplicación de los clientes está destinada a un mayor número de usuarios, con distintas habilidades y conocimientos, por lo que debe ser más intuitiva y debe cumplir los estándares de accesibilidad y usabilidad. Requisitos tecnológicos:
v.
vi.
Las aplicaciones están destinadas a smartphones o tablets Android, con una pantalla de entre 3,2’’ y 7’’, que tengan la versión 2.3.3 o superior. Los dispositivos deberán tener cámara de fotos y conexión a Internet a través de 3G. Sería recomendable que también tuvieran GPS integrado. El sistema deberá adaptarse a la gran variedad de dispositivos móviles existentes. Más concretamente deberá tener en cuenta el área de presentación y adaptar las visualizaciones para aprovechar al máximo el tamaño disponible. El ancho de banda desde dispositivos móviles suele ser bastante reducido, por lo que hay que controlar no saturar con contenidos demasiado pesados que influyan en el tiempo de respuesta de la aplicación. Las aplicaciones se ejecutarán sobre un esquema cliente/servidor, con los procesos e interfaz de usuario ejecutándose en los clientes y estos solicitando requerimientos al servidor que cumple su proceso. Requisitos de interfaces externas
Interfaces de usuario: La interfaz de usuario de la aplicación de clientes debe ser similar a la del portal web (en cuanto a diseño y colores). Interfaces hardware: Smartphone o tablet Android. Requisitos de rendimiento
El tiempo de respuesta de la aplicación a cada función solicitada por el usuario no debe ser superior a 5 segundos, exceptuando la función de “crear un nuevo pedido”, donde se podrá demorar como máximo hasta 10 segundos.
18
DESARROLLO
vii.
Análisis
Requisitos de desarrollo y restricciones de diseño.
El marco de trabajo de desarrollo de software elegido para este proyecto es Scrum, cuya característica principal es que es un proceso iterativo e incremental. Para controlar los sprints y realizar la gestión operativa del proyecto se utilizará JIRA. En cuanto a las restricciones de diseño, los códigos QR deberán seguir el estándar ISO/IEC 18004:2006, y contendrán una cadena de texto referente al número de seguimiento.
2.1.3. Casos de uso En esta sección se especificarán los casos de uso más relevantes en el sistema. El resto están incluidos en el Anexo 1 (Casos de uso). A continuación se muestra el diagrama de casos de uso de la aplicación para los repartidores, junto con la especificación de los dos casos de uso que restan por i mplementar en el sistema.
Figura 4. Diagrama de casos de uso para la aplicación d e repartidores.
19
DESARROLLO
Análisis
Caso de uso
Sincronizar
Descripción
Actualizar en el servidor todos los cambios que se hayan producido en el dispositivo cuando no estaba conectado a Internet.
Actores
Repartidor.
Precondiciones
El dispositivo debe estar conectado a Internet.
Postcondiciones
Todos los cambios almacenados offline en el dispositivo son sincronizados en el servidor correctamente.
Flujo básico
1. 2. 3.
El repartidor pulsa el botón de sincronizar. El sistema se conecta con el servidor y actualiza los cambios. El sistema sube las firmas digitalizadas a la nube.
Flujos alternativos y excepciones
No hay. Anotaciones
No hay.
Caso de uso
Notificar incidencia
Descripción
Reportar una incidencia al servidor para que el personal de administración pueda gestionarla.
Actores
Repartidor.
Precondiciones
El repartidor debe estar en [Ver detalles de tarea].
Postcondiciones
La incidencia es notificada correctamente.
Flujo básico
1. 2. 3.
El repartidor pulsa el botón de incidencia. El sistema muestra un diálogo con una lista de las incidencias más habituales y un campo de texto. El repartidor selecciona una incidencia de las de la lista o escribe una personalizada en el campo de texto, y pulsa “Enviar”.
Flujos alternativos y excepciones
No hay. Anotaciones
No hay.
20
DESARROLLO
Análisis
Por otra parte, el siguiente diagrama muestra los casos de uso de la aplicación para los clientes. Se incluyen también la especificación de los casos de uso más relevantes junto con los diagramas de actividad.
Figura 5. Diagrama de casos de uso para la aplicación de clientes.
21
DESARROLLO
Análisis
Caso de uso
Localizar pedido
Descripción
Localizar un pedido en curso introduciendo su número de seguimiento o escaneando su código QR.
Actores
Cliente.
Precondiciones
No hay.
Postcondiciones
Se muestra un resumen del pedido a localizar.
Flujo básico
1. 2. 3. 4.
El cliente elige la opción “Localizar pedido” en la pantalla inicial. El sistema muestra: un cuadro de texto para introducir el número de seguimiento, un icono con una cámara y un botón de Buscar. El cliente introduce el número de seguimiento y pulsa Buscar. El sistema muestra un resumen del pedido que corresponde con el número de seguimiento introducido.
Flujos alternativos y excepciones
Si el cliente está autenticado en el sistema, tras el punto 1 se mostrará directamente un resumen con los pedidos en curso de dicho usuario. En el punto 3, el cliente puede llevar a cabo [Escanear código QR] en vez de introducir el número de seguimiento. Tras el punto 4, el cliente puede pulsar sobre el pedido e ir a [Ver detalle pedido]. Si el número de seguimiento o el código QR no se corresponde con ningún pedido se avisa al cliente del error. Anotaciones
Para escanear un código QR en vez de introducir el número de seguimiento, el cliente deberá pulsar sobre el icono de la cámara.
22
DESARROLLO
Análisis
Figura 6. Diagrama de actividad del caso de uso [Localizar pedido].
23
DESARROLLO
Análisis
Caso de uso
Crear nuevo pedido
Descripción
Crear un pedido nuevo para que sea llevado a cabo por la empresa de paquetería en el tiempo establecido.
Actores
Cliente.
Precondiciones
No hay.
Postcondiciones
El pedido se crea correctamente.
Flujo básico
1. 2. 3.
4. 5.
El cliente elige la opción “Nuevo pedido” en la pantalla inicial. El sistema muestra un formulario con los datos requeridos. El cliente rellena el formulario, con al menos los siguientes campos: datos de quien envía el paquete, datos de quien lo recibe, tipo de servicio y método de pago. Luego pulsa en “Continuar”. El sistema comprueba si el cliente está autenticado en el sistema. El usuario confirma el pedido.
Flujos alternativos y excepciones
En el punto 4, si el cliente no ha iniciado sesión se lleva a cabo [ Iniciar sesión]. Hasta que el cliente no confirme el pedido en el punto 5, puede cancelarlo en cualquier momento. Anotaciones
No hay.
24
DESARROLLO
Análisis
Figura 7. Diagrama de actividad del caso de uso [ Crear nuevo pedido].
25
DESARROLLO
Análisis
Caso de uso
Iniciar sesión
Descripción
Autenticarse en el sistema con nombre de usuario y contraseña.
Actores
Cliente.
Precondiciones
No hay.
Postcondiciones
La sesión del cliente queda abierta en el sistema hasta que este la cierre.
Flujo básico
1. 2. 3.
El cliente elige la opción “Iniciar sesión” en la pantalla inicial. El sistema muestra un formulario con dos campos: nombre de usuario y contraseña. El cliente introduce sus datos y pulsa sobre el botón de Iniciar sesión.
Flujos alternativos y excepciones
No siempre se accede a este caso a través del punto 1, sino que se puede llegar desde [Ver historial de pedidos] o [Crear nuevo pedido]. Si el nombre de usuario o la contraseña no son correctos se avisará al usuario a través de un mensaje de error. Anotaciones
No hay.
26
DESARROLLO
Análisis
Figura 8. Diagrama de actividad del caso de uso [Iniciar sesión].
27
DESARROLLO
Diseño
2.2. Diseño En el siguiente apartado se enumeran las decisiones tomadas a lo largo de este proyecto con respecto al diseño de las interfaces de usuario, a la arquitectura del sistema y al almacenamiento de los datos.
2.2.1. Diseño de la interfaz de usuario 1. Aplicación para los trabajadores . Como se ha mencionado anteriormente, al comienzo de este proyecto la aplicación destinada a los repartidores de la empresa de paquetería estaba casi finalizada. Sin embargo, el diseño de la misma no era el adecuado, puesto que las exigencias de la empresa en el periodo de prácticas se habían dirigido más hacia el funcionamiento y no tanto al diseño.
Figura 9. Interfaces al comienzo del proyecto.
Las decisiones tomadas respecto a la interfaz de esta aplicación fueron las siguientes:
Cambiar el contraste general, pasando del fondo negro al blanco o gris claro. Cambiar la barra de título predeterminada de Android por una personalizada, donde apareciera el nombre de la aplicación y el logotipo. Cambiar los iconos del menú por otros más significativos. Adaptar correctamente la aplicación a pantallas de alta resolución, especialmente en tablets, puesto que hasta el momento no se había gestionado la resolución de las pantallas.
28
DESARROLLO
Diseño
Establecer una paleta de colores para la aplicación. Inicialmente se planteó una paleta de naran jas, pero en una de las últimas revisiones en la empresa se decidió cambiarla junto con los colores de la página web a una paleta de verdes, como se puede apreciar en la Figura 10 y en la Figura 11.
Figura 10. Evolución de la pantalla de inicio.
Figura 11. Evolución de la pantalla de detalles de la tarea.
29
DESARROLLO
Diseño
2. Aplicación para los clientes . En este caso, al partir de cero, había que diseñar unos prototipos que se aproximasen a cómo iba a ser la aplicación una vez finalizada, con el objetivo de realizar los cambios oportunos en la fase de diseño y no en la de implementación. A continuación se muestran los primeros prototipos realizados. Por similitud no se muestran todos, el resto aparecen en el Anexo 2 (Mockups).
Figura 12. Pantalla inicial.
Esta es la pantalla que aparece al iniciarse la aplicación. A través de los botones se puede acceder a las tres funciones principales: seguimiento, histórico y nuevo pedido. Mediante el menú, el usuario puede loguearse y ver la información de la empresa de paquetería.
30
DESARROLLO
Diseño
Figura 13. Pantalla del primer paso de nuevo pedido.
Cuando el usuario comience un nuevo pedido verá esta pantalla. El proceso de realización de un nuevo pedido se ha dividido en tres pasos:
Datos personales: el usuario deberá introducir los datos del remitente y del receptor del paquete. Pago: el usuario elegirá el tipo de servicio y el método de pago. Revisión y finalización: el sistema mostrará un resumen con todos los datos que ha introducido el usuario, para que este los revise y decida si finalizar el pedido o cancelarlo.
En el siguiente punto se mostrará el diagrama de navegación de la aplicación para los clientes.
31
DESARROLLO
Diseño
2.2.2. Diagrama de navegación
Menu -> About us
Order tracking
Order tracking (logged)
Menu -> Login
Order history
New order
Order details
Next step
Full details
Next step
32
DESARROLLO
Diseño
2.2.3. Arquitectura del sistema Las aplicaciones desarrolladas poseen una arquitectura de tres capas y dos niveles (cliente/servidor), ya que algunos procesos de negocio y gran parte de los datos provienen del servidor web y de la base de datos almacenada allí.
Figura 14. Arquitectura en capas y niveles.
La capa de presentación es la encargada de interactuar con los usuarios de la aplicación. Está conformada por múltiples archivos XML, uno por cada vista de la aplicación. La capa de lógica de negocio se encarga de realizar los procesos de la aplicación. Hace de nexo entre la capa de presentación y la de persistencia. La función de la capa de persistencia es acceder a los datos almacenados para consultarlos o modificarlos. El almacenamiento de datos está especificado en la sección 2.2.4.
2.2.4. Almacenamiento de datos Al ser este un sistema distribuido, los datos se almacenan en tres ubicaciones distintas: 1. Base de datos del servidor . Aquí se almacena la mayor parte de la información del sistema, incluyendo tareas, trabajadores y clientes. Cada vez que cualquiera de las aplicaciones Android necesita obtener o actualizar un determinado dato, utiliza el servicio web adecuado creado por el otro miembro del proyecto. De esta manera, la información más importante del sistema está
33
DESARROLLO
Diseño
almacenada en un único lugar (base de datos) al que todas las aplicaciones Android pueden acceder vía API. 2. Device Cloud de Etherios . La nube es el medio que hace posible recibir mensajes o notificaciones desde la página web. Únicamente se almacenan los ficheros con la posición de los trabajadores en tiempo real, las firmas digitalizadas de los clientes y las fotografías de perfil de los trabajadores. 3. Dispositivo Android . En el caso de la aplicación para los repartidores, debido a que los datos que se iban a almacenar en la memoria del dispositivo eran mínimos y se utilizarían en contadas ocasiones, el proyectante decidió guardar la información en ficheros XML en vez de utilizar una base de datos. El primer fichero está destinado a guardar los cambios en las tareas, y únicamente se utiliza cuando el dispositivo pierde la conexión a Internet. En ese instante, entra en funcionamiento el modo offline, que permite al trabajador seguir usando la aplicación prácticamente igual que cuando está conectada a la red. Todos los cambios producidos durante el tiempo que el dispositivo no tenga conexión se guardarán en el fichero XML, localizado en el almacenamiento privado de la aplicación, y se subirán al servidor una vez vuelva la conexión.
En el anterior código XML podemos observar la estructura del fichero. Por cada cambio que se produzca en una tarea se añadirá un nodo task, cuyos atributos son el identificador de la tarea, el estado al que ha cambiado, la fecha y hora del cambio y los detalles. El segundo fichero es el encargado de almacenar los mensajes que se reciben desde la aplicación web. El código sería similar al anterior; por cada mensaje se guarda un nodo message, cuyos hijos son el contenido del mensaje, la fecha y hora de recepción y el identificador del remitente. ……
Por último, se guarda un fichero de preferencias globales, que es gestionado por el S.O. Android. En él se almacena los datos personales del repartidor, la última posición y el hash de los datos de acceso a la aplicación.
34
DESARROLLO
Diseño
En el otro caso, el de la aplicación para los clientes, únicamente se almacena el fichero de preferencias con el nombre del cliente y el hash de los datos de acceso.
2.2.5. Patrones de diseño Pese a que en la documentación oficial no se hace referencia a ningún patrón, en realidad muchos autores consideran que el sistema operativo implementa el patrón Modelo-Vista-Controlador (MVC). Esto es debido a lo siguiente:
Se definen una serie de interfaces en ficheros XML. Se definen una serie de recursos (locales, estructuras de datos) en ficheros XML. Se extienden diversas clases, como listas o tabs, y se instancian dentro de sus correspondientes vistas. Se crean tantas clases como sean necesarias para el modelo. Existen muchas clases que facilitan el acceso a bases de datos, HTML, etc.
Es por ello que al programar en Android, implícitamente, se usa el patrón MVC. Además, el proyectante ha utilizado el patrón Singleton en ambas aplicaciones, que garantiza que una clase solo tenga una instancia, proporcionando un punto de acceso global a ella. Android no permite modificar la interfaz gráfica desde hilos que no sean el principal. Acciones tan básicas como mostrar un toast (mensaje en forma de popup) únicamente se pueden lanzar desde el hilo principal, algo que puede ser un problema. Además, es necesario en muchas ocasiones acceder a las clases que gestionan la persistencia (tareas y mensajes). Por ello se decidió implementar el patrón Singleton en la clase principal de las aplicaciones, de manera que desde cualquier clase se pueda acceder a todos los métodos básicos sin necesidad de crear objetos de esas clases.
public class PackagingApplication extends Application { private static PackagingApplication instance ; public void onCreate() { super.onCreate(); instance = this;
… } public static PackagingApplication getInstance() { return instance ;
} … }
35
DESARROLLO
Diseño
2.2.6. Diseño de clases Como se ha comentado anteriormente, ambas aplicaciones poseen una arquitectura de tres capas. Todas ellas usan el modelo de objetos que se explicará más adelante. Los siguientes diagramas y clases pertenecen a la aplicación para los clientes.
Figura 15. Diagrama de paquetes.
En el siguiente diagrama se muestran las clases correspondientes al modelo de objetos . Por simplicidad, los accesores y modificadores de los atributos (getters y setters) se han obviado.
Figura 16. Diagrama de clases del modelo de objetos.
36
DESARROLLO
Diseño
Como se puede observar, la clase Order es la más relevante. Servirá para almacenar los datos de cada pedido que tenga un usuario. Las características más importantes de un pedido son las siguientes:
Tendrá un identificador único (idTask). Estará relacionado con dos clientes: el emisor y el receptor del paquete. Almacenará una lista con todos los cambios de estado que se hayan producido. A lo largo de su ciclo de vida pasará por varios estados, pero en un instante determinado solo tendrá uno. Tendrá asignado un único tipo de servicio.
La capa de Lógica de negocio es la encargada de gestionar todas las operaciones internas de la aplicación. Generalmente, cada pantalla de una aplicación Android corresponde con una clase que extiende de Activity (o de subclases de ella, como ListActivity o TabActivity).
Figura 17. Diagrama de clases de la capa de lógica de negocio.
Por último, en la capa de Persistencia existirán dos clases: una gestionará los pedidos y la otra las preferencias de la aplicación.
Figura 18. Diagrama de clases de la capa de persistencia.
37
DESARROLLO
Diseño
2.2.7. Diseño del plan de pruebas En esta sección se van a especificar las pruebas que posteriormente se ejecutarán en la última fase del desarrollo. Esta definición va a servir como guía de testeo y como medio de verificación de que todas las partes del sistema cumplen los requisitos iniciales con unos niveles de calidad aceptables. Se llevarán a cabo tres tipos de pruebas:
Pruebas unitarias: aquellas que sirven para asegurar que cada módulo funciona de la manera
correcta.
Pruebas de integración : aquellas en las que se verifica la validez de varios módulos en conjunto.
Pruebas de aceptación: aquellas que determinan si se cumplen o no los requisitos iniciales.
Cada prueba que se realice deberá ser documentada mediante la siguiente plantilla:
Prueba nº
Tarea:
Descripción Procedimiento Resultado
38
DESARROLLO
Implementación
2.3. Implementación Esta fase tiene como objetivo poner en práctica todas las características y reglas que se han ido estableciendo en las dos fases anteriores. En este capítulo se describen brevemente las principales tecnologías usadas en el proyecto, las librerías externas que se han empleado, los problemas que han surgido y cuál ha sido la manera de resolverlos.
2.3.1. Tecnologías usadas Como ya se ha señalado en varias ocasiones a lo largo de esta memoria, el proyecto está destinado a la obtención de dos aplicaciones para el sistema operativo Android. Android no utiliza Java SE, sino que usa una implementación libre de Java llamada Apache Harmony, que alcanza el 97% de Java SE 6. La máquina virtual de Android se llama Dalvik, cuyo núcleo está basado en Apache Harmony. Dalvik ejecuta ficheros .dex, que son versiones optimizadas de los ficheros .class. Desde el punto de vista del desarrollador, Java de Android es similar a Java SE, pero sin las librerías AWT/Swing y añadiendo APIs de Android personalizadas.
Figura 19. Diferencia entre Java VM y Dalvik VM.
En la actualidad, existen al menos dos formas para desarrollar aplicaciones en Android: con la ayuda de un framework (como Titanium, Adobe AIR o PhoneGap) o desde el lenguaje nativo Java. Pese a que los frameworks anteriormente citados poseen ciertas ventajas con respecto al desarrollo nativo, como la mayor simplicidad o la exportación a varios sistemas operativos, la realidad es bastante diferente. A diferencia del desarrollo en iOS, donde hay dos únicos modelos de dispositivos, en Android existe una gran variedad de terminales, pantallas y resoluciones, por lo que se hace más complicado desarrollar
39
DESARROLLO
Implementación
aplicaciones que funcionen y se visualicen correctamente en todos los dispositivos con el mismo código. Desarrollando en Android nativo con Java podremos: 1. Crear aplicaciones para todos los dispositivos Android, ya que comparten la misma API base. 2. No poner límites a nuestras aplicaciones (puesto que el uso de los frameworks anteriores acarrea unas ciertas limitaciones a la hora de acceder a ciertas funciones del terminal). Por todo lo anterior, el proyectante decidió desarrollar las aplicaciones en Android nativo con Java, usando el Software Development Kit (SDK) de Android, Eclipse como IDE y el plugin Android Development Tools (ADT). Para el desarrollo de las interfaces y elementos gráficos se ha usado XML, puesto que es la manera adecuada para hacerlo, recomendada por Google.
2.3.2. Librerías empleadas Con el objetivo de facilitar el desarrollo de ciertas partes del proyecto, se han usado varias librerías externas. Algunas de ellas (las relacionadas con la gestión de la nube) han sido proporcionadas por la empresa Digi International Spain. 1. Cloud Connector Android . Es una librería diseñada por los desarrolladores de Digi para comunicar las aplicaciones Android con la Device Cloud. Permite, entre otros, detectar los cambios de estado del Cloud Connector, recibir notificaciones o enviar ficheros a la nube. 2. Etherios Client Library. Es una librería diseñada por los desarrolladores de Digi que permite comunicar las aplicaciones Java con la Device Cloud. Su función principal es la de gestionar la conexión con la nube. 3. Dom4j. Es una librería Java open source que sirve para trabajar con XML, XPath y XSLT. Es compatible con los estándares DOM, SAX y JAXP. Es usada en la transmisión de datos entre el servidor web y los dispositivos Android, ya que se envían en XML. 4. Joda Time. Es una librería que sirve de reemplazo de las clases Java date y time. Permite trabajar con fechas de una forma más sencilla, potente y eficiente. La inclusión de intervalos y duraciones a la librería ha sido muy útil a la hora de calcular las horas límite de entrega de los paquetes por parte de los repartidores.
2.3.3. Estructura del proyecto A la hora de comenzar el proyecto, el propio Eclipse se encarga de crear el árbol de directorios, con las carpetas y ficheros necesarios para su funcionamiento. Todo proyecto en Android se divide generalmente en 6 carpetas: src, gen, assets, bin, libs y res, siendo las más relevantes la primera y la última:
40
DESARROLLO
Implementación
/src. Aquí se almacenan las actividades y el resto de clases creadas, con sus paquetes corres-
pondientes.
Figura 20. Contenido de la carpeta /src.
/res. Es la carpeta de recursos del proyecto. Está subdividida en,
como mínimo, 4 directorios: - drawable: contiene ficheros bitmap, formas, animaciones, imágenes, botones y otros elementos de dibujo. -
layout : en ella se encuentran los ficheros XML que corresponden con las interfaces de la aplicación.
-
menu: contiene los ficheros XML que definen los menús de las actividades.
-
values: en ella se encuentran los ficheros XML que contienen valores simples, como colores, cadenas de texto o estilos.
Figura 21. Contenido de /res.
Esta última carpeta puede contener además variaciones de los 4 subdirectorios mencionados, como se puede observar en la figura de la derecha. En este caso, las imágenes que se encuentren en drawable-nodpi no se escalarán dependiendo de la resolución de la pantalla; las interfaces de layout-land se mostrarán cuando el dispositivo móvil esté colocado en orientación horizontal (landscape); los valores que aparezcan en values-es serán visualizados cuando el idioma del terminal se español… 3 Otro elemento fundamental dentro de un proyecto es el AndroidManifest. Este fichero XML se genera automáticamente y en él se declaran todas las especificaciones de la aplicación, como actividades, servicios, nombre de la aplicación, versión, hardware necesario o permisos que usa del sistema operativo. En el Anexo 3 (AndroidManifest.xml) se pueden ver los ficheros de amb as aplicaciones.
3
La especificación completa se puede leer en http://developer.android.com/tools/projects/index.html
41
DESARROLLO
Implementación
2.3.4. Desarrollo de las aplicaciones Como se comentó al inicio de esta memoria, el proyectante escogió Scrum como metodología de desarrollo. Esto implica ir haciendo el trabajo en pequeños incrementos (o sprints), en este caso de dos semanas, de manera que al finalizar cada sprint se obtenga una parte funcional de la aplicación. Por ello, en este apartado se profundizará en lo expuesto en el punto 1.4, es decir, se irá describiendo el desarrollo realizado por cada sprint, los problemas que aparecieron y cómo el proyectante los resolvió (las fases 1 y 2 corresponden con la finalización de la aplicación para los repartidores; las siguientes con la nueva aplicación para los clientes).
Fase 1. Adaptación del código, incidencias y servicios y horas límite
Al inicio del trabajo, el proyectante se encontró con una aplicación sin finalizar, cuyas interfaces eran austeras y rudimentarias (Figura 9), y cuyo código solo era compatible con las versiones de Android 2.3.*. Todo esto desembocaba de la primera etapa del proyecto, el semestre de prácticas, debido a que fue una fase de aprendizaje y adaptación a Android, con el desarrollo de pequeñas porciones funcionales de código que luego se ensamblarían para formar la aplicación. El primer paso fue analizar el problema más importante, es decir, por qué la aplicación no funcionaba correctamente en las nuevas versiones de Android.
Figura 22. Excepción que aparecía al arrancar la aplicación.
Tras varias búsquedas en foros, se llegó a la siguiente conclusión: a partir de la versión 3.0 de Android no se puede realizar una operación de red en el hilo principal de la aplicación. Hasta ese momento, todas las llamadas a los servicios web del servidor (autenticación, petición o actualización de tareas…) se hacían en dicho hilo, por lo que hubo que buscar una alternativa para el correcto funcionamiento de la aplicación: crear tareas asíncronas. Se creó una clase llamada WebConnection, que extiende de AsyncTask (clase utilizada para ejecutar tareas simples o atómicas en un hilo aparte), de manera que cada vez que se desea realizar una conexión web se crea un objeto de esa clase, pasando la URL de conexión y los parámetros. Se advierte al lector de que todas las porciones de código que se presenten a partir de ahora pueden no corresponderse totalmente con el código de la aplicación, puesto que son pequeñas reducciones para ilustrar mejor los ejemplos.
42
DESARROLLO
Implementación
Por ejemplo, para pedir al servidor la información relativa a la tarea cuyo identificador es 1111, crearíamos un objeto de la clase WebConnection, llamaríamos a su método execute (pasándole los parámetros adecuados), y por último recogeríamos el resultado mediante el método get. WebConnection connection = new WebConnection(); connection.execute( "https://bybike-delivery.appspot.com/getTask", "idTask=1111"); result = connection.get();
public class WebConnection extends AsyncTask { protected String doInBackground(String... params) {
En esta fase se implementaron además los siguientes módulos:
Notificación de incidencias : cuando el repartidor pulse sobre el icono
de incidencia de la tarea aparecerá un diálogo con una serie de incidencias predeterminadas y un cuadro de texto, donde podrá dar cualquier detalle adicional del motivo de la incidencia. Para ello se creó la clase ReportIncidenceDialog (que extiende de Dialog). En el momento en el que se crea un objeto de la clase debemos establecer el comportamiento del diálogo cuando se vaya a cerrar. En este caso la aplicación volverá a la actividad que ha creado el diálogo a través de un Intent. ReportIncidenceDialog incidenceDialog = new ReportIncidenceDialog(context, task); incidenceDialog.setDialogResult(new OnMyDialogResult() { @Override public void finishTask(Task task) { Intent intent = new Intent(); intent.putExtra("task", task); setResult( RESULT_OK , intent); finish(); } }); incidenceDialog.show();
Implementación de tipos de servicio y horas límite : se crearon cuatro tipos de servicio, repre-
sentados por la enumeración Service (ver Figura 16). Por cada tarea se guarda el tipo de servicio y la hora de creación de la misma, que servirá para calcular la hora límite de entrega (especificada en el punto 2.1.2). Se añadió estas horas en la lista de tareas, y se creó un método que comprueba si queda menos de una hora para que llegue la hora límite de una tarea; si es así, muestra una alerta para que el repartidor se dé cuenta de ello.
Ordenación de las tareas en base a su prioridad : se creó la clase SortTasksByStatu-
sAndTime, que implementa a la interfaz Comparator<>, con el objetivo de poder ordenar la
lista de tareas en base a su estado (primero las que están en progreso, después las que están sin comenzar y por último las que están finalizadas) y a su hora límite, para que el repartidor sepa qué tarea debe hacer en cada momento.
Fase 2. Sincronización
Hasta este momento, la aplicación funcionaba siempre y cuando estuviera conectada a Internet, bien a través de WiFi o de datos móviles. El proyectante pensó que una característica que podría dar valor a la aplicación era que pudiera ser utilizada en aquellos lugares donde no hubiera cobertura. Para ello, ideó un sistema mediante el que el repartidor pudiera seguir utilizándola en dichas zonas.
44
DESARROLLO
Implementación
El primer paso fue detectar los cambios en la red, es decir, cuándo el terminal perdía la conexión a Internet y cuándo la recuperaba. La forma de hacerlo fue comprobando el estado del Cloud Connector 4. Para ello se creó la clase CloudConnectorStatusReceiver, cuya misión es captar los mensajes de broadcast emitidos por el Cloud Connector cuando hay un cambio en el estado de la red del terminal. Cuando se pierde la conexión se activa el “modo offline”; cuando vuelve, se regresa al “modo online” o modo normal. En la siguiente figura se pueden observar las implicaciones de cada modo:
Figura 23. Implicaciones de ambos modos de conexión.
La principal consecuencia del paso al modo sin conexión es que todos los cambios que se produzcan en las tareas deben ser almacenados localmente. Esto incluye tanto los cambios de estado como las firmas digitalizadas de los clientes (que se generan cuando un envío es entregado). Cuando la conexión vuelve al dispositivo, el sistema actualiza los cambios de las tareas en el servidor y sube las firmas almacenadas a la nube. Uno de los mayores problemas surgió en el método creado para subir las firmas a la nube. Dicho método accede al almacenamiento privado de la aplicación, lista todos los ficheros y aquellos cuya extensión es .png (correspondientes con las firmas digitalizadas) son enviados a la nube mediante el Cloud Connector, y borrados más tarde. La anomalía apareció a la hora de subirlas, puesto que el Cloud Connector se cerraba repentinamente.
4
El funcionamiento del Cloud Connector se explica en el punto 1.1.
45
DESARROLLO
Implementación
Tras múltiples pruebas, depuraciones y cambios en el código se llegó a la siguiente conclusión: el método que proporciona el Cloud Connector para subir un fichero a la nube es, por defecto, asíncrono. Tal cual estaba el código hasta ese momento, se invocaba dicho método y seguidamente se borraba el fichero .png, por lo que aparecía una excepción en el Cloud Connector y se cerraba. La solución fue invocar al método síncrono, con timeout 10 segundos, para subir un fichero (que devuelve true si la operación se ha realizado con éxito o false en caso contrario) y borrarlo una vez subido. En las siguientes porciones de código se puede ver el antes y el después: …
Fase 3. Creación de las interfaces de la nueva aplicación
La primera tarea de la nueva aplicación para los clientes (después del análisis y diseño) fue el desarrollo de las interfaces de usuario. Fue un proceso sencillo, puesto que solo había que copiar los prototipos realizados en el diseño y el proyectante ya dominaba la programación de layouts en Android.
Figura 24. Estructura de los layouts de la aplicación.
46
DESARROLLO
Implementación
Todos los layouts tienen la misma estructura: un LinearLayout vertical que contiene 3 elementos, la cabecera (siempre la misma), la barra de título y el cuerpo de la actividad.
La mayor dificultad que encontró el proyectante fue en el layout de “Nuevo pedido”, puesto que se quería simular un proceso en varios pasos (primero introducir los datos del remitente y el receptor, luego elegir el tipo de servicio y por último ver un resumen antes de aceptar el pedido). Además, se quería que fuese un proceso animado, con transiciones de entrada y salida en cada paso. Para ello se creó el layout new_order.xml, dentro del cual se utilizó el componente ViewFlipper , que incluye los cuatro pasos del proceso de nuevo pedido (finalmente se decidió dividir el primer paso en dos: información del remitente primero y luego la del receptor).
La clase NewOrderActivity es la encargada de gestionar las transiciones, de manera que cuando se pulsa el botón de siguiente la animación cambia de paso de derecha a izquierda. btNext.setOnClickListener(new OnClickListener() { @Override public void onClick(View v) { viewFlipper.showNext(); } });
47
DESARROLLO
Implementación
En las últimas semanas de desarrollo, cuando el proyecto estaba prácticamente acabado, la empresa proporcionó al proyectante un nuevo tablet para que probara la aplicación, el Nexus 7 de Google. Este tablet, de 7 pulgadas, posee una gran resolución (800x1280, 216 ppi), por lo que se presentó el problema de que las interfaces se veían muy pequeñas. Este inconveniente se resolvió de la siguiente manera: se estableció que las interfaces diseñadas hasta ese momento se muestren en dispositivos con resolución menor a 600dp (generalmente móviles de hasta 7 pulgadas). Para el resto de dispositivos (tablets de 7 pulgadas o más), se duplicaron y adaptaron las interfaces existentes, y se introdujeron dentro de la carpeta res/layout-sw600dp. El propio S.O. Android detecta la resolución de la pantalla donde se está ejecutando la aplicación y decide qué interfaces mostrar.
Fase 4. Funcionalidad de la aplicación para los clientes
Una vez implementadas las interfaces de usuario, el siguiente paso fue dotar de funcionalidad a la aplicación. Primero se crearon las clases correspondientes al modelo de objetos (ver Figura 16). Posteriormente, las diez clases que corresponden con la lógica de negocio, explicadas a continuación. Se recomienda al lector ver previamente las figuras del Anexo 2 (Mockups) y el punto 2.2.2 (Diagrama de navegación) para que le sea más fácil la comprensión de las siguientes clases.
MainApplication. Esta clase, que extiende de Application, es la principal de la aplica-
ción. Sirve para mantener el estado a través de todas las actividades y partes de la aplicación, implementando el patrón Singleton. A través de su única instancia, permite el acceso a las dos clases de la persistencia. Además, posee un método público para que cualquier actividad o hilo de la aplicación pueda mostrar un toast (mensaje por pantalla) a través del hilo principal. /** * Default handler to take care of UI actions called from other threads. */ private Handler handler = new Handler() { public void handleMessage(Message msg) { switch (msg.what) { case ACTION_SHOW_TOAST : Toast. makeText(MainApplication.this, msg.getData().getString( "message"), Toast.LENGTH_LONG ).show(); break; } } };
HomeActivity. Es la actividad inicial, aquella que aparece cuando la aplicación es ejecutada.
Implementa el funcionamiento de los tres botones (ver Figura 12) y crea un menú para acceder al login y a la información de la empresa.
48
DESARROLLO
Implementación
LoginActivity. Esta actividad es la encargada de loguear al usuario. Cuando se pulsa el bo-
tón de iniciar sesión, el método handleSignPressed() verifica la autenticidad del usuario llamando al servicio web /clientIdentification, al que le pasa el hash de user:password . Si la verificación es correcta, almacena el nombre del usuario en las preferencias globales y retorna a la actividad que había invocado al login; si no lo es, muestra un mensaje por pantalla.
TrackingActivity. El cometido de esta actividad es localizar el o los pedidos en curso de
un cliente o un usuario no registrado en el sistema. Por ello, esta actividad cuenta con dos vistas: si hay un cliente en la sesión, llama al método de la persistencia getProgressOrders() y muestra una lista con los pedidos en curso de dicho cliente; si no lo hay, presenta un cuadro de texto donde el usuario puede introducir un número de seguimiento para ver los detalles de su pedido. En ambos casos se permite escanear un código QR asociado a un pedido para ver sus detalles. Cuando el usuario pulsa sobre un pedido de la lista o hace clic sobre el botón de localizar, la aplicación inicia la actividad OrderDetailsActivity.
Figura 25. Comparación de ambas vistas.
OrderDetailsActivity. Esta actividad recibe a través del intent de llamada un objeto
de la clase Order, que contiene todos los detalles del pedido seleccionado. Muestra al usuario una tabla con el tránsito del pedido, es decir, cada fila corresponde con un cambio de estado de la tarea. Además, proporciona un botón para acceder a los detalles completos de la misma.
OrderFullDetailsActivity. Una de las actividades más simples de la aplicación. Su úni-
ca tarea es recoger el objeto pedido del intent y mostrar al usuario todos los detalles del mismo.
HistoryActivity. Es la actividad encargada de mostrar todos los pedidos que ha realizado
un usuario. Para ello, llama al método de la persistencia getOrders(), que devuelve un obje-
49
DESARROLLO
Implementación
to del tipo List. Al igual que ocurría en la actividad de tracking, cuando el usuario pulsa sobre un pedido se inicia la actividad OrderDetailsActivity. Por último, se le provee al usuario de un cuadro de texto donde poder buscar o filtrar los pedidos (a través de su identificador o de su estado). A medida que el usuario escribe en el cuadro, la lista de pedidos se va actualizando. En el siguiente código se puede observar cómo está implementada esta característica:
private void initializeUI() {
… etSearch = (EditText)findViewById(R.id.etSearch); TextWatcher fieldValidatorTextWatcher = new TextWatcher() { … @Override public void onTextChanged(CharSequence s, int start, int before, int count) { updateList(etSearch.getText().toString().toLowerCase()); } }; etSearch.addTextChangedListener(fieldValidatorTextWatcher); } private void updateList(String text) { if (orders != null) {
ArrayList filter = new ArrayList(); for (Order o : orders) { if (o.getIdTask().contains(text) || o.getStatus().getName().toLowerCase().contains(text)) filter.add(o); } ordersAdapter = new OrdersAdapter(context, R.layout.order_item , filter, getLayoutInflater()); getListView().setAdapter( ordersAdapter); } }
NewOrderActivity. Actividad encargada de gestionar el proceso de un nuevo pedido. Co-
mo ya se comentó anteriormente, este proceso está compuesto de cuatro pasos. En el primero y segundo se presenta al usuario una serie de cuadros de texto para que introduzca los datos del emisor y receptor del paquete. Las únicas comprobaciones que se hacen en ese momento es que todos los campos excepto el teléfono estén rellenados. En el tercer paso el usuario debe elegir el tipo de servicio y método de pago. Además, puede adjuntar detalles específicos relacionados con el envío. Antes de cargar este paso, el sistema comprueba en base a la hora del dispositivo qué servicios están disponibles en ese momento para mostrarlos en el spinner. El cuarto y último paso sirve para que el usuario verifique que toda la información es correcta, mostrando todos los valores introducidos en los anteriores pasos. Cuando el usuario pulse so-
50
DESARROLLO
Implementación
bre el botón de finalizar, el sistema llamará al método de creación de pedido de la persistencia y mostrará en un diálogo el resultado de la operación.
StoredAddressesActivity. Cada vez que un usuario realiza un nuevo pedido, interna-
mente en el servidor se almacenan los datos del remitente y del receptor como “favoritos”, con el objetivo de agilizar futuros pedidos a los mismos clientes. Por ello, esta actividad obtiene esas direcciones favoritas del servidor y las muestra en una lista, permitiendo que el usuario no tenga que volver a escribir los datos. A esta actividad se accede a través del menú de NewOrderActivity. La idea de crear esta actividad surgió en pleno desarrollo del proceso de nuevos pedidos, por lo que no está contemplada en los prototipos iniciales.
AboutUsActivity. Es la actividad más simple de la aplicación y no tiene funcionalidad algu-
na. Únicamente muestra información sobre la empresa y sus tipos de servicios. Estos datos están almacenados en la carpeta de recursos (res/values/strings.xml ) de la aplicación.
Figura 26. Vista de las direcciones almacenadas y la información de la empresa.
Por último, se crearon las dos clases de la capa de persistencia: PreferencesManager y OrdersManager. La primera de ellas gestiona las preferencias de la aplicación (en este caso nombre de usuario y hash) en el almacenamiento interno de Android. Para ello, utiliza un objeto de la clase SharedPreferences, que proporciona métodos put y get para escribir y leer del fichero de preferencias. Por otro lado, la clase OrdersManager es la encargada de realizar las peticiones web, obtener las respuestas en formato XML y parsearlas. En todas las llamadas a servicios web es necesario pasar el hash como método de validación del usuario (exceptuando en el de tracking de un único p edido).
51
DESARROLLO
Pruebas
2.4. Pruebas Como se estableció en el punto 2.2.7 Diseño del plan de pruebas, se van a realizar tres tipos de pruebas: unitarias, de integración y de aceptación. Cabe destacar que, al estar utilizando una metodología de desarrollo ágil, las pruebas unitarias se fueron haciendo a medida que se iba desarrollando la aplicación. 1. Pruebas unitarias (solo se incluyen las más importantes, el resto se pueden ver en el Anexo 4, Pruebas unitarias). Las dos primeras corresponden con la aplicación para los repartidores; las dos últimas a la aplicación para los clientes.
Prueba nº 1.1
Tarea: Envío de incidencia
Descripción
Reporte de una incidencia sobre una tarea no finalizada.
Procedimiento
En la actividad de detalles de tarea, el repartidor pulsa sobre el icono de incidencia. En el diálogo que aparece selecciona una incidencia de las que se muestran en el spinner y, si desea, añade un comentario en el cuadro de texto.
Resultado
CORRECTO. La incidencia es enviada correctamente y la aplicación regresa a la pantalla inicial, donde la tarea marcada aparece ahora como incidencia.
Prueba nº 1.2
Tarea: Ordenación de tareas por prioridad
Descripción
La lista de tareas que ve el repartidor está ordenada según el estado de las mismas y su hora límite.
Procedimiento
No hay ninguna acción por parte del repartidor.
Resultado
CORRECTO. Las tareas, a medida que llegan a la aplicación, se van ordenando según su estado, y dentro de un mismo estado, por la hora límite de entrega.
52
DESARROLLO
Pruebas
Prueba nº 2.1
Tarea: Login
Descripción
Identificación en el sistema a través de la cuenta de usuario (nombre de usuario y contraseña).
Procedimiento
El usuario, desde la pantalla inicial de la aplicación, accede a la actividad de Login desde el menú o pulsando sobre los botones de “Mis pedidos” o “Nuevo pedido”. Después, introduce sus credenciales y pulsa el botón Iniciar sesión.
Resultado
CORRECTO. Si las credenciales son correctas, la aplicación loguea al usuario, guarda su nombre y hash en las preferencias de la aplicación y regresa a la actividad de procedencia. Si no, aparece un mensaje de error.
Prueba nº 2.2
Tarea: Localización con tracking number
Descripción
Localización de un pedido introduciendo su número de seguimiento.
Procedimiento
El usuario, sin haber iniciado sesión, accede a la actividad de “Localizar pedido” e introduce su número de seguimiento. Por último, pulsa sobre el botón Localizar.
Resultado
CORRECTO. Si el número de seguimiento coincide con un pedido, se muestra la actividad “Detalles del pedido”, con la tabla del tránsito del pedido. Si no, muestra un mensaje avisando que no existe ningún pedido con ese código.
53
DESARROLLO
Pruebas
2. Pruebas de integración .
Prueba nº 1.1
Tarea: Sincronización
Descripción
Actualización en el servidor de cambios de estado de tareas y firmas digitalizadas cuando el terminal estaba en modo sin conexión.
Procedimiento
No hay ninguna acción por parte del usuario. La aplicación, en el momento en el que recupera la conexión a Internet, actualiza en el servidor los cambios de estado de las tareas y sube a la nube las firmas digitalizadas.
Resultado
CORRECTO. Cuando la aplicación recupera la conexión a la red: quita el icono de modo offline, sube los cambios de estado y las firmas y avisa mediante un mensaje al usuario de que el proceso ha finalizado correctamente. Si no hay ningún cambio de estado o ninguna firma, no aparece ningún mensaje.
Prueba nº 2.1
Tarea: Nuevo pedido
Descripción
Proceso de creación de un nuevo pedido.
Procedimiento
El usuario, una vez ha iniciado sesión, accede desde el inicio a “Nuevo pedido”. En el primer paso introduce los datos del remitente del pedido; en el segundo, los del emisor; en el tercero debe seleccionar el tipo de servicio y el método de pago; por último, en el cuarto puede verificar los datos introducidos anteriormente. Si está conforme, pulsará sobre el botón Finalizar. Si no, sobre Cancelar.
Resultado
CORRECTO. Si hay disponibilidad de repartidores y todos los datos introducidos son correctos, aparecerá un diálogo avisando de que el proceso se ha completado correctamente. Si no la hay, se avisa de que el servicio no está disponible. Por el contrario, si el usuario decide cancelar el pedido, la aplicación regresa a la actividad inicial.
54
DESARROLLO
Pruebas
3. Pruebas de aceptación. A lo largo del proyecto, la revisión del trabajo realizado por parte de la empresa ha s ido constante, puesto que cada dos semanas se convocaba una reunión para exponer los avances del mismo, que también servía para proponer cambios o mejoras en las aplicaciones. Durante los meses de abril y mayo, ambas aplicaciones fueron presentadas en varias ocasiones a los miembros responsables de la empresa, haciendo en las últimas reuniones una demo del sistema completo (aplicaciones Android y aplicaciones web). En la última, se obtuvo el visto bueno de ambas aplicaciones, con lo que se dio por finalizado el desarrollo del proyecto.
55
Capítulo 3. Conclusiones En este último apartado se resumen las conclusiones más importantes de este proyecto. Se ha evaluado el grado de cumplimiento de los objetivos iniciales y se exponen los problemas planteados y el método de resolución, los conocimientos adquiridos por el proyectante en el desarrollo del mismo y las futuras mejoras que no se han podido implementar por falta de tiempo.
3.1. Evaluación de objetivos En la primera parte de la memoria se mencionaron los objetivos de este proyecto. Estos se dividieron en tres niveles: objetivo general, objetivos a nivel del sistema y objetivos a nivel de las aplicaciones Android. Se analizarán de modo inverso a lo expuesto, es decir, de los más concretos a los más abstractos. En cuanto a las aplicaciones Android : se ha finalizado correctamente y según lo planificado la de los repartidores, modificando determinados aspectos como la interfaz de usuario, y se ha desarrollado la nueva aplicación para los clientes, con las tres funciones básicas. Además, ambas aplicaciones son intuitivas y fáciles de usar, funcionan tanto en smartphones como en tablets y son compatibles con cualquier versión del sistema operativo superior a la 2.3.3. Con respecto al sistema global (visto como la unión de los dos trabajos de los alumnos), se ha logrado que ambas plataformas se comuniquen, bien a través de la Device Cloud o de Google App Engine. El sistema ha sido probado por varios miembros de la empresa Digi y ha contado con el visto bueno de todos los responsables, así como el vídeo promocional, que ha causado muy buenas sensaciones. Por último, analizando el objetivo general del proyecto (desarrollar un sistema completo y fácil de usar que se encargue de la logística necesaria para el buen funcionamiento de una empresa de paquetería a pequeña escala), se considera que se ha cumplido casi en su totalidad. Pese a que el sistema podría implantarse tal y como está en una empresa de esas características, quizás haya cuestiones que mejorar o añadir para poder competir con los sistemas similares presentes en el mercado.
3.2. Problemas planteados y procedimiento para su resolución A pesar de que durante la fase de desarrollo ya se fueron mencionando los problemas que surgieron, se ha decidido resumirlos aquí para un mejor análisis de los mismos. Uno de los primeros problemas que surgió en el desarrollo fue el no funcionamiento de la aplicación para los repartidores en versiones superiores a la 3.0 de Android. Esto se debió a que no se siguieron las recomendaciones de Android, puesto que se llevaban a cabo operaciones de red en el hilo principal de la aplicación, algo que se resolvió introduciendo tareas asíncronas.
56
CONCLUSIONES
Conocimientos adquiridos
El cambio ha sido un constante inconveniente a lo largo de proyecto. Como se ha comentado anteriormente, cada dos semanas había una reunión con los responsables de la empresa, y en muchas de ellas se planteaban cambios y mejoras en las aplicaciones. En el caso de las mejoras no significaba tanto problema, pero hacer efectivo un cambio significaba haber perdido horas o días de trabajo. Sin embargo, pese a todos los cambios que se han llevado a cabo, el proyecto se ha conseguido finalizar en el plazo previsto y dentro del margen de horas estimadas. Otro problema que surgió en el mes de marzo fue el cambio de marca corporativa de la nube de dispositivos. Hasta entonces, la nube se llamaba iDigi Device Cloud, pero debido a la adquisición de Etherios por parte de Digi, decidieron hacer un rebranding, con lo que pasó a llamarse Etherios Device Cloud. Esto afectó al proyecto ya que hubo que cambiar y refactorizar todas las clases que dependen de la nube, sustituyendo también las librerías y el iDigi Connector por el Cloud Connector. Por último, otra complicación que surgió en la parte final del proyecto fue la mala adaptación de las interfaces a pantallas con grandes resoluciones. Durante el desarrollo de las aplicaciones, los medios para probarlas fueron un tablet de 7 pulgadas y un smartphone de 4,7. En las últimas semanas, se instalaron las aplicaciones en un tablet de gran resolución y quedó de manifiesto su mala adaptación. Esto se resolvió acudiendo a la documentación oficial de Android, que dio las claves al proyectante para corregir las interfaces y que se visualizaran de manera correcta.
3.3. Conocimientos adquiridos No cabe duda de que después de trabajar tanto tiempo sobre la plataforma Android, una de las destrezas más importantes adquiridas ha sido esa, la programación de aplicaciones para este sistema operativo. Cuando el proyectante comenzó a elaborar este trabajo ya poseía cierta base en esta plataforma, ya que durante los meses de prácticas previos a este trabajo se inició la construcción del sistema, lo que implicó semanas de aprendizaje. Adentrarse en el mundo de las tecnologías móviles ha resultado una muy buena experiencia para el proyectante, pudiendo asegurar que estas solo han sido las primeras de muchas aplicaciones que desarrollará, tanto en Android como en otras plataformas. Además, las habilidades transversales adquiridas a lo largo de este trabajo han sido muy positivas. Aprender a solucionar problemas sin la supervisión de un profesor, trabajar en equipo, guiar tu propio proyecto o desarrollar en el ámbito de una empresa son cuestiones que han ayudado al proyectante a acercarse más al mundo laboral que le espera. El proyectante ha aprendido que quien manda puede cambiar de opinión, y lo que hace una semana había que hacerlo de una manera ahora hay que hacerlo de otra, y además hay que hacerlo ya. Es decir, hay que estar constantemente preparado para el cambio y es posible que todo el trabajo de días o semanas no valga para nada y haya que cambiarlo. Y, aunque no se ha mejorado demasiado el nivel, este trabajo ha hecho que el proyectante se dé cuenta de la importancia que tiene el inglés en el campo de las tecnologías. Formar parte de una multinacional
57
CONCLUSIONES
Mejoras del proyecto
norteamericana ha implicado escribir (documentación, presentaciones, correos electrónicos) e incluso exponer el proyecto en inglés ante ejecutivos de la delegación estadounidense, por lo que queda de manifiesto la importancia del buen manejo de este idioma.
3.4. Mejoras del proyecto Debido a la limitación horaria y temporal de este trabajo, ha sido imposible llevar a cabo ideas que se propusieron antes de comenzar con él. Ejemplos de esas ideas son:
Comunicación mediante mensajes del dispositivo móvil a la página web. En la aplicación para los repartidores solo se permite que la empresa envíe mensajes a sus trabajadores. Una mejora sería que estos pudieran también responder. Reiniciación de tareas marcadas como incidencia. En el estado actual de la aplicación, una vez que se marca una tarea como incidencia no se puede volver a iniciar. Lo ideal sería que se pudiera reiniciar para entregar el paquete en otro momento. Generación de códigos QR para pegatinas. Según como está diseñado el sistema, el repartidor debe llevar pegatinas pre-impresas para pegar en los paquetes que recoge. Cada código QR de las pegatinas tiene una numeración distinta, como medio de identificación única del paquete. Podría ser mejor que el repartidor imprimiera el código en el momento de recoger el paquete. Utilización de la localización del repartidor en el seguimiento de un pedido. Algo que podría agradar a los clientes es ver sobre un mapa dónde se encuentra su pedido. Para ello, podría utilizarse la localización del terminal que se utiliza para controlar a los repartidores. Implementación de los métodos de pago. Puesto que la aplicación no está destinada, en principio, a venderse a una empresa real, no se implementaron los métodos de pago. Si fuera a ser utilizada por una compañía real habría que implementar las pasarelas de pago para poder solicitar un envío.
58
Capítulo 4. Bibliografía
Ed Burnette (2010). Hello Android. Introducing Google’s Mobile Development Platform. Pragmatic Bookshelf. Mark L. Murphy (2009). The Busy Coder’s Guide to Advanced Android Development . CommonsWare. Sayed Hashimi, Satya Komatineni, Dave MacLean (2010). Pro Android 2. Apress. Project Management Institute (2008). Guía de los Fundamentos para la Dirección de Proyectos. PMI.
http://www.android.com
http://developer.android.com
http://stackoverflow.com
59
Trabajo de Fin de Grado Rubén Moral Miera
Anexos Anexo 1. Casos de uso En este anexo se enumeran el resto de casos de uso de la aplicación para los clientes:
Caso de uso
Cerrar sesión
Descripción
Finalizar la sesión abierta en [Iniciar sesión].
Actores
Cliente.
Precondiciones
La sesión del cliente debe estar abierta.
Postcondiciones
La sesión del cliente queda cerrada.
Flujo básico 1. 2. 3.
El cliente elige la opción “Cerrar sesión” en la pantalla inicial. El sistema muestra un aviso pidiendo la confirmación del usuario. El cliente pulsa sobre aceptar.
Flujos alternativos y excepciones No hay. Anotaciones
La opción de cerrar sesión solo aparecerá en el menú inicial cuando la sesión se encuentre abierta.
Caso de uso
Ver detalle pedido
Descripción
Mostrar los detalles del pedido seleccionado.
Actores
Cliente.
Precondiciones
El cliente ha tenido que pulsar en un pedido en [Localizar pedido] o en [Ver historial de pedidos].
Postcondiciones
Se muestra en detalle el pedido, así como una lista con los estados por los que ha ido pasando.
Flujo básico 1. 2.
El cliente pulsa sobre el pedido. El sistema muestra la información relativa a ese pedido.
Flujos alternativos y excepciones No hay. Anotaciones
No hay.
1
ANEXOS
Casos de uso
Caso de uso
Ver historial de pedidos
Descripción
Mostrar una lista con los pedidos realizados de un cliente.
Actores
Cliente.
Precondiciones
El cliente debe estar autenticado.
Postcondiciones
Se muestra una lista con todos los pedidos que ha realizado el cliente.
Flujo básico 1. 2. 3.
El cliente elige la opción “Historial de pedidos” en la pantalla inicial. El sistema comprueba si el cliente está autenticado. El sistema muestra una lista con todos los pedidos realizados por el cliente.
Flujos alternativos y excepciones En el punto 2, si el cliente no ha iniciado sesión se lleva a cabo [Iniciar sesión]. Tras el punto 3, el cliente puede pulsar sobre un pedido de la lista e ir a [Ver detalle pedido]. Anotaciones
No hay.
Caso de uso
Escanear código QR
Descripción
A través de la cámara del dispositivo se escanea un código QR que lleva implícito el número de seguimiento.
Actores
Cliente.
Precondiciones
El cliente ha tenido que pulsar el icono de la cámara en [Localizar pedido].
Postcondiciones
El número de seguimiento implícito en el código es devuelto a [Localizar pedido].
Flujo básico 1. 2. 3.
El cliente sitúa la cámara del dispositivo sobre el código QR, quedando alineado este con el cuadro delimitado en la pantalla. El sistema escanea el código y avisa al usuario mediante un pitido. El sistema lleva a cabo el punto 4 de [Localizar pedido].
Flujos alternativos y excepciones Si lo que se está escaneando no es un código QR, el sistema mantendrá la pantalla de escaneo. Anotaciones
No hay.
2
ANEXOS
Mockups
Anexo 2. Mockups
Figura 1. Pantalla inicial.
3
ANEXOS
Mockups
Figura 2. Menú de la pantalla inicial
4
ANEXOS
Mockups
Figura 3. Pantalla de información de la empresa.
5
ANEXOS
Mockups
Figura 4. Pantalla de login y registro.
6
ANEXOS
Mockups
Figura 5. Pantalla de inicio con usuario logueado.
7
ANEXOS
Mockups
Figura 6. Menú de la pantalla inicial con usuario lo gueado.
8
ANEXOS
Mockups
Figura 7. Pantalla de confirmación de cierre de sesión.
9
ANEXOS
Mockups
Figura 8. Pantalla de inicio horizontal.
10
ANEXOS
Mockups
Figura 9. Pantalla de seguimiento de pedidos.
11
ANEXOS
Mockups
Figura 10. Pantalla de detalles del pedido.
12
ANEXOS
Mockups
Figura 11. Pantalla de detalles completos.
13
ANEXOS
Mockups
Figura 12. Pantalla de seguimiento si el usuario está logueado.
14
ANEXOS
Mockups
Figura 13. Pantalla de histórico de pedidos.
15
ANEXOS
Mockups
Figura 14. Pantalla del primer paso de un nuevo pedido.
16
ANEXOS
Mockups
Figura 15. Pantalla del segundo paso de un nuevo pedido.
17
ANEXOS
Mockups
Figura 16. Pantalla del tercer paso de un nuevo pedido.
