Aplicación Android para la Asistencia a Pilotos de Aviación Ligera
Transcripción
Aplicación Android para la Asistencia a Pilotos de Aviación Ligera
IS31 PROYECTOS INFORMÁTICOS DE SISTEMAS INGENIERÍA TÉCNICA EN INFORMÁTICA DE SISTEMAS Curso 2012/13 Memoria Técnica del Proyecto Aplicación Android para la Asistencia a Pilotos de Aviación Ligera Proyecto Presentado por: José Miguel Llorens Vera Dirigido por: Raúl Montoliu Colás Castellón, a 25 de Mayo de 2013 2 Resumen En este documento se detalla el estudio y realización de una aplicación Android que busca suplir las necesidades que un piloto de Aviación Ligera puede tener. En el transcurso de éste se estudia el sistema Android, se realiza una planificación y, siguiendo ésta, se modela el sistema y finalmente se diseña e implementa una pequeña parte de este. La parte implementada consta de una actividad que realiza el seguimiento de listas de chequeo de un avión. En ellas se reflejan las acciones que debe tomar un piloto en las distintas fases de vuelo para conseguir un vuelo más seguro. La aplicación ha sido diseñada para ser utilizada tanto desde un móvil como desde una Tablet, aprovechando al máximo la pequeña pantalla de un Móvil y aprovechando el espacio extra disponible de una Tablet. 3 IÍ ndice General Índice General .................................................................................................. 3 Índice de Figuras ............................................................................................. 7 Índice de Cuadros ............................................................................................ 9 Capítulo 1: Introducción ............................................................................. 11 1.1 1.2 1.3 1.4 1.5 Motivación del Proyecto ................................................................................................11 Necesidades del Proyecto .............................................................................................11 Contexto ...............................................................................................................................13 Objetivos del Proyecto....................................................................................................14 Palabras Clave....................................................................................................................14 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 Qué es Android ..................................................................................................................15 Características Técnicas ................................................................................................16 Arquitectura del Sistema ...............................................................................................18 Almacenamiento de Datos ............................................................................................20 Estructura de una Aplicación .......................................................................................21 Ciclo de Vida de una Activity........................................................................................23 Resources ............................................................................................................................25 Android Manifest ..............................................................................................................25 Interfaz de Usuario ..........................................................................................................26 Capítulo 2: Estudio Previo - El sistema Android ................................. 15 Principios de Diseño ................................................................................................................................... 26 Patrones de Diseño ...................................................................................................................................... 27 Componentes Básicos. ............................................................................................................................... 32 2.10 Entorno de Desarrollo ....................................................................................................33 Capítulo 3: Planificación ............................................................................. 34 3.1 3.2 Estimación de Recursos Materiales...........................................................................34 Planificación Temporal ..................................................................................................36 3.3 3.4 Estimación de Costes ......................................................................................................40 Seguimiento del Proyecto .............................................................................................41 Identificación de Tareas ............................................................................................................................ 36 Estimación de Tiempos ............................................................................................................................. 38 Hitos ................................................................................................................................................................... 38 Relaciones entre Tareas ............................................................................................................................ 39 Estimación de Fechas ................................................................................................................................. 39 4 Capítulo 4: Análisis .......................................................................................43 4.1 4.2 Presentación de los Requisitos ...................................................................................43 Visión general de la Aplicación ...................................................................................45 4.3 4.4 4.5 Subsistema Papeles .........................................................................................................53 Subsistema Navegación .................................................................................................60 Subsistema Utilidades ....................................................................................................65 5.1 Interfaz Gráfica ..................................................................................................................71 5.2 Diseño de los Procesos ...................................................................................................77 Actores .............................................................................................................................................................. 46 Dependencias de Datos ............................................................................................................................. 47 Requisitos No Funcionales ....................................................................................................................... 52 Capítulo 5: Diseño .........................................................................................71 Elementos Comunes ................................................................................................................................... 71 Prototipo de la Interfaz Gráfica (Anexo C) ........................................................................................ 72 Menú Principal .............................................................................................................................................. 72 Lista de Funcionalidades .......................................................................................................................... 73 Menú Checklists ............................................................................................................................................ 74 Checklist Actual............................................................................................................................................. 75 Menú Ajustes .................................................................................................................................................. 76 Mostrar Listas y Checklist ........................................................................................................................ 77 Proceso Usar Checklists ............................................................................................................................ 78 Proceso Usar Checklists de Emergencia ............................................................................................ 79 Borrar Checklists Completadas ............................................................................................................. 80 Borrar Ítems Completados ....................................................................................................................... 80 Diagramas de Clase (Libros de Checklists) ....................................................................................... 81 Archivo XML del Avión .............................................................................................................................. 84 Capítulo 6: Implementación ...................................................................... 85 6.1 Implementación del Interfaz Gráfico ........................................................................85 6.2 Presentación de la Implementación del Sistema .................................................89 6.3 6.4 6.5 Layouts Principales ..................................................................................................................................... 86 El Spinner de Categorías ........................................................................................................................... 87 Pestañas en las Checklists ........................................................................................................................ 88 Recursos Visuales ........................................................................................................................................ 88 Paquete Principal (com.gmail.mikepilot.PilotFMS) ...................................................................... 89 Paquete Checklists (com.gmail.mikepilot.PilotFMS.Papers.Checklist) ................................ 91 Vista General del Sistema ..............................................................................................92 Elementos Comunes del Sistema................................................................................93 Métodos Comunes........................................................................................................................................ 93 Procedimientos Comunes......................................................................................................................... 95 Principales Retos y Cambios de Diseño ...................................................................98 Cambio de Diseño - Mostrar Lista y Mostrar Ítems. ..................................................................... 98 Cambio de Diseño - Borrar Checklist. ................................................................................................. 99 Cambio de Diseño – Usar Checklist de Emergencia ...................................................................... 99 Implementación de PlaneChecklists. ................................................................................................ 100 Versiones SmartPhone y Tablet – Pestañas. ................................................................................. 102 Versiones SmartPhone y Tablet – Up & Back. .............................................................................. 103 Versiones SmartPhone y Tablet – Nombre de Checklist. ........................................................ 103 5 Capítulo 7: Pruebas.................................................................................... 104 Capítulo 8: Resultado Final ..................................................................... 111 8.1 8.2 8.3 Menú Principal – Vista de Categorías. ................................................................... 111 Menú Ajustes ................................................................................................................... 114 Actividad Checklists. .................................................................................................... 115 9.1 9.2 9.3 Conclusiones Técnicas ................................................................................................. 118 Conclusiones Personales ............................................................................................ 118 Trabajo Futuro ............................................................................................................... 119 Capítulo 9: Conclusiones .......................................................................... 118 Bibliografía ................................................................................................... 120 Anexo A: Definiciones y Abreviaturas ............................................... 121 Anexo B: Manual de Usuario................................................................. 125 6 IÍ ndice de Figuras Figura 1. Piernógrafo, Checklists y CR-3 respectivamente ................................................12 Figura 2. Esquema de la Arquitectura de Android [2].........................................................18 Figura 3. Ciclo de Vida de Activity [4] ........................................................................................24 Figura 4. Navegación en Android [3] .........................................................................................28 Figura 5. Componentes de Action Bar [3] .................................................................................29 Figura 6. Layout de una App en un móvil [3] ..........................................................................30 Figura 7. Layout de una App en una Tablet [3] ......................................................................30 Figura 8. Layout de una Notificación [3]...................................................................................31 Figura 9. Red de Actividades .........................................................................................................39 Figura 10. Diagrama de Casos de Uso - General.....................................................................45 Figura 11. Diagrama de Casos de Uso - Subsistema Papeles.............................................53 Figura 12. Diagrama de Casos de Uso - Subsistema Navegación.....................................60 Figura 13. Diagrama de Casos de Uso - Subsistema Utilidades........................................65 Figura 14. Icono de la Aplicación .................................................................................................71 Figura 15. Diseño de la Pantalla Menú Principal ...................................................................72 Figura 16. Diseño de la Pantalla Lista de Funcionalidades................................................72 Figura 17. Diseño en Tablet de Menú Principal – Lista de Funcionalidades ..............73 Figura 18. Diseño de la Pantalla Menú Checklists .................................................................74 Figura 19. Diseño de la Pantalla Checklist Actual .................................................................74 Figura 20. Diseño en Tablet de Menú Checklists - Checklist Actual ...............................75 Figura 21. Diseño de la Pantalla Ajustes ...................................................................................76 Figura 22. Diagrama de Actividad - Mostrar Listas ..............................................................77 Figura 23. Diagrama de Actividad - Mostrar Checklist........................................................77 Figura 24. Diagrama de Actividad - Usar Checklist ..............................................................78 Figura 25. Diagrama de Actividad - Usar Checklist Emergencia .....................................79 Figura 26. Diagrama de Actividad - Borrar Checklists Completadas .............................80 Figura 27. Diagrama de Actividad - Borrar Ítems Completados......................................80 Figura 28. Diagrama de Clases - Clase PlaneChecklists.......................................................81 Figura 29. Diagrama de Clases - Clase Checklist ....................................................................82 Figura 30. Diagrama de Clases - Clase CheckCompletas .....................................................83 Figura 31. Prototipo de Archivo XML de Avión ......................................................................84 Figura 32. Layout Principal main.xml ........................................................................................86 Figura 33. Layout Principal checklist_main.xml ....................................................................87 Figura 34. Código catActivity.java. onCreate() - Implementación del Spinner ..........87 Figura 35. Código CheckActivity.java. onCreate() - Implementación de Pestañas ...88 Figura 36. Icono Checklist de Emergencia ...............................................................................88 Figura 37. Relación Activities-Fragments ................................................................................92 Figura 38. Método onActivityCreated() de BookNormTab.java ......................................98 7 Figura 39. Método checkSavedItems() de CheckDetail.java .............................................99 Figura 40. Captura Móvil - Menú Principal ........................................................................... 111 Figura 41. Captura Móvil - Menú Categorías ........................................................................ 111 Figura 42. Captura Tablet - Menú Principal. ........................................................................ 112 Figura 43. Captura Móvil - Menú Categoría (Spinner Desplegado) (Portrait) ........ 112 Figura 44. Captura Móvil - Menú Principal (Landscape) ................................................. 112 Figura 45. Captura Tablet - Menú Principal (Portrait) ..................................................... 113 Figura 46. Captura Tablet - Menú Ajustes - Cambiar Avión (Portrait) ...................... 113 Figura 47. Captura Móvil - Menú Ajustes .............................................................................. 114 Figura 48. Captura Móvil - Menú Ajustes - Reiniciar Sesión .......................................... 114 Figura 49. Captura Móvil - Función Checklists - Lista de Checklists. .......................... 115 Figura 50. Captura Móvil - Función Checklists - Ítems de Checklist. .......................... 115 Figura 51. Captura Tablet - Función Checklists. ................................................................. 116 Figura 52. Captura Móvil - Función Checklists - Reiniciar Checklists ........................ 117 Figura 53. Captura Móvil - Función Checklists - Reiniciar Checklist Actual ............ 117 Figura 54. Captura Tablet - Función Checklists - Opciones de Borrado .................... 117 Figura 55. Captura Tablet - Función Checklists - Confirmación de Borrado ........... 117 8 IÍ ndice de Cuadros Cuadro 1. Descripción de Tareas .................................................................................................36 Cuadro 2. Estimación de Horas por Tarea ...............................................................................38 Cuadro 3. Desvío de Tiempo de Tareas .....................................................................................42 Cuadro 4. Modelo de Descripción de Caso de Uso ................................................................43 Cuadro 5. Modelo de Descripción de Requisito de Datos ...................................................44 Cuadro 6. Modelo de Descripción de Requisito No Funcional .........................................44 Cuadro 7. Modelo de Descripción de Actor..............................................................................44 Cuadro 8. Actor Piloto. .....................................................................................................................46 Cuadro 9. Actor Lector PDF ...........................................................................................................46 Cuadro 10. Actor Servidor Meteo ................................................................................................46 Cuadro 11. Actor Sensores Movimiento....................................................................................46 Cuadro 12. Actor Sensor GPS ........................................................................................................46 Cuadro 13. Req.Datos DAP01 - Avión Seleccionado .............................................................47 Cuadro 14. Req.Datos DAP02 - Estaciones METAR ..............................................................47 Cuadro 15. Req.Datos DAP03 - Notas Guardadas..................................................................47 Cuadro 16. Req.Datos DAP04 - Último VOR ............................................................................47 Cuadro 17. Req.Datos DST01 - Checklists Completadas .....................................................48 Cuadro 18. Req.Datos DST02 - Ìtems Completados..............................................................48 Cuadro 19. Req.Datos DST03 - Último METAR.......................................................................48 Cuadro 20. Req.Datos DST04 - Información FPL ...................................................................48 Cuadro 21. Req.Datos DST05 - Datos Mass & Balance ........................................................49 Cuadro 22. Req.Datos DST06 - Último VOR .............................................................................49 Cuadro 23. Req.Datos DST07 - Última Nota ............................................................................49 Cuadro 24. Req.Datos DST08 - Hora Inicio Vuelo .................................................................49 Cuadro 25. Req.Datos DES01 - Archivo XML del Avión.......................................................50 Cuadro 26. Req.Datos DES02 - Checklists ................................................................................50 Cuadro 27. Req.Datos DES03 - Datos de Mass & Balance...................................................50 Cuadro 28. Req.Datos DES04 - Datos Generales del Avión ................................................50 Cuadro 29. Req.Datos DES05 - Base de Datos VOR...............................................................51 Cuadro 30. Req.Datos DES06 - Archivos XML de FPL's.......................................................51 Cuadro 31. Req.Datos DES07 - Carpeta de Fichas PDF .......................................................51 Cuadro 32. Req.No Funcional RNF01 - Sistema Operativo Mínimo ...............................52 Cuadro 33. Req.No Funcional RNF02 - Interfaz basado en Patrones Google .............52 Cuadro 34. Req.No Funcional RNF03 - Interfaz funcional en Tablets ...........................52 Cuadro 35. Req.No Funcional RNF04 - Facilidad de uso en Vuelo..................................52 Cuadro 36. Req.No Funcional RNF05 - Uso de Recursos ....................................................52 Cuadro 37. Req.No Funcional RNF06 - Código Ordenado ..................................................52 Cuadro 38. Req.No Funcional RNF07 - Cambio de Idioma ................................................53 9 Cuadro 39. Req.No Funcional RNF08 - Reinicio de la Aplcicación .................................53 Cuadro 40. Req.No Funcional RNF09 - Cambio de Avión ...................................................53 Cuadro 41. Caso de Uso PA01 - Mostrar Lista Ítems ............................................................54 Cuadro 42. Caso de Uso PA02 - Marcar Checklist Leídas ...................................................54 Cuadro 43. Caso de Uso PA03 - Usar una Checklist ..............................................................55 Cuadro 44. Caso de Uso PA04 - Ver Ficha Aeropuerto ........................................................56 Cuadro 45. Caso de Uso PA05 - Ver METAR TAF ...................................................................57 Cuadro 46. Caso de Uso PA06 - Rellenar FPL ..........................................................................58 Cuadro 47. Caso de Uso PA07 - Calcula Mass & Balance ....................................................59 Cuadro 48. Caso de Uso PA08 - Añadir Estación Aeropuerto ...........................................59 Cuadro 49. Caso de Uso NV01 - Calcular Posición VOR ......................................................61 Cuadro 50. Caso de Uso NV02 - Cambiar Frecuencia ...........................................................61 Cuadro 51. Caso de Uso NV03 - Usar HSI..................................................................................62 Cuadro 52. Caso de Uso NV04 - Calcular Espera....................................................................62 Cuadro 53. Caso de Uso NV05 - Calcular Interceptación ....................................................63 Cuadro 54. Caso de Uso NV06 - Calcular Punto a Punto .....................................................63 Cuadro 55. Caso de Uso NV07 - Calcular Arco ........................................................................64 Cuadro 56. Caso de Uso NV08 - Ver Instrumentos de Stand-By ......................................65 Cuadro 57. Caso de Uso UT01 - Mostrar Nota ........................................................................66 Cuadro 58. Caso de Uso UT02 - Crear Nota .............................................................................66 Cuadro 59. Caso de Uso UT03 - Borrar Nota ...........................................................................67 Cuadro 60. Caso de Uso UT04 - Convertir Unidades ............................................................67 Cuadro 61. Caso de Uso UT05 - Calcular Datos del Aire .....................................................68 Cuadro 62. Caso de Uso UT06 - Calcular Combustible ........................................................69 Cuadro 63. Caso de Uso UT07 - Usar Cronómetro ................................................................70 Cuadro 64. Caso de Uso UT08 - Ver Información de Vuelo ...............................................70 10 Capı́tulo 1: Introducció n 1.1 Motivación del Proyecto En la última década, los dispositivos móviles han sufrido un gran cambio. Han pasado de ser meros teléfonos portátiles que apenas permitían hablar y enviar mensajes a convertirse en auténticos ordenadores de mano, donde pueden realizarse casi cualquier tipo de tarea computable. Debido a estos avances, la industria del software se ha visto totalmente desplazada hacia estos nuevos dispositivos. Gracias a las facilidades que se dan para desarrollar en estas plataformas se ha conseguido que, sin tener un respaldo de una compañía, un estudiante o recién titulado pueda ser capaz de desarrollar aplicaciones que ayuden a estos a recopilar experiencia e incluso triunfar en la plataforma. Con este panorama resulta muy atractivo realizar un proyecto basado en esta tecnología. Aprovechando la necesidad de realizar un proyecto final de carrera hemos buscado que éste, además de para desarrollar una aplicación que cumpla las necesidades de un sector, pueda servirnos como aprendizaje de esta nueva plataforma y sea el precursor de un estudio mucho más profundo que permita aprovechar todo el potencial que esta tecnología pone a nuestro alcance. En este caso la aplicación que queremos realizar intenta suplir las necesidades que un piloto de aviación ligera (avionetas, ultraligeros, planeadores,…) puedan ser cubiertas, en la medida de lo posible, por un dispositivo móvil. 1.2 Necesidades del Proyecto Antecedentes En el día a día de un piloto la cantidad de documentación, listas de chequeo, reglas de cálculo, datos de aeropuertos, conocimientos de navegación y demás es ingente. Estas hacen que la atención del piloto pueda pasar, de controlar el avión, a basarse en la búsqueda, cálculo o anotación a papel de lo requerido en ese momento, ya sea por necesidad propia o por petición del controlador. Esa cantidad de información que hay que llevar encima se suele intentar llevar lo más ordenada posible, pero la experiencia nos dice que en el transcurso del vuelo, debido al estrés de ciertos momentos, se puede llegar a traspapelar resultando al final en un montón de papeles sueltos y desordenados. 11 Hasta ahora, la mejor forma de evitar que esto ocurriese era mediante un piernógrafo (kneeboard en inglés, ver Figura 1. Piernógrafo, Checklists y CR-3), que es un archivador que se ata a la pierna y contiene departamentos para guardar documentos y está provisto de una plancha de aluminio que permite escribir en él. Éste, sin embargo, sigue sin conseguir que todo quede en su sitio y siempre cuesta mucho tiempo conseguir el papel que se necesita en un momento dado. Otra dificultad que tienen los pilotos se centra en el seguimiento de las llamadas Checklists (listas de chequeo, ver Figura 1). Éstas son una serie de listas, basadas en las distintas partes de un vuelo (inspección pre-vuelo, arranque, rodaje, post despegue,…) que contienen los puntos vitales que deben realizarse. El problema que presentan estas es que, en papel es difícil tener constancia de qué ítems se han realizado y qué ítems no (como ejemplo, este fue uno de los eslabones que condujeron al accidente del Spanair en el Aeropuerto de Barajas en 2008) [1] Otro tipo de entretenimiento que puede sufrir un piloto es en el cálculo de datos, ya sea conversiones, cálculos de velocidad, altitud, rumbos,… que requieren tiempo y concentración para realizarlos. Hasta ahora la herramienta más útil que ha servido a esta necesidad era el Computador de datos CR-3(ver Figura 1), que no es más que una regla circular que permite cálculos gracias a los distintos diales milimetrados que contiene. El problema que tiene este, es que es difícil ser preciso, pues un pequeño desvío entre los diales produce errores significativos (es difícil usarlo en condiciones de turbulencia, por ejemplo). Por otra parte, para la correcta realización de procedimientos de navegación que requieren cálculo de rumbos solo existen algunas reglas mnemotécnicas o el uso de “chuletas” en el piernógrafo. Figura 1. Piernógrafo, Checklists y CR-3 respectivamente También puede llegar a darse el caso, aunque extremo, de quedarse sin algún tipo de instrumentación en el avión, ya sean indicaciones de vuelo (altitud, velocidad, actitud y rumbo) o de navegación (posición respecto radiobalizas, distancias a estaciones, etc.) dejando al piloto totalmente indefenso. La única baza que queda es la experiencia propia y la limitada ayuda de los controladores. Solución Una vez conocemos las necesidades podemos determinar qué debería implementar la aplicación final: • Un sistema que contenga de forma ordenada la documentación de vuelo, tal como fichas de aeropuerto, planes de vuelo, Información 12 • • • Meteorológica, datos recogidos por el piloto, información sobre el vuelo, etc. Una parte que ayude al piloto a realizar las listas de chequeo de forma segura, que impida que se pueda saltar un ítem y que guarde una relación de listas e ítems realizados. Una serie de ayudas para el cálculo de velocidades, rumbos, combustible, carga y centrado, monitorización de procedimientos de navegación, etc. Un sistema que supla la falta de alguno de los instrumentos de vuelo y otro que imite el funcionamiento del sistema de navegación por radiobalizas (limitados estos a los sensores que tiene un dispositivo móvil hoy en día). 1.3 Contexto Como hemos mencionado en la introducción, los dispositivos móviles tienen gran acogida hoy en día. Esto ha propiciado que haya distintas opciones a la hora de elegir el sistema en el que desarrollar. Principalmente hay 3 sistemas distintos: En primer lugar, iOS, propiedad de Apple. Se trata de un sistema cerrado por el que solo se te brinda un kit de desarrollo, se te obliga a seguir ciertas pautas de funcionamiento y ante la posibilidad de publicar la aplicación en el mercado Apple te exige muchos requisitos. Por otra parte los usuarios de iOS tienen más probabilidades de pagar por una aplicación, asé que si el objetivo es puramente económico esta es la opción más segura. En segundo lugar, está el recién salido Windows 8 de Microsoft. El principal problema es que apenas tiene el 5% de cuota de los dispositivos móviles. Como Apple, es un sistema cerrado y solo se te permite desarrollar usando el kit que te ofrecen. En cuanto a la posibilidad de subir la aplicación en su mercado es más fácil que Apple. Su interfaz gráfica es muy atractiva, por lo que podría ser un sistema que tener presente en los próximos años. Finalmente se encuentra Android propiedad de Google entre otras. Su principal ventaja es que es open source casi en su totalidad, así que no solo te limitan al kit de desarrollo que te proporcionan, sino que en teoría es posible añadir funcionalidades al sistema operativo que te permitan realizar acciones que el kit no te ofrece. Otra ventaja es su acogida, al ser libre se monta en infinidad de dispositivos, de distinta marca y de distintos tipos (desde tabletas, a teléfonos, televisores e incluso relojes…). Esto permite que existan dispositivos de todas las gamas y por tanto el número de usuarios sea el mayor de los 3. Además, la total libertad del mercado oficial permite que, en el caso de colocar una aplicación en él, tenga gran probabilidad de ser bajado por los usuarios. Como inconveniente tiene que, si el interés es económico, el perfil de usuario de Android prefiere las aplicaciones gratuitas, y también existe la posibilidad 13 de que puedan ser “crackeados” y se puedan bajar en mercados alternativos de forma gratuita. Como nuestra finalidad es mantener el código de nuestra aplicación abierto, Android parece la opción más apropiada para este proyecto y por ello nuestra aplicación será desarrollada para Android. 1.4 Objetivos del Proyecto Dado que las necesidades del proyecto son ingentes y los créditos de la asignatura marcan una duración de proyecto sobre las 200 horas de trabajo, no será posible realizar una aplicación que cubra todas las necesidades antes mencionadas. Por lo tanto, decidimos acotar el proyecto de forma que diseñaremos todo el conjunto pero solo implementaremos el apartado de Checklists. Así pues, los objetivos del Proyecto fin de Carrera son: • Aprender las bases y el funcionamiento del sistema Android con la finalidad de poder desarrollar la aplicación deseada. • Realizar un Análisis del funcionamiento de una aplicación que supla las necesidades antes mencionadas sin perjuicio de diseñar e implementar ninguna parte. Se tendrá la prioridad de modular el sistema para reutilizar funcionalidades similares. • Diseñar un Interfaz de usuario que sea fácil de usar en vuelo. Debido al entorno en el que se encuentra un piloto se tendrá que hacer hincapié en conseguir que la aplicación sea muy intuitiva y fácil de usar. • Diseñar e Implementar una aplicación Android que ayude al uso de Checklists. Esta permitirá al piloto hacer uso de estas de una forma segura y ordenada. Este comprenderá el objetivo principal del proyecto 1.5 Palabras Clave Android, Dispositivo Móvil, Aviación Ligera, Checklist, XML. 14 Capı́tulo 2: Estudio Previo: El sistema Android En este capítulo se aborda el estudio sobre el sistema operativo Android. Contando su historia, sus principios, arquitectura, funcionamiento y diseño de interfaz. 2.1 Qué es Android Android es un sistema operativo basado en Linux. Está enfocado para ser utilizado en dispositivos como smartphones, tabletas, televisiones, relojes… Lo desarrolla la Open Handset Alliance, liderada por Google. Tiene una gran comunidad de desarrolladores escribiendo aplicaciones. A la fecha, se han sobrepasado las 850.000 aplicaciones disponibles (de las cuales, dos tercios son gratuitas) en la tienda de aplicaciones oficial de Android: Google Play. Existe la posibilidad de obtener software de terceras tiendas o bien externamente. El desarrollo de aplicaciones se realiza en entornos IDE como Eclipse pero se necesita un Kit de desarrollo que proporciona Google que, además del plug-in de Eclipse y una extensa documentación, contiene también un emulador que te permite probar tus aplicaciones sin disponer de un dispositivo físico. Los programas se escriben en Java. No obstante, no se trata de una versión oficial de Java ya que no incluye todos los paquetes. También existe la posibilidad de escribir ciertas rutinas en C++, aunque se destina al desarrollo de librerías o funcionalidades que requieran mucha potencia de computación. Historia [2] En julio de 2006, Google adquirió Android Inc., una pequeña compañía de California fundada en 2003. En aquel entonces, poco se sabía de las funciones de Android fuera de que desarrollaban software para teléfonos móviles. Esto dio pie a rumores de que Google estaba planeando entrar en el mercado de los teléfonos móviles. En Google, un equipo desarrolló una plataforma para dispositivos móviles basada en el núcleo Linux que fue promocionado a fabricantes de dispositivos y operadores con la promesa de proveer un sistema flexible y actualizable. Se informó que Google había alineado ya una serie de fabricantes de hardware y software y señaló a los operadores que estaba abierto a diversos grados de cooperación por su parte. La especulación sobre que el sistema Android de Google entraría en el mercado de la telefonía móvil se incrementó en diciembre de 2006. Diversos medios señalaron 15 que Google quería sus servicios de búsqueda y aplicaciones en teléfonos móviles y estaba muy empeñado en ello. Los medios pronto reportaron que Google estaba desarrollando un teléfono con su marca. En septiembre de 2007, se difundió un estudio de Evalueserve que reportaba que Google había solicitado diversas patentes en el área de la telefonía móvil. El anuncio del sistema Android se realizó el 5 de noviembre de 2007 junto con la creación de la Open Handset Alliance, un consorcio de compañías de hardware, software y telecomunicaciones dedicadas al desarrollo de estándares abiertos para dispositivos móviles. Google liberó la mayoría del código de Android bajo la licencia Apache, una licencia libre y de código abierto. A partir de entonces Android ha ido evolucionando en versiones, a razón de una por año como media. Ha aumentado su cuota de mercado hasta ser el sistema más extendido a nivel mundial entre smartphones. A día de hoy la versión más reciente publicada es 4.2 alias Jelly Bean. Curiosidades El nombre de Android (así como el nombre de los dispositivos Google; Nexus) proviene de la novela Sueñan los androides con ovejas eléctricas? de Phillip K. Dick. que fue llevada al cine como Blade Runner. Cada versión de Android lleva un nombre en clave siguiendo un orden alfabético. Los nombres son todos postres típicos americanos. (Cupcake, Donut, Ecclair, Frozen Yoghurt, Ginger Bread, HoneyComb, Ice Cream Sandwich, Jelly Bean, Key Lime Pie...). El androide verde que se usa como logotipo se llama Andy. 2.2 Características Técnicas Datos obtenidos de Wikipedia [2]: Diseño de dispositivo: La plataforma es adaptable a pantallas de mayor resolución, VGA, biblioteca de gráficos 2D, biblioteca de gráficos 3D basada en las especificaciones de la OpenGL ES 2.0 y diseño de teléfonos tradicionales. Almacenamiento: SQLite y XML. Conectividad: GSM/EDGE, IDEN, CDMA, EV-DO, UMTS, Bluetooth, Wi-Fi, LTE, HSDPA, HSPA+ y WiMAX. Mensajería: SMS, MMS y Android Cloud to Device Messaging Framework (C2DM), parte del servicio de Push Messaging de Android. 16 Navegador web: El navegador web incluido en Android está basado en el motor de renderizado de código abierto WebKit, emparejado con el motor JavaScript V8 de Google Chrome. Soporte de Java: Aunque la mayoría de las aplicaciones están escritas en Java, no hay una máquina virtual Java en la plataforma. El soporte para J2ME puede ser agregado mediante aplicaciones de terceros como el J2ME MIDP Runner Soporte multimedia: WebM, H.263, H.264 (en 3GP o MP4), MPEG-4 SP, AMR, AMRWB (en un contenedor 3GP), AAC, HE-AAC (en contenedores MP4 o 3GP), MP3, MIDI, Ogg Vorbis, WAV, JPEG, PNG, GIF y BMP. Soporte para streaming: Streaming RTP/RTSP (3GPP PSS, ISMA), descarga progresiva de HTML (HTML5 <video> tag), Adobe Flash Streaming (RTMP) (soportado mediante el Adobe Flash Player). Soporte para hardware adicional: Android soporta cámaras de fotos, de vídeo, pantallas táctiles, GPS, acelerómetros, giroscopios, magnetómetros, sensores de proximidad y de presión,, sensores de luz, gamepads, termómetro, aceleración por GPU 2D y 3D. Entorno de desarrollo: El kit de desarrollo Incluye un emulador de dispositivos, herramientas para depuración de memoria y análisis del rendimiento del software. El entorno de desarrollo integrado es Eclipse usando el plugin de Herramientas de Desarrollo de Android. Google Play: Es un catálogo de aplicaciones gratuitas o de pago en el que pueden ser descargadas e instaladas en dispositivos Android sin la necesidad de un PC. Multi-táctil: Soporte nativo para pantallas capacitivas con soporte multi-táctil. Bluetooth: Soporte para A2DF y AVRCP, envío de archivos (OPP), exploración del directorio telefónico, marcado por voz y envío de contactos entre teléfonos. Videollamada: Soportada a través de Google Talk o Aplicaciones de terceros. Multitarea: Multitarea real de aplicaciones está disponible, a diferencia de otros sistemas en la que la multitarea es congelada (Como por ejemplo iOS, en el que la multitarea se limita a servicios internos del sistema y no a aplicaciones externas). Características basadas en voz: La búsqueda en Google a través de voz está disponible como "Entrada de Búsqueda" desde la versión inicial del sistema. Tethering: Soporta tethering, que permite al teléfono ser usado como un punto de acceso alámbrico o inalámbrico. 17 2.3 Arquitectura del Sistema La estructura del sistema operativo Android se compone de aplicaciones que utilizan un framework a través de APIs. En este existen una serie de librerías Java que se ejecutan en una máquina virtual (Dalvik) en traducción dinámica (JiT). Tanto la Maquina Dalvik como algunos componentes del Framework acceden a las librerías nativas, escritas en C o C++, mediante un interfaz llamado JNI (Java Native Interface). Estas librerías nativas acceden al kernel de Linux a través de una capa de abstracción Hardware (HAL) para usar las funcionalidades de los drivers de los dispositivos necesarios. En la siguiente figura (Figura 2) se puede ver la estructura de Android. Figura 2. Esquema de la Arquitectura de Android [3] Podemos resaltar: Aplicaciones: Las aplicaciones base incluyen un cliente de email, programa de SMS, calendario, mapas, navegador, contactos, etc. Es aquí donde se colocan las aplicaciones desarrolladas por terceros. Todas las aplicaciones están escritas en Java y tienen la misma prioridad unas sobre otras. 18 Framework de aplicaciones: Los desarrolladores tienen acceso completo a las API’s del framework usado por las aplicaciones. La arquitectura está diseñada para simplificar la reutilización de componentes; cualquier aplicación puede publicar sus capacidades y cualquier otra aplicación puede luego hacer uso de ellas (sujeto a reglas de seguridad). Éste mismo mecanismo permite que los componentes sean remplazados por el usuario. Este framework está formado, entre muchas otras, por: • • • • • • Un extenso conjunto de Vistas tales como listas, cajas de texto, botones… Content Providers: Permiten a las aplicaciones acceder a información de otras aplicaciones o compartir su propia información. Resource Manager: Proporciona acceso a recursos que no son código como pueden ser gráficos, cadenas de texto, imágenes… Notification Manager: Permite a las aplicaciones mostrar alarmas personalizadas en la barra de estado. Activity Manager: Gestiona el ciclo de vida de las aplicaciones. … Librerías Nativas: Android incluye un set de librerías C/C++ usadas por varios componentes del sistema. Éstas se exponen a través del framework de aplicaciones de Android. También el Runtime de Android interactúa con las librerías mediante el JNI (Java Native Interface). Algunas son: System C library (implementación librería C estándar), librerías de medios, librerías de gráficos, OpenGL ES, SQLite, entre otras. Runtime de Android: Android incluye un set de librerías base que proveen la mayor parte de las funcionalidades disponibles en Java. Cada aplicación Android corre su propio proceso, con su propia instancia de la máquina virtual Dalvik. Dalvik es una Máquina Virtual Java específicamente diseñada para Android y dispositivos móviles. Su objetivo, aparte de ejecutar la aplicación Java, es tener en cuenta el uso de recursos, memoria y batería; cosas que en un dispositivo móvil son limitadas. Ha sido escrito de forma que un dispositivo pueda correr múltiples máquinas virtuales de forma eficiente. HAL (Hardware Abstraction Layer): Aunque su traducción es capa de Abstracción de Hardware no es una capa estanca en sí. Esta está integrada en parte en las librerías nativas y parte en el kernel. Facilita la comunicación entre los componentes y las librerías. La desarrolla Google para un dispositivo inicial y luego cada fabricante la modifica para hacerla compatible con sus dispositivos. En las últimas versiones de Android se ha mejorado este apartado. Kernel Linux: Android depende del núcleo Linux 2.6 para los servicios básicos del sistema como: seguridad, gestión de memoria, gestión de procesos, pila de red y modelo de drivers. 19 2.4 Almacenamiento de Datos En aplicaciones de escritorio, el sistema operativo ofrece el sistema de ficheros para guardar o compartir datos entre aplicaciones. En Android, los ficheros son privados por aplicación, es decir, solo la aplicación que crea estos datos o para la cual existen pueden usarlos. Esto soluciona las dependencias que cualquier aplicación en Android pueda tener con otra pero tiene como inconveniente que no hay compartición de datos de forma inmediata. Para evitar este inconveniente se provee (desde el framework de aplicaciones) el llamado Content Provider (ver más adelante). Android tiene 3 tipos de almacenamiento de datos: Preferences: Es la forma más rápida y sencilla de guardar datos simples. Estos se guardan en pares (llave/valor) y se almacenan en la memoria interna del dispositivo hasta que son modificadas por el usuario. Quiere decir que ante el cierre de una aplicación estos no se perderán. Entre los datos que se pueden guardar tenemos: Boolean, Float, Strings, etc. Local Files: Esta forma es similar al almacenamiento de datos de un escritorio Linux estándar, con la salvedad de que solo la aplicación en desarrollo tendrá acceso a estos. Para acceder o crear los archivos se usan Streams como en Java y, aunque por defecto se guardan en la memoria interna existe la posibilidad de hacerlo en la externa (Tarjeta SD). Aquí, por supuesto puede haber cualquier tipo de archivo; Texto llano, XML, HTML, propios... Database: Consiste en una implementación de bases de datos SQL llamada SQLite. Es soportada nativamente por Android y tiene como ventaja que es ligera y no requiere recursos excesivos. La forma de compartir estas es a través de Content Providers. 20 2.5 Estructura de una Aplicación Una aplicación en Android se puede definir como un programa escrito en Java que utiliza el framework de aplicaciones a través del SDK (Software Development Kit) para satisfacer las necesidades de un usuario mediante el uso de una interfaz gráfica que se puede componer de distintas vistas y sub programas. Cada aplicación tiene: • Una instancia propia de la máquina virtual Dalvik • Por tanto, su propio espacio de memoria. • Un proceso de Linux asociado exclusivamente a ella. • Un ID de usuario de Linux asignado (el cual es el único que tiene permisos para acceder a los datos de esta) • Una aplicación puede tener 2 threads (el principal (donde se gestiona la UI y otro opcional para operaciones más costosas) Google ha optado por una modularización de las aplicaciones, por lo que estas se dividen en distintos componentes que, según el ámbito del objetivo de la aplicación a desarrollar, hará uso de ellos o no. A continuación se nombran los más importantes: Activity Es el elemento constituyente de Android más común. Básicamente define una pantalla (su UI) en el dispositivo y le da funcionalidad. Para implementarla se utiliza una extensión de la clase Activity (una por cada Actividad). Cada clase mostrará una interfaz de usuario, compuesta por Views (los distintos tipos de componentes de un interfaz gráfico). Cada vez que se cambia de pantalla (Vista), se cambia de Actividad. Cuando cambiamos de Vista, la anterior queda pausada y puesta dentro de una pila de actividades para poder retornar en caso necesario. Para pasar de vista en vista, Android utiliza los Intents. En las últimas versiones de Android (a partir de 4.0 Ice Cream Sandwich) se ha añadido otro componente llamado Fragment que vive dentro de una Activity. Se comporta igual que una actividad (en el sentido de tener una View, comportamiento y ciclo de vida propios), pero al estar anidada dentro de una Activity consigue que el número de Activities de la aplicación sea menor y se usa para tener distintas Interfaces gráficas en una misma pantalla (pensando en las tablets).Para más información sobre este componente ver Android Developers [4]. Intent Es un mecanismo para el paso de mensajes. Declara la intención de realizar una acción. Se utilizan para iniciar Activities o para comunicarse entre ellas. Las dos partes más importantes de un Intent son la acción que se quiere realizar y la información necesaria que se proporciona para poder realizarla ya sea en formato URI o mediante extras (pueden contener cualquier tipo de variable o una clase que implemente Parcelable [4]). 21 Intent Filter Es una descripción de qué Intents puede gestionar una Actividad. Mediante los Intent Filters, el sistema puede resolver Intents que una aplicación pide, buscando cuales posee cada actividad y escogiendo aquel que mejor se ajuste a sus necesidades. El proceso de resolver Intents se realiza en tiempo real, lo cual ofrece dos beneficios: • • Las actividades pueden reutilizar funcionalidades de otros componentes haciendo peticiones mediante un Intent. Las actividades pueden ser remplazadas por nuevas actividades con los mismos Intent Filters (siguiendo el principio de igualdad entre aplicaciones). Service Es un componente que se ejecuta durante un largo periodo y que no tiene UI, por lo que se ejecuta de forma transparente. Por ejemplo un reproductor de música que reproduce una canción sin que el usuario, por el hecho de abrir una nueva vista, el reproductor se interrumpa. Content Provider Como hemos mencionado antes, Android tiene la capacidad de manejar Bases de datos con SQLite pero las aplicaciones externas no pueden acceder a estas BBDD. En caso de querer compartir dicha información con otras aplicaciones se utiliza un Content Provider. Un Content Provider es, por tanto, un componente que permite a otras aplicaciones guardar y obtener la información que maneja dicho Content Provider. Broadcast Receiver Es otro componente que se puede implementar en una aplicación. Realiza una acción ante un mensaje de difusión del sistema (Intent Broadcast). Carece de UI aunque puede mostrarse a través de la barra de estado (Notification Manager). Atiende a las señales que se hayan especificado en su Intent Filter. Ejemplos de Intent Broadcasts son: Recepción de una llamada, aviso de batería baja, activación/desactivación del Wifi/Bluetooth,… 22 2.6 Ciclo de Vida de una Activity Como anteriormente hemos nombrado (Punto 2.5), cada aplicación de Android corre en su propio proceso que se crea cuando se ejecuta por primera vez y permanece en memoria hasta que la aplicación deja de trabajar o el sistema necesita memoria para otras aplicaciones. Una característica peculiar en Android es que el ciclo de vida de una Activity no lo controla la aplicación sino que lo determina el sistema, mediante el Activity Manager, a partir de una serie de condiciones como son: aplicaciones que están funcionando en ese momento, prioridad que tienen para el usuario y memoria disponible en el sistema. Así Android sitúa cada proceso en distintos estados basándose en las condiciones anteriores. Dentro del proceso de una aplicación pueden existir varias Activities, pero el estado del proceso depende de la que esté activa, de forma que, podemos relacionar el estado de la Activity (Starting, Running, Paused, Stopped y Destroyed) con el estado del proceso (Foreground, Visible, Background y Empty). Los estados posibles Activity (Proceso) son: Running (Foreground Process): El estado que tiene la Activity cuando está en primer plano, es decir, se muestra su UI en la pantalla y el usuario puede interactuar con ella. El sistema deja como última opción a eliminar en caso de falta de memoria. Paused (Visible Process): En este estado la aplicación está visible pero alguna instancia ha aparecido delante de ella requiriendo la atención del usuario y dejando congelada la UI de la aplicación principal. Un ejemplo típico es la ventana de diálogo (pidiendo una confirmación), esta pasa a estar en Running y la aplicación principal pasa a Paused. El sistema solo eliminaría un Visible Process si no tuviera recursos suficientes para mantener el proceso activo en ese momento. Stopped (Background Process): Estado en el que se encuentra una aplicación cuando deja de estar visible al usuario. Ocurre cuando se cambia entre distintas aplicaciones; la aplicación se para y se guarda en una pila para poder volver a ella posteriormente. El sistema ante la necesidad de recursos elimina en primera instancia las Activities que se hallan dentro en esta cola. Starting/Destroyed (Empty Process): Es un proceso que no aloja ningún componente. La razón de existir de este proceso es tener una cache disponible de la aplicación para su próxima activación. Se crea la primera vez que se ejecuta la aplicación. Es común que el sistema elimine este tipo de procesos con frecuencia para obtener recursos. 23 Para el desarrollador, la forma de saber en qué estado se encuentra una Activity se realiza mediante la sobrecarga de una serie de métodos que el sistema llama cuando cambia entre estados. Figura 3. Ciclo de Vida de Activity [5] En esta figura (Figura 3) podemos diferenciar 3 periodos (lifetime) en la vida de una Activity: • • • Entire Lifetime: Es la vida completa de la aplicación desde que se crea hasta que se destruye. La determinan onCreate() y onDestroy(). Visible Lifetime: Es el periodo de vida de una Activity donde la aplicación es visible pero no activa. Determinada por onStart() y onStop() Foreground Lifetime: La parte de vida en la que la Activity es visible y activa. Lo determina onResume() y onPause(). 24 2.7 Resources Los recursos (Resources) en Android son archivos externos que no son código y que son usados e incluidos dentro de la aplicación. Android soporta distintos tipos de recursos como imágenes, textos, layouts, audio, videos… Estos recursos se organizan por carpetas según el tipo de recurso que representan. Entre los más importantes se encuentran: • • • • • • Drawable: Imágenes, Iconos… Layout: Organización de los interfaces gráficos de usuario (en XML) Values: Textos, colores, dimensiones, estilos, ... (en XML) Menú: Menús y diálogo (en XML) XML: Resto de archivos XML que no soporta nativamente Android. Raw: Recursos que se copian en la aplicación sin un proceso previo Los ficheros XML se compilan dentro un archivo binario por razones de eficiencia y los strings se comprimen en una forma más eficiente de almacenamiento. Es por esta razón que hay diferentes tipos de recursos en Android. 2.8 Android Manifest El Android Manifest es un archivo XML (AndroidManifest.xml) que forma parte de una aplicación Android y que contiene aspectos principales de la aplicación, como: • • • • • • Identificación (Nombre, versión, icono, paquete Java asociado,…) Componentes (Activities, Servicios, Clases, Intent Filters…) Permisos que necesita la aplicación para su ejecución. Lista de librerías necesarias. Requisitos mínimos del dispositivo. … 25 2.9 Interfaz de Usuario En este apartado se muestra la filosofía de diseño de Interfaces gráficos en Android [4] y vemos los componentes más destacados. Principios de Diseño Durante los primeros años de Android, los desarrolladores siempre han tenido la libertad de diseñar sus interfaces gráficos. Esto tiene el inconveniente de que cada aplicación funciona de una manera y no existían unos patrones oficiales que seguir. Desde el lanzamiento de Android 4.0 Ice Cream Sandwich, Google ha empezado a promover unos patrones de diseño, que si bien no son obligatorios, sí se recomiendan con el fin de facilitar el uso de los usuarios. Estos patrones se basan en 3 principios dirigidos al usuario: Enchant Me (Haz que me Encante): La aplicación debe ser atractiva, sencilla y personalizable. Para ello recomiendan: • • • • Dejar que el usuario pueda personalizarla. Usar iconos en vez de botones y menus. Usar efectos sutiles que ayuden a entender el funcionamiento Aprender del usuario Simplify My Life (Simplifica mi Vida): El principal objetivo de una aplicación es facilitar al usuario una tarea. Tiene que ser intuitiva y fácil de usar. Tareas sencillas no deben de requerir pasos complicados y las complicadas deben automatizarse teniendo en cuenta el usuario. Se debe evitar añadir demasiadas opciones o alertas. Estos objetivos se consiguen siguiendo: • • • • • • • • Uso de frases cortas y directas. Usar fotos en vez de palabras. Evitar demasiadas preguntas. Decidir por el usuario pero dejar que tenga la última palabra. Mostrar sólo lo necesario y sólo cuando lo necesite. Ayudar al usuario a saber en qué parte de la aplicación se encuentra. Guardar opciones y recordar preferencias. Evitar que componentes parecidos se comporten de distinta forma (If it looks the same, it should act the same). Sólo interrumpir al usuario si es importante. 26 Make me Amazing (Hazme increíble): Además de ser fácil de usar, debe animar al usuario a aprender y probar nuevas formas de usar sus aplicaciones. Debe de posibilitar al usuario el acceso a las nuevas tecnologías con claridad y elegancia. Conceptos que pueden ayudar a este objetivo serían: • • • • Hacer la aplicación más fácil de aprender aprovechando patrones visuales y el comportamiento de otras aplicaciones de Android. Evitar abrumar al usuario con palabras técnicas y no echarle la culpa cuando hay problemas; en vez de eso indicarle instrucciones. Permitir al usuario hacer acciones avanzadas simplificando y automatizando el proceso. Decidir lo más importante de cada aplicación y conseguir que sea fácil de encontrar, fácil de usar y rápido de hacer. Patrones de Diseño Para conseguir los objetivos se han diseñado una serie de patrones que facilitan al desarrollador la tarea de tener que pensar en cómo conseguirlos. Gestos: Los gestos táctiles disponibles son: • • • • • • Toque: Toque Largo: Deslizar: Arrastrar: Doble toque: Pinzar: Para activar la funcionalidad normal. Activar el modo selección de datos. Para navegar en componentes de la misma jerarquía. Para mover componentes. Para activar una funcionalidad secundaria. Para hacer zoom. Estructura del Interfaz: El interfaz debe tener 3 jerarquías: • • • Nivel Principal: En él se deben mostrar las funcionalidades que tiene la aplicación Vistas de Categoría: Aquí deben estar los elementos de una misma categoría del nivel superior. Vista Detalle: Aquí es donde se realiza la acción y el usuario consigue lo que quiere. Navegación: Para moverse por los menús existen (asumiendo el toque) dos botones; el botón Back y el botón Up. • • Back (Rojo): Vuelve una ventana atrás en la pila de Activities, de forma muy parecida al botón Atrás de un navegador de Internet (Figura 4). Up (Nanranja): Sube un nivel en la jerarquía de la aplicación. Parecido al botón subir del Explorador de Windows (Figura 4). 27 Figura 4. Navegación en Android [4] 28 Action Bar: Es un patrón de diseño colocado en la parte de arriba de una aplicación, y que normalmente es persistente (no desaparece en las distintas vistas): • • • Muestra la localización del usuario dentro de la aplicación y permite el movimiento en esta. Permite el uso de funcionalidades frecuentes de forma accesible. Permite agrupar funciones menos frecuentes en un Action Overflow (menú donde se agrupan funcionalidades) Tiene una organización de elementos definida (Figura 5): Figura 5. Componentes de Action Bar [4] 1. App Icon (Botón Up): Muestra el icono de la aplicación y sirve (aparte de personalizar la aplicación) para indicar si el usuario se encuentra en el nivel más alto o no de la jerarquía de la aplicación. Para ello muestra un “<” cuando no lo está. Presionar el botón produce que el usuario suba en la jerarquía. 2. View Control: Sirve para nombrar la Activity actual y/o para permitir moverse por la aplicación dándole distintas funcionalidades (Spinner [lista desplegable], Tabs [Pestañas], o Drawer [Menú Deslizable]). 3. Action Buttons: Debe mostrar las acciones más importantes para la aplicación. El número de estos dependerá del tamaño de la pantalla del dispositivo. 4. Action Overflow: Al presionar sobre él se muestra una lista desplegable de elementos que no se usan tan a menudo. El Action Bar también puede partirse en dos, con la parte superior y una en el inferior de la pantalla para permitir más botones y para soportar distintos tipos de dispositivos. Multi-Pane Layout: Una de las cosas a tener en cuenta es que, debido a la gran gama de dispositivos que existen, el interfaz se debe ajustar a multitud de tamaños y resoluciones. Para ello se usa un DPI (Dots per Inch) base y usando dp’s (Density Independent Pixels) se puede escalar sobre él. Google sugiere que hay que aprovechar las pantallas grandes añadiendo nuevas vistas en vez de solo agrandar el interfaz. Para ello existe el Multi-Pane Layout. Es la utilización de distintos tipos de GUI dependiendo de las características del dispositivo en el que se ejecuta la aplicación. 29 En terminales pequeños solo se mostrará una vista por pantalla, y en el caso de disponer de una pantalla grande, las distintas vistas se colocarían una al lado de otra: Un móvil tendría este Layout (Figura 6): Figura 6. Layout de una App en un móvil [4] Una Tablet las juntaría en una sola pantalla (Figura 7): Figura 7. Layout de una App en una Tablet [4] También hay que tener en cuenta el cambio de orientación del dispositivo que permite un tipo de distribución distinto. En Android te recomiendan 4 tipos de recomposición de la pantalla: • Show/Hide: Sería seguir el mismo patrón que cuando se dispone de móvil o tablet (se mostraría en apaisado ambas vistas (como la Figura 7), pero en vertical solo se vería una (Figura 6)). 30 • • • Stretch/Compress: Sencillamente estrechar o ensanchar los componentes que existen (esto ocurre de manera automática en la mayoría de los casos) Stack: Los componentes se redistribuyen para optimizar el cambio de orientación. Expand/Collapse: La vista de la izquierda mostraría solo los datos importantes (en la Figura 7 mostraría los nombres ocultando las imágenes). Menú Selección: En versiones anteriores de Android (<3.0 Honeycomb) se utilizaba un modo de selección similar al de un escritorio (mediante un menú contextual). Esto se cambia por un menú de selección. Al mantener presionado un ítem en una lista, el ActionBar cambia a Contextual Action Bar (CAB) y este permite realizar acciones contextuales sobre uno o varios ítems de la vista; como puede ser seleccionar, copiar, cortar, pegar, borrar,… Confirmación y Acuses: Google es muy explícito en cuanto a cuándo debe ser avisado o “molestado” el usuario durante el funcionamiento de la aplicación. Existen dos formas de avisar a un usuario: Mediante una confirmación (Dialog), donde el usuario debe tomar una decisión; o un acuse (Toast), donde el usuario es avisado sobre una acción que la aplicación ha realizado. Los patrones señalan que hay que pedir confirmación solo en casos como (pérdida irrecuperable de datos, cargos en tarjetas, uso intensivo de Internet, largas esperas,…) Los casos donde hay que evitar informar al usuario son aquellos que no aportan nada al usuario o donde existe otro tipo de feedback. Notificaciones: El sistema de notificaciones permite a una aplicación mantener informado al usuario sobre eventos como mensajes nuevos, citas de calendario, etc. Las notificaciones se muestran en la barra de estado del teléfono y se acceden arrastrando ésta hacia abajo. Como mínimo una notificación debe contener lo señalado en la Figura 8: Figura 8. Layout de una Notificación [4] 31 En la última versión de Android (4.2 Jelly Bean) se han añadido funcionalidades a las notificaciones como: Vistas Expandidas (se puede ampliar el espacio de una notificación para que muestre más información), acciones (se le pueden añadir botones para realizar distintas acciones) y se añade un sistema de Prioridades (se les da a las notificaciones una prioridad en función de su importancia). Widgets: Son mini aplicaciones que se muestran en la pantalla principal del sistema (Home). Se pueden implementar para cualquier aplicación, pero solo se recomienda usar para aquellas que requieran un uso intensivo por parte de los usuarios. Settings (Preferencias): Es un lugar de la aplicación donde los usuarios indican sus preferencias y cómo quieren que la aplicación se comporte. El menú de Settings se debe encontrar dentro del Action Overflow. Los principios de Android aconsejan evitar meter dentro de Settings información o acciones. También ajustes que la mayoría de los usuarios no vayan a modificar siempre y cuando esto no repercuta negativamente a las minorías que sí lo usarán. Si las opciones son muchas se pueden agrupar mediante divisores o mediante sub menús. Google recomienda usar un lenguaje llano y directo, sin entrar en tecnicismos. Componentes Básicos Android ofrece una serie de componentes (Views) para diseñar las Interfaces de Usuario. Entre las más comunes están: • • • • • • • • • • • Tabs: Es una pestaña. Se alojan en la Action Bar Permite cambiar de Vistas rápidamente. Existen dos tipos: Scrollable y Fixed. Lists: Consiste en una lista de ítems de puestos verticalmente. Scroll Indicator: Permite mover y saber la posición del usuario en una interfaz cuando ésta es más grande (verticalmente) que la pantalla. Spinners: Es una lista desplegable igual que en otros sistemas. Buttons: Botones que realizarán una acción al ser pulsados Text Fields: Espacio donde se permite al usuario escribir en él. Seek Bars & Sliders: Se utilizan para seleccionar un valor contínuo o discreto de una forma más gráfica que escribiendo el valor. Progress Bar & Activity Circle: Muestran al usuario que el sistema está haciendo algo que requiere tiempo en completarse. Switches, Checkbox & RadioButton: Controles que activan o desactivan una función, un valor individual, o un valor entre varias opciones. Dialogs: Ventana que se muestra para solicitar algo al usuario. Pickers: Ruleta que permite seleccionar un valor dentro de un conjunto. Para más información sobre el UI se puede acceder a Android Developers [4] 32 2.10 Entorno de Desarrollo Google, desde antes incluso del lanzamiento de Android, ofreció a los desarrolladores un kit de desarrollo para facilitarles la programación. En este punto se describe esta herramienta. Componentes El Entorno de desarrollo se ha diseñado para usarse utilizando IDE’s. El IDE en el que Google recomienda programar es Eclipse por su filosofía Open Source, como por su amplio reconocimiento entre los desarrolladores. La versión de Eclipse más adecuada para Android es Eclipse for Mobile Developers, ya que contiene paquetes para Java, y C/C++ en caso de necesitar programar en lenguaje nativo (se puede descargar desde www.eclipse.org). El siguiente componente necesario es el kit de desarrollo de Java, el Java Development Kit que se descarga de la página oficial de Oracle (www.oracle.com). Este contiene las librerías y API’s necesarios para programar en Java. Por parte de Google se nos ofrece el antes mencionado Kit de desarrollo (Android Software Development Kit) disponible desde la página de Android Developers [4]. Se compone de varias partes: • • • • • Paquete con todas las librerías específicas de Android, API’s y demás archivos necesarios para poder programar una Aplicación. SDK Manager: Un programa que ayuda a mantener las distribuciones del Kit actualizadas. AVD Manager: Una Máquina Virtual que simula un dispositivo Android según los requerimientos del desarrollador. Software para la depuración de las aplicaciones(en línea de comandos). Drivers y software para la comunicación con dispositivos reales. (en línea de comandos). Por último un plug-in de Eclipse (u otras IDE’s alternativas) que ayuda en la comunicación entre el IDE y el SDK de Android. Ayuda al desarrollador en el trabajo: • • • • • • Facilitando la compilación de los proyectos. Ofreciendo ayuda en el editor de texto rellenando campos y creando código prefabricado. Mostrando documentación de Android para el recurso seleccionado Dotando de interfaces gráficas para el software de depuración. Facilitando el uso de dispositivos físicos. … 33 Capı́tulo 3: Planificació n En este capítulo realizamos una estimación de recursos materiales y humanos, costes y una planificación temporal del proyecto para, una vez se ha finalizado el proyecto, contrastar las diferencias con los costes y tiempos reales. En el Anexo E se describe una planificación de todo el proyecto si se tuviese intención de implementar todas las funcionalidades de la aplicación. 3.1 Estimación de Recursos Materiales En este apartado consideramos recurso material a todo objeto, dispositivo, ordenador y software necesario para la realización del proyecto. Recursos Físicos Ordenador de Sobremesa del alumno: Donde se realiza casi la totalidad del proyecto exceptuando pruebas reales. Adquirido en el año 2006. Sus características más destacables son: • • • • • Procesador AMD Athon 64 X2 4200+ Placa Base Asus A8RN32 2 GB de RAM DDR 1TB de Disco Duro SATA2 Tarjeta Gráfica ATI Radeon HD3870 (512 MB VRAM) Dispositivo móvil del alumno: Será necesario para la etapa de pruebas. Su sistema operativo está modificado tal que puede hacerse pasar por Tablet y mostrar el contenido de las aplicaciones de igual forma que lo haría con una Tablet real. Adquirido en 2010, sus características son: • • • • • • Marca y modelo : HTC Desire (HTC Bravo/G7) System on Chip Qualcomm Snapdragon S1 (QSD8250) Procesador ARM7 1Ghz (del SoC) Acelerómetro (3 ejes) y Brújula (3 Ejes) Pantalla AMOLED de 3.7’’ (480x800) 250dpi Android 4.2 Jelly Bean (Modificación por Paranoid Android) 34 Segundo Dispositivo Móvil: Adquirido en 2012 • • • • • Marca y modelo : Sony Xperia S (LT26i) System on Chip Qualcomm Snapdragon S3 (MSM8260) Procesador ARM7 1.5Ghz DualCore Acelerómetro (3 ejes), Giróscopo y Brújula (3 Ejes) Pantalla SLCD de 4.3’’ (720x1280) 340dpi • Android 4.0 Ice Cream Sandwich Tablet: Disponible bajo pedido, será de utilidad en el testeo final para confirmar el buen comportamiento que presenta la aplicación en la HTC en modo Tablet. • • • • • • Marca y modelo : ASUS Transformer (TF101) System on Chip NVIDIA Tegra 2 (T20) Procesador ARM7 1Ghz DualCore (Cortex-A9) Acelerómetro (3 ejes), Giróscopo y Brújula (3 Ejes) Pantalla IPS LCD de 10.1’’ (1280x800) 150dpi Android 4.0 Ice Cream Sandwich Avioneta en régimen de alquiler: En caso de que se estimase necesario, y si las pruebas realizadas con simulador no se vieran suficientes, existe la posibilidad de probar la aplicación en un entorno real. Recursos de Software Sistema Operativo Windows 7 Home Premium: Sistema Operativo instalado en el Ordenador de Sobremesa. Licencia de 2010. Eclipse IDE for Mobile Developers + Android Plug-in: Utilizado para la implementación de la aplicación Eclipse Modeling Tools: Separado del IDE del proyecto, se utiliza para la creación de Diagramas UML durante la fase de Diseño. Java Development Kit 7: Necesario para la utilización del IDE. Android SDK: Software proporcionado por Google para el desarrollo de aplicaciones Android y posterior testeo. Microsoft Office 2010: Adquirido en 2010. Se utiliza para la redacción de la memoria y sus anexos. PDF Creator: Herramienta gratuita para convertir archivos a PDF. Chrome: Explorador de Internet utilizado para la búsqueda de información. 35 Servicio Google Drive: Para mantener la memoria actualizada y disponible al alumno y al tutor en cualquier momento. X-Plane X: Simulador de vuelo utilizado para la prueba del dispositivo en condiciones simuladas. Open Workbench: Planificador de Tareas. Utilizado para la planificación temporal. Balsamik Mockups: Programa para la creación de bocetos de interfaces gráficos. 3.2 Planificación Temporal Identificación de Tareas Conocidos los objetivos de nuestro proyecto podemos determinar la serie de tareas de la que se compondrá el proyecto final enumerados en el siguiente Cuadro 1: Fase Estudio Previo Planificación Análisis Diseño Implementación Pruebas Documentación Tarea a Desempeñar Repaso de conceptos de Programación OO y Java Documentación General sobre Android Estudio de Manuales para Desarrolladores Android Instalación del Entorno (Java JDK, Eclipse y Android SDK) Familiarización del Entorno Eclipse-Android Estudio de Necesidades del Piloto Planificación del Proyecto Definición de Funcionalidades Estudio de Conceptos Aeronáuticos Necesarios Elaboración del Modelo de Casos de Uso Realización de los Casos de Uso Diseño de la Interfaz de Usuario Diseño funcional y de datos de las Checklist Implementación de la Interfaz de Usuario Implementación de la funcionalidad de Checklists Pruebas de Funcionamiento Prueba en Simulador o Real Realización de la Memoria Redacción del Manual de Usuario Cuadro 1. Descripción de Tareas A continuación pasamos a detallar algunas de las tareas: Repaso de conceptos de Programación OO y Java: Dado el tiempo de inactividad por parte del alumno en el campo de la informática es necesario un repaso sobre los conceptos básicos de Programación Orientada a Objetos así como un recordatorio sobre la sintaxis y particularidades del lenguaje Java, ya conocido por el alumno. 36 Documentación General sobre Android: Consiste en la recopilación de información sobre el sistema Android, funcionamiento en dispositivos, datos sobre sus posibilidades, etc. Estudio de Manuales para Desarrolladores Android: Lectura y ejecución de ejercicios de libros sobre el desarrollo en la plataforma Android donde se aprende la forma de programar, recursos disponibles para el desarrollo, pautas de diseño, etc. Estudio de Necesidades del Piloto: Antes de poder definir las funcionalidades de la aplicación hay que conocer las tareas que realiza un piloto a bordo de un avión. Para ello se cuenta con la experiencia propia del alumno así como con la aportación de otros profesionales del campo. Definición de Funcionalidades: En base a las necesidades, se acotan las necesidades que van a ser una futura funcionalidad de la aplicación. Estudio de Conceptos Aeronáuticos Necesarios: Conocidas las funcionalidades que tendrá el sistema se pasa al estudio de la teoría necesaria para poder diseñar dichas funcionalidades. Dado que el alumno conoce la mayoría de la teoría a aplicar no supondrá un coste temporal alto como sí lo sería para cualquier otro programador. Elaboración del Modelo de Casos de Uso: Creación del esquema principal de la aplicación vista desde el modelo de Casos de uso. Realización de los Casos de Uso: Se toman los casos de uso especificados en el modelo y se detallan uno a uno indicando dependencias, precondiciones, pasos, postcondiciones, etc. Diseño de la Interfaz de Usuario: Diseño del Interfaz mediante Mock-ups (dibujos) de toda la aplicación. Diseño funcional y de datos de las Checklists: Diseño Funcional de la aplicación principal y la parte de Checklists incluyendo dependencias de datos. Implementación de la Interfaz de Usuario: Implementación de la Activity Principal y del apartado de Checklists. Prueba en Simulador o Real: Pruebas usando el simulador de vuelo. Si en ese momento se estimase oportuno también se realizaría una prueba en un vuelo real. 37 Estimación de Tiempos Para cada tarea se ha calculado un tiempo de duración siguiendo el algoritmo PERT [6], que calcula en base a una estimación probable, una optimista y otra pesimista. Calculadas estas nos quedaría una relación de horas tal que (Cuadro 2): Tarea a Desempeñar Tiempo Estimado Repaso de conceptos de Programación OO y Java 4 Horas Documentación General sobre Android 6 Horas Estudio de Manuales para Desarrolladores Android 33 Horas Instalación del Entorno 3 Horas Familiarización del Entorno Eclipse-Android 3 Horas Estudio de Necesidades del Piloto 4 Horas Planificación del Proyecto 14 Horas Definición de Funcionalidades 8 Horas Estudio de Conceptos Aeronáuticos Necesarios 8 Horas Elaboración del Modelo de Casos de Uso 5 Horas Realización de los Casos de Uso 27 Horas Diseño de la Interfaz de Usuario 19 Horas Diseño funcional y de datos de las Checklist 24 Horas Implementación de la Interfaz de Usuario 21 Horas Implementación de Checklists 33 Horas Pruebas de Funcionamiento 8 Horas Prueba en Simulador o Real 4 Horas Realización de la Memoria 32 Horas Redacción del Manual de Usuario 8 Horas Total Horas Estimadas 264 Horas Cuadro 2. Estimación de Horas por Tarea Hitos Los hitos son objetivos intermedios durante la ejecución de un proyecto. Sirven para poder evaluar el desarrollo del mismo. En este caso se han tomado como hitos los siguientes puntos: • • • • • • H1: Fin del estudio Previo. H2: Fin del Análisis del Proyecto. H3: Fin del Diseño del Proyecto. H4: Fin de la implementación. H5: Fin de la Fase de Pruebas. H6: Fin de la Redacción de Documentación. 38 Relaciones entre Tareas Una vez definidas tareas e hitos podemos relacionarlos de forma que se pueda ver gráficamente las dependencias que tienen unos sobre otros. Para ello hemos utilizado una red de Actividades (Figura 9). Las actividades son nodos rectangulares, y la relación de precedencia entre ellas se representa mediante una flecha. Los hitos son dibujados como círculos. Figura 9. Red de Actividades Estimación de Fechas Para la realización del proyecto se ha tenido en cuenta un calendario adecuado a la actividad del alumno. Se ha establecido una jornada de 3 horas diarias, 4 días a la semana. Esto supone 48 horas al mes. Para tener mejor exactitud en el cálculo, se han tenido en cuenta los festivos nacionales y los de la localidad de Castellón de la Plana desde Noviembre a Junio (Todos los santos, Puente de la Constitución, Navidad, Nochevieja, Epifanía, Magdalena, San José, Pascua y Día del Trabajador). Suponiendo una fecha de inicio de Proyecto el 01 de Octubre de 2012 la fecha de finalización debería acercarse al 13 de Abril de 2013, siendo el número total de días transcurridos de 244. 39 Debido a que solo existe un desarrollador (el alumno) se descarta una impresión del diagrama de Gantt. En este caso solo representa una sucesión de tareas y se considera información superflua. Tampoco se considera un cálculo del camino crítico por la misma razón pues cualquier tarea que se retrase implica un retraso sobre el proyecto. 3.3 Estimación de Costes Aunque el coste económico del proyecto sea nulo debido a que se trata de un proyecto académico y que ya se dispone del software y hardware necesario, sí se va a considerar para tener un conocimiento del coste que supone un proyecto de estas características. Recursos Materiales: • • • • • • Ordenador de Sobremesa: 800€ Dispositivos Móviles: HTC Desire: 150€ Sony Xperia S: 300€ Asus Transformer: 400€ Electricidad (0.3kWh * 0.1457€/kWh *264horas + 20€*7meses): 151.54€ Internet (39.90€/mes * 7 meses): 279.30€ Alquiler Avión (150€/hora *1 horas): 150€ Software: Microsoft Windows 7 95€ Microsoft Office 2010 250€ X-Plane 10: 80€ Balsamiq Mockups 60€ Total Recursos Materiales: 2715.84€ Recursos Humanos: • Alumno: 264 horas * 30€/hora = 7.920€ Coste Total del Proyecto (2715.84€ + 7.920€) = 10.635,84€ 40 3.4 Seguimiento del Proyecto Aunque una planificación se haga de la forma más realista y usando los métodos más exactos siempre se produce un desfase entre la planificación y el desarrollo real. Este proyecto no es una excepción y, aunque en la mayor parte de él se ha cumplido el cálculo de tiempo (con una holgura aceptable) sí ha habido una serie de acontecimientos que han modificado el calendario estimado de una forma tangible: • • • • • • El Estudio de Manuales para Desarrolladores Android ha resultado mucho mayor de lo esperado. Las diferencias con Java a la hora de programar son superiores a lo esperado. Esto ha requerido un estudio más a fondo de la plataforma Android con el tiempo extra que conlleva. La Planificación del proyecto también ha sufrido un incremento de tiempo. Tras realizarla con el uso de la aplicación OpenProj se descubre que está no es capaz de distribuir las tareas sobre un máximo de trabajo diario, por lo que el alumno tenía una sobreexplotación del 700%. La solución tomada es el uso de Open Workbench en el que, tras realizar la tarea por segunda vez sí se consigue una planificación correcta. La Realización de casos de uso aumenta su duración respecto de la estimada por dos razones. La primera es que se subestiman las funcionalidades del sistema, por lo que cuesta un trabajo extra modelizar el comportamiento de cada una de ellas. La segunda razón deriva en las fiestas de Navidad. No se consigue el objetivo de horas durante estas fechas, por lo cual la duración del proyecto se ve desplazada 2 semanas. Durante el Diseño Funcional y de Datos aumenta el número de horas estimado debido a que el alumno debe aprender el entorno de desarrollo de diagramas UML y en repasar los conceptos de los diagramas utilizados. También incrementa la duración al pasar los diagramas a la memoria ya que eclipse exporta a imagen con mala calidad, por lo que se tiene que exportar a PDF (que mantiene el dibujo vectorial) para pasarlo luego a PNG y editarlo posteriormente con un editor de imágenes. El Diseño del Interfaz de usuario se realiza utilizando el programa Balsamiq Mockups. Debido a que el alumno tiene que aprender el uso del programa y la realización de prototipos es más lenta que si se hiciese a mano, se produce un aumento de trabajo y por tanto, un aumento de la duración de esta tarea. Tanto la Implementación de la Interfaz de Usuario como la Implementación de Checklists sufren una serie de cambios y contratiempos que se exponen en el Capítulo 6 Punto 6.5 Principales Retos y Cambios de Diseño 41 Con todos estos acontecimientos las tareas han sufrido un desvío respecto a la estimación que se muestran en el Cuadro 3: Tarea a Desempeñar Repaso de conceptos de Programación OO y Java Documentación General sobre Android Estudio de Manuales para Desarrolladores Android Instalación del Entorno Familiarización del Entorno Eclipse-Android Estudio de Necesidades del Piloto Planificación del Proyecto Definición de Funcionalidades Estudio de Conceptos Aeronáuticos Necesarios Elaboración del Modelo de Casos de Uso Realización de los Casos de Uso Diseño de la Interfaz de Usuario Diseño funcional y de datos de las Checklists Implementación de la Interfaz de Usuario Implementación de Checklists Pruebas de Funcionamiento Prueba en Simulador o Real Realización de la Memoria Redacción del Manual de Usuario Total Horas Cuadro 3. Desvío de Tiempo de Tareas T. T. Desv. Estim. Real 4 H. 3h -1h 6 H. 6h 0h 33 H. 50h +17h 3 H. 2h -1h 3 H. 2h -1h 4 H. 2h -2h 14 H. 18h +4h 8 H. 5h -3h 8 H. 6h -2h 5 H. 7h +2h 27 H. 35h +8h 19 H. 28h +9h 24 H. 32h +8h 21 H. 27h +6h 33 H. 52h +19h 8 H. 4h -4h 4 H. 1h -3h 32 H. 40h +8h 8 H. 8h 0h 264H 328h +64h El incremento son 64 horas, que siguiendo el ritmo calculado supone un retraso de la finalización del proyecto de 5-6 semanas, lo que sitúa el final del proyecto en la semana del 20 al 27 de Mayo. Podemos afirmar que la planificación ha sido correcta pues la fecha real de finalización se encuentra en ese periodo. 42 Capı́tulo 4: Aná lisis En este capítulo se aborda el análisis de la aplicación a desarrollar. En él se estudian los requisitos de su sistema, tanto funcionales como datos, así como requisitos que, no siendo de ninguno de estos anteriores, deben tener una repercusión sobre la aplicación. Todos estos requisitos serán descritos individualmente y su cumplimiento permitirá que la aplicación tenga todas las funcionalidades y diseños para que sea satisfactoria. 4.1 Presentación de los Requisitos Para analizar los requisitos que debe cumplir el sistema se van a utilizar los diagramas y tablas de Casos de Uso. En este proyecto se definen 3 tipos de requisitos: • • • Requisitos Funcionales: Los casos de uso. Funcionalidades para el usuario. Requisitos de Datos: Información necesaria para el usuario y Req. Funcionales. Req. No Funcionales: Filosofías de diseño, objetivos generales y restricciones. Los requisitos funcionales se definirán utilizando una tabla como en el Cuadro 4. Caso de Uso : Código Descripción Precondición Flujo Normal Flujo Alternativo Postcondición Nombre del Caso de Uso Breve descripción del requisito que debe cumplir el sistema. Condiciones necesarias ante la ejecución del caso de uso. Paso Acción 1 Acción 1. 2 Acción 2. 3 Acción 3. … Acción ... Paso Acción 2a.1 Acción Alternativa A al Paso 2 – Paso 1. 2a.2 Acción Alternativa A al Paso 2– Paso 2. 2b.1 Acción Alternativa B al Paso 2 – Paso 1. 2b.2 Acción Alternativa B al Paso 2 –Paso 2. 3C Acción Alternativa C al Paso 3 (Única Acción). D Accion Alternativa D en todo el Caso de Uso. Condiciones que se cumplen al terminar la ejecución de la funcionalidad del caso de uso. Cuadro 4. Modelo de Descripción de Caso de Uso Para requisitos que no sean casos de uso se utilizarán tablas más sencillas. Para requisitos de datos (Cuadro 5) y para requisitos no funcionales (Cuadro 6). 43 Req. de Datos : Código Descripción Casos de uso Asociados Requisitos Asociados Comentarios Nombre del Requisito Breve descripción del requisito que debe cumplir el sistema. Casos de Uso donde se utiliza este futuro recurso. Lista de relación con otros requisitos de datos. Notas y comentarios sobre el requisito. Cuadro 5. Modelo de Descripción de Requisito de Datos Req. no Funcional : Código Descripción Comentarios Nombre del Requisito Breve descripción del requisito que debe cumplir el sistema. Notas y comentarios sobre el requisito. Cuadro 6. Modelo de Descripción de Requisito No Funcional Para definir a los actores del sistema se utilizará la siguiente tabla (Cuadro 7) Actor : Casos de Uso Asociados: Tipo Descripción: Nombre del Actor Casos de uso en los que está implicado. Primario o Secundario. Descripción del Actor. Cuadro 7. Modelo de Descripción de Actor Los códigos que se utilizan en el modelado siguen los patrones que se indican a continuación (los xx se sustituyen por el número de caso de uso): • • • • • • • PAxx (PApers): Casos de uso centrados en el apartado de papeles (documentación e información de vuelo) NVxx (NaVigation): Casos de uso centrados en la navegación, instrumentos y ayuda a la navegación. UTxx (UTilities): Casos de uso referentes a utilidades del sistema (conversores, cálculos, notas, cronometro…). DAPxx (Data-APplication): Requisitos de datos almacenados permanentemente en la aplicación. DSTxx (Data-Status): Requisitos de datos almacenados temporalmente durante la ejecución de la aplicación. DESxx (Data-External Storage) Requisitos de datos que se refieren a archivos localizados en la memoria externa del dispositivo (Tarjeta SD o Memoria adicional). RNFxx: Requisitos No funcionales. 44 4.2 Visión general de la Aplicación Antes de describir cada caso de uso, para tener una visión global del futuro sistema y para comprenderlos mejor se muestra un diagrama de Caso de Uso general (Figura 10). En él se distinguen 3 subsistemas, que realmente es el mismo, solo que para una mejor comprensión se separan los casos de uso en 3 bloques. Figura 10. Diagrama de Casos de Uso - General 45 Actores Los Actores del sistema son aquellas personas o sistemas externos que interactúan con nuestra aplicación. Ahora detallamos los Actores del sistema en estudio (Cuadros 8 al 12): Actor : Casos de Uso Asociados: Tipo: Descripción: Piloto PA01, PA03, PA04, PA05, PA06, PA07,PA08, NV01, NV03, NV04, NV05, NV06, NV07, NV08, UT02, UT03, UT04, UT05, UT06,UT07, UT08 Primario Se trata del usuario principal de la aplicación. Representa a cualquier persona que esté usando el dispositivo. Cuadro 8. Actor Piloto. Actor : Casos de Uso Asociados: Tipo Descripción: Lector PDF PA04 Secundario Representa una aplicación instalada en Android que permite abrir y visualizar archivos PDF. Cuadro 9. Actor Lector PDF Actor : Casos de Uso Asociados: Tipo: Descripción: Servidor Meteo PA05 Secundario Se trata de un Servidor externo o página web alojado en Internet que ofrece información meteorológica de un aeropuerto en formato METAR y TAFOR (Texto Llano). Cuadro 10. Actor Servidor Meteo Actor : Casos de Uso Asociados: Tipo: Descripción: Sensores Movimiento NV08, UT05 Secundario Son los sensores disponibles del dispositivo encargados del movimiento y conocimiento del medio en el que se rodea (acelerómetros, giróscopo, brújula y barómetro). Cuadro 11. Actor Sensores Movimiento Actor : Casos de Uso Asociados: Tipo: Descripción: Sensor GPS NV01, NV08, UT05, UT06 Secundario Sensor del dispositivo encargado de traducir las señales de los satélites GPS en una posición en el Elipsoide WGS84 que representa la Tierra. También ofrece velocidad sobre el suelo, Track y Altitud. Cuadro 12. Actor Sensor GPS 46 Dependencias de Datos El sistema, para su correcto funcionamiento necesita de una serie de información. Esta puede provenir de 3 lugares: de la memoria externa, la memoria de la aplicación y del estado de la aplicación. Según esta clasificación en nuestra aplicación tenemos las siguientes dependencias de datos: Memoria de la Aplicación: Datos que se guardan en la aplicación de forma permanente para su uso por parte del sistema. Solo pueden ser modificados desde dentro de la aplicación. (Cuadros 13 al 16) Req. de Datos : DAP01 Descripción: Avión Seleccionado Nombre del Avión y ruta del archivo XML del avión que se utilizará en la aplicación. Casos de uso Asociados PA03, PA07, UT06, UT08 Requisitos Asociados DST01 Comentarios Ruta del archivo localizada en la memoria Externa. Cuadro 13. Req.Datos DAP01 - Avión Seleccionado Req. de Datos : DAP02 Descripción: Estaciones METAR Buscados Nombre y código OACI de las estaciones meteorológicas buscadas por el Piloto con anterioridad. Casos de uso Asociados PA05 Requisitos Asociados Comentarios Se trata de una lista con dos componentes en cada nodo. Un nombre de estación y un código OACI. Cuadro 14. Req.Datos DAP02 - Estaciones METAR Req. de Datos : DAP03 Descripción: Casos de uso Asociados Requisitos Asociados Comentarios Notas Guardadas Notas escritas por el Piloto y guardadas en el sistema. UT01, UT02, UT03 Lista de notas. Solo se almacenan caracteres alfanuméricos. Cuadro 15. Req.Datos DAP03 - Notas Guardadas Req. de Datos : DAP04 Descripción: Último VOR Identificación y posición del último VOR utilizado por el Piloto en sesiones anteriores. Casos de uso Asociados NV01, NV02 Requisitos Asociados DES05 Comentarios Componente que almacena un código de 3 caracteres como identificación y un número decimal como frecuencia. Cuadro 16. Req.Datos DAP04 - Último VOR 47 Estado de la Aplicación: Son los datos que se guardan durante la ejecución de la aplicación y que son borrados tras cerrarla o tras un tiempo sin utilizar la aplicación (tiempo que depende del sistema y del dispositivo) (Cuadros 17 al 24). Req. de Datos : DST01 Descripción Checklists Completadas Lista de Checklists que ya han sido completadas por el Piloto en la sesión actual. Casos de uso Asociados PA02 Requisitos Asociados DES02 Comentarios Listado de las Checklist en las que el Piloto ha seleccionado todos sus ítems. Se guarda como lista de un solo elemento por nodo (la identificación de la lista). Cuadro 17. Req.Datos DST01 - Checklists Completadas Req. de Datos : DST02 Descripción Ítems Completados Relación de ítems completados dentro de una Checklist en la sesión actual. Casos de uso Asociados PA03 Requisitos Asociados Comentarios Número entero de ítems completados. Cuadro 18. Req.Datos DST02 - Ìtems Completados Req. de Datos : DST03 Descripción Último METAR Información del último METAR consultado por el usuario durante la ejecución de la sesión actual. Casos de uso Asociados PA05, UT08 Requisitos Asociados DES03 Comentarios Cadena de caracteres alfanuméricos que componen el texto normalizado de un METAR. Cuadro 19. Req.Datos DST03 - Último METAR Req. de Datos : DST04 Descripción Casos de uso Asociados Requisitos Asociados Comentarios Información FPL Guarda información del plan de vuelo de la sesión actual. PA06, UT08 DES06 Estructura de distintos campos alfanuméricos. Guarda la información de: • Nombre del Plan de Vuelo • Tipo de Vuelo: (General, Escuela,…) • Código de Aeropuerto de Salida • Hora de salida • Velocidad de crucero • Códigos de aeropuertos alternativos • Código de aeropuerto de Destino • Tiempo estimado de Duración • Número de Pasajeros • Autonomía en horas • Piloto al Mando • Día del Vuelo • Otra información (cadena de caracteres) Cuadro 20. Req.Datos DST04 - Información FPL 48 Req. de Datos : DST05 Descripción Datos Mass & Balance Información del cálculo de peso y centro de gravedad del avión en la sesión actual. Casos de uso Asociados PA07, UT06, UT08 Requisitos Asociados DES03 Comentarios Datos numéricos sobre: • Combustible a bordo • Peso de las personas a bordo • Peso del Equipaje • Peso Actual del avión • Posición del Centro de Gravedad del avión • Capacidad de los depósitos de Combustible Cuadro 21. Req.Datos DST05 - Datos Mass & Balance Req. de Datos : DST06 Descripción Último VOR Identificación y posición del último VOR utilizado por el Piloto en la sesión actual. Casos de uso Asociados NV01, NV02, NV03, NV04, NV05, NV06, UT08 Requisitos Asociados DES05 Comentarios Componente que almacena un código de 3 caracteres como identificación, un número decimal como frecuencia, una coordenada N-S, una coordenada E-O (ambos con 4 decimales) y una elevación. Cuadro 22. Req.Datos DST06 - Último VOR Req. de Datos : DST07 Descripción Última Nota abierta Información escrita por el Piloto la última vez que utilizó la funcionalidad de crear Nota. Casos de uso Asociados UT02 Requisitos Asociados Comentarios Cadena de caracteres que contienen la nota escrita por el piloto en el caso de que se salga de la aplicación sin guardar la nota. Cuadro 23. Req.Datos DST07 - Última Nota Req. de Datos : DST08 Descripción Casos de uso Asociados Requisitos Asociados Comentarios Hora Inicio Vuelo Hora en la que se inicia el vuelo en la sesión actual. UT06, UT08 Hora que se utiliza para calcular el tiempo de vuelo. Se graba a partir de superar cierta velocidad GPS. Cuadro 24. Req.Datos DST08 - Hora Inicio Vuelo 49 Memoria Externa: Datos accesibles desde la memoria externa del dispositivo (ya sea una memoria interna o una tarjeta SD). Es modificable por el usuario (u otras aplicaciones) debido a que pueden acceder a los archivos que residen en ella (Cuadros 25 al 31). Req. de Datos : DES01 Descripción Archivo XML de Avión. Guarda toda la información referida al avión que representa en la memoria externa. Casos de uso Asociados PA03, PA07, UT06 Requisitos Asociados DAP01, DES02,DES03,DES04 Comentarios Archivo XML que guarda la información General (DES04), Checklist de Vuelo (DES02) y los Datos de Mass & Balance (DES03). Cuadro 25. Req.Datos DES01 - Archivo XML del Avión Req. de Datos : DES02 Descripción Checklists Serie de Listas de chequeo, cada una con sus ítems propios. Forma parte de DES01. Casos de uso Asociados PA03 Requisitos Asociados DES01, DST01 Comentarios Checklists distribuidas en dos grandes Grupos: Normales y Emergencia. Dentro de cada Grupo existe una serie de Listas (para cada parte del vuelo) y dentro de ellas una sucesión de ítems a realizar. Cuadro 26. Req.Datos DES02 - Checklists Req. de Datos : DES03 Descripción Datos de Mass & Balance Datos propios del avión necesarios para el cálculo de la carga y centrado . Forma parte de DES01. Casos de uso Asociados PA07 Requisitos Asociados DES01, DST05 Comentarios Los Datos que almacena son: • Peso Básico del Avión • Peso Máximo al despegue • Capacidad de los depósitos • Número máximo de pasajeros • Peso máximo del compartimento de carga • Gráfica de la envolvente de vuelo (Peso/ Centro Gravedad) Cuadro 27. Req.Datos DES03 - Datos de Mass & Balance Req. de Datos : DES04 Descripción Casos de uso Asociados Requisitos Asociados Comentarios Datos Generales del Avión Datos generales del avión. Forma parte de DES01. UT06 DES01, DAP01 Los Datos que almacena son: • Nombre del Avión • Código OACI del Avión • Velocidad de Crucero • Consumo Medio • Velocidad óptima de planeo • Fineza Cuadro 28. Req.Datos DES04 - Datos Generales del Avión 50 Req. de Datos : DES05 Descripción Casos de uso Asociados Requisitos Asociados Comentarios Base de Datos VOR Base de datos SQLite que contiene todos los VOR del mundo. Alojada en la memoria externa. NV02 DAP04, DST06 Los Datos que almacena son: • Identificación VOR (3 Caracteres) • Frecuencia VOR (Numero Decimal) • Coordenada Latitud (4 Decimales) • Coordenada Longitud (4 Decimales) • Elevación del Terreno (en pies) Cuadro 29. Req.Datos DES05 - Base de Datos VOR Req. de Datos : DES06 Descripción Archivos XML de FPL’s Contiene la información de un plan de vuelo guardado en la memoria externa por el Piloto. Casos de uso Asociados PA06 Requisitos Asociados DST04 Comentarios Estructura de distintos campos alfanuméricos. Guarda la información de: • Nombre del Plan de Vuelo • Tipo de Vuelo: (General, Escuela,..) • Código de Aeropuerto de Salida • Hora de salida • Velocidad de crucero • Códigos de aeropuertos alternativos • Código de aeropuerto de Destino • Tiempo estimado de Duración • Número de Pasajeros • Autonomía en horas • Piloto al Mando • Día del Vuelo • Otra información (cadena de caracteres) Cuadro 30. Req.Datos DES06 - Archivos XML de FPL's Req. de Datos : DES07 Descripción Casos de uso Asociados Requisitos Asociados Comentarios Carpeta de Fichas PDF Carpeta que aloja las fichas de aeropuertos que el Piloto utiliza en la memoria externa. PA04 La estructura es tal que: Dentro de una carpeta general (Fichas) existen subcarpetas (Código - Aeropuerto) que contienen todas las fichas PDF de cada aeropuerto. Cuadro 31. Req.Datos DES07 - Carpeta de Fichas PDF 51 Requisitos No Funcionales Aquí se nombran aquellos requisitos que condicionan la función global de la aplicación, restricciones y requisitos que no son funcionalidades por sí mismas. Req. no Funcional : RNF01 Descripción Comentarios Sistema Operativo Mínimo La aplicación debe soportar como mínimo Android 4.0 (Ice Cream Sandwich). Debe aprovechar las mejoras que se introducen a partir de 4.0. Cuadro 32. Req.No Funcional RNF01 - Sistema Operativo Mínimo Req. no Funcional : RNF02 Descripción Interfaz basado en Patrones de Google La interfaz gráfica debe estar diseñada siguiendo los patrones estudiados anteriormente (Interfaz de Usuario) para mejorar la experiencia del usuario. Cuadro 33. Req.No Funcional RNF02 - Interfaz basado en Patrones Google Req. no Funcional : RNF03 Descripción Comentarios Interfaz funcional en Tablets La aplicación debe soportar y adaptarse a los distintos tipos de pantallas de los diferentes dispositivos, aprovechando el espacio extra de las tablets para mostrar más información que en un Smartphone. Debe hacer uso de los Fragments que dispone Android 4.0 así como aprovechar las distintas configuraciones según densidad de píxels. Cuadro 34. Req.No Funcional RNF03 - Interfaz funcional en Tablets Req. no Funcional : RNF04 Descripción Comentarios Facilidad de uso en Vuelo La aplicación se debe diseñar para que al Piloto le resulte fácil e intuitivo utilizar sus funcionalidades en el transcurso de un vuelo. Debe hacerse hincapié en evitar introducir datos y letras. Hay aprovechar la introducción de datos visualmente, mostrar solo lo estrictamente necesario y simplificar la interacción con el Piloto. Cuadro 35. Req.No Funcional RNF04 - Facilidad de uso en Vuelo Req. no Funcional : RNF05 Descripción Uso de Recursos La aplicación debe utilizar, en la medida de lo posible, la mínima cantidad de recursos (memoria, CPU, batería) sin que ello perjudique al Piloto. Cuadro 36. Req.No Funcional RNF05 - Uso de Recursos Req. no Funcional : RNF06 Descripción Código Ordenado El código de la aplicación debe estar documentado, escrita de forma coherente y de fácil lectura. Debe tener en cuenta la reutilización de código, la escalabilidad y debe facilitar la localización de bugs. Cuadro 37. Req.No Funcional RNF06 - Código Ordenado 52 Req. no Funcional : RNF07 Descripción Comentarios Cambio de Idioma La aplicación debe de tener la opción de cambiar el idioma del interfaz gráfico. Se intentará utilizar las recomendaciones de Google para reducir al mínimo el coste de añadir idiomas nuevos. Cuadro 38. Req.No Funcional RNF07 - Cambio de Idioma Req. no Funcional : RNF08 Descripción Comentarios Reinicio de la aplicación La aplicación debe de tener la opción de reiniciar la aplicación, haciendo que todas los datos temporales se borren. Borrará todos los datos del estado de la aplicación (DSTxx) dejando la aplicación lista para un vuelo nuevo. Cuadro 39. Req.No Funcional RNF08 - Reinicio de la Aplcicación Req. no Funcional : RNF09 Descripción Comentarios Cambio de Avión La aplicación debe de tener la opción cambiar el avión seleccionado para el vuelo. Se buscará el XML de todos los aviones disponibles en la memoria externa del dispositivo. Cuadro 40. Req.No Funcional RNF09 - Cambio de Avión 4.3 Subsistema Papeles En esta parte de la aplicación se agrupan todas las funcionalidades referidas al uso de documentación del avión (Checklists, Fichas, Carga y centrado, Meteorología y Planes de Vuelo). Este es el único subsistema que contiene casos de uso que van a ser diseñados e implementados; en concreto se trata de PA01 – Mostrar Lista Ítems, PA02 – Marcar Checklist Leídas y PA03 – Usar Checklist. El diagrama de Casos de uso para este subsistema es el siguiente (Figura 11): Figura 11. Diagrama de Casos de Uso - Subsistema Papeles 53 El Detalle de cada Caso de Uso se indica en los siguientes Cuadros (del Cuadro 41 al Cuadro 48): Caso de Uso : PA01 Mostrar Lista Ítems Descripción El Sistema muestra en pantalla una lista de ítems cargados desde el conjunto de datos correspondiente a fin de que el piloto seleccionar uno de ellos. Precondición Se le debe indicar el conjunto de datos donde debe buscar la información ya sea una estructura de datos personalizada, un archivo XML, o una lista de archivos externos. Flujo Normal Paso Acción 1 El sistema carga la ListView donde se añadirán los ítems. 2 Se carga el conjunto de datos correspondiente en la Pantalla. 3 El Piloto selecciona el ítem deseado. 4 Se devuelve el Ítem seleccionado al sistema. Flujo Alternativo Paso Acción 3A En caso de mostrar Checklists (Provenir de PA03) se ejecuta el caso de uso PA02 – Marcar Checklist Leídas. Se vuelve al Flujo Normal en el Punto 3. 3B En caso de mostrar Estaciones Meteorológicas (Provenir de PA05) se Ejecuta el caso de Uso PA08 – Añadir Estación Aeropuerto. Se vuelve al Flujo Normal en el Punto 3. Postcondición Se ha seleccionado un Ítem. Cuadro 41. Caso de Uso PA01 - Mostrar Lista Ítems Caso de Uso : PA02 Marcar Checklist Leídas Descripción El Sistema comprueba las Checklists completadas o parcialmente cargadas y las marca para que el usuario tenga constancia de ello. Precondición Este Caso de Uso es llamado por PA01 - Mostrar Lista Ítems sólo en el caso de haber sido llamada por PA03 -Usar una Checklist. Flujo Normal Paso Acción 1 Se comprueba desde el estado de la aplicación las Checkist completadas (DST01). 2 El sistema Añade un Stick a la derecha del nombre de las Checklist que ya han sido completadas. 3 Se devuelve el Flujo al caso de uso PA01 - Mostrar Lista Ítems. Flujo Alternativo Paso Acción A.1 El Piloto Accede a las opciones y selecciona Reiniciar Listas A.2 El Sistema borra todas las listas completadas del estado de la aplicación (DST01) y borra los sticks. Postcondición Se han marcado las Checklists completadas. Cuadro 42. Caso de Uso PA02 - Marcar Checklist Leídas 54 Caso de Uso : PA03 Usar una Checklist Descripción El Sistema muestra en pantalla una Lista de Checklists del avión seleccionado (provenientes del fichero XML del avión) a fin de que el piloto seleccione una de ellas. Precondición Existe un avión cargado en el sistema (Archivo XML) DAP01. Flujo Normal Paso Acción 1 El sistema llama al caso de uso PA01 - Mostrar Lista Ítems indicando el archivo XML del avión seleccionado ubicado en la memoria externa del Dispositivo (DES01). 2 Es sistema según el Ítem (Checklist) seleccionado abre una nueva ventana y muestra una lista de los puntos de la Checklist cargados desde el XML del Avión (DES02). 3 El Sistema Comprueba si existen puntos ya realizados en el estado de la aplicación (DST02). De ser así se les añade un stick a la derecha (para indicar que ya han sido realizados). 4 El Piloto selecciona los distintos puntos en orden (el sistema no permite saltarse un punto). Al realizarlo se añade un stick a la derecha indicando su estado completado. 5 Al terminar seleccionar todos los puntos el sistema mostrará en pantalla “Checklist Completed”. Se añade la Checklist al estado de la aplicación para indicar que ya ha sido completada. Flujo Alternativo Paso Acción 5A La lista cargada es de Emergencia. El sistema muestra en pantalla “Checklist Completed”. (No se añade la lista a completadas). A En caso que la Actividad sea parada se guarda la relación de ítems que han sido completados en el estado de la aplicación (DST02). B.1 El Piloto Accede a las opciones y Selecciona Reiniciar Lista. B.2 El Sistema borra todos los Ítems completados y lista completada del estado de la aplicación (DST02) y borra los sticks. Postcondición El piloto ha usado la Checklist deseada. Cuadro 43. Caso de Uso PA03 - Usar una Checklist 55 Caso de Uso : PA04 Ver Ficha de Aeropuerto Descripción El Sistema muestra en pantalla una Ficha de un aeropuerto con el uso de un visor PDF externo. Para ello primero muestra una Lista de Aeropuertos (provenientes de la cantidad de Ficheros de aeropuertos que existan en la Memoria Externa) y luego otra de las Fichas disponibles en cada directorio a fin de que el piloto seleccione una de ellas. Precondición Existen al menos un fichero de Aeropuerto en la memoria Externa y una ficha PDF dentro de él. Flujo Normal Paso Acción 1 El sistema llama al caso de uso PA01 - Mostrar Lista Ítems indicando la ruta del fichero donde se encuentran los aeropuertos en la memoria externa del Dispositivo (DES07). 2 Es sistema según el Ítem (Aeropuerto) vuelve a llamar al caso de uso PA01 - Mostrar Lista Ítems indicando la ruta del fichero del aeropuerto donde se encuentran las Fichas PDF en la memoria externa del Dispositivo (DES07). 3 Según el Ítem seleccionado (Ficha) se manda su ruta al Visor PDF para que abra dicho documento. Flujo Alternativo Paso Acción 3A No se encuentra Visor de PDF en el dispositivo. El Sistema le muestra al usuario la posibilidad de descargar uno desde Google Play. Postcondición El sistema ha abierto el visor PDF con la ficha seleccionada. Cuadro 44. Caso de Uso PA04 - Ver Ficha Aeropuerto 56 Caso de Uso : PA05 Ver METAR TAF Descripción El Sistema muestra en pantalla el METAR y el TAFOR en texto llano de un aeropuerto. Para ello primero muestra una Lista de Aeropuertos estándar y los que el usuario ha introducido anteriormente. Precondición Existe una conexión a Internet Flujo Normal Paso Acción 1 El sistema llama al caso de uso PA01 - Mostrar Lista Ítems indicando el archivo de memoria de la aplicación (DAP02) donde se encuentran los aeropuertos estándar y los buscados con anterioridad. 2 El sistema según el Ítem seleccionado (Código OACI del Aeropuerto) pide al servidor de meteorología la información de ese aeropuerto. 3 El servidor devuelve en texto llano el METAR y el TAFOR. 4 El Sistema muestra en pantalla el texto en grande para facilitar la lectura y lo guarda en el estado de la aplicación (DST03). 5 Se añade el aeropuerto consultado en la lista de “buscados con anterioridad” (alojada en el estado de la aplicación) si no lo está ya. Flujo Alternativo Paso Acción 3a.1 El servidor no responde. 3a.2 El sistema muestra al piloto que no puede contactar con el servidor. FIN del Caso de Uso. 3b.1 El servidor no encuentra el aeropuerto y envía al sistema un error. 3b.2 El Sistema muestra al piloto que el Aeropuerto no se ha encontrado. FIN del Caso de Uso. Postcondición El sistema muestra un texto que contiene el METAR y TAFOR del aeropuerto requerido. Cuadro 45. Caso de Uso PA05 - Ver METAR TAF 57 Caso de Uso : PA06 Rellenar FPL Descripción El Sistema muestra en pantalla los distintos campos de un Plan de Vuelo OACI y el usuario puede rellenarlos sin ningún tipo de restricción. El usuario puede guardar o cargar FPL’s desde la Memoria Externa. Precondición Ninguna. Flujo Normal Paso Acción 1 El sistema muestra en pantalla los distintos campos vacíos a rellenar. 2 El piloto rellena los datos según su plan de Vuelo aprobado o supervisa los existentes. 3 Al salir de la Actividad el sistema guarda los datos temporalmente en el estado de la aplicación (DST04). Flujo Alternativo Paso Acción 1A El Sistema carga los datos anteriormente introducidos en vez de mostrar campos vacíos. Continúa el Flujo Normal en el Punto 2 (DST04). 2a.1 El usuario pulsa en Cargar FPL anterior. 2a.2 El sistema abre una ventana nueva y llama al caso de uso PA01 Mostrar Lista Ítems indicando la ruta del fichero donde se encuentran los FPL (en formato XML) en la memoria externa del Dispositivo (DES06). 2a.3 Según el Ítem seleccionado (Archivo FPL) el sistema abre dicho archivo y carga los datos en los campos de la actividad (DES06). Continúa el Flujo Normal en el Punto 2. 3a.1 El Usuario presiona Guardar FPL. 3a.2 El sistema genera y guarda un archivo con nombre normalizado (Fecha–Hora TO-ID) en la memoria externa (DES06) con todos los datos introducidos. FIN del Caso de Uso. Postcondición El sistema muestra una serie de campos con información sobre el Plan de Vuelo. Cuadro 46. Caso de Uso PA06 - Rellenar FPL 58 Caso de Uso : PA07 Calcular Mass & Balance Descripción El Sistema muestra en pantalla 3 parámetros numéricos (Personas a bordo, Kg de Equipaje y US Galones de Combustible) que el piloto debe seleccionar correctamente a fin de que el sistema calcule si el avión seleccionado se encuentra dentro de la envolvente de vuelo (que asegura que no se excede el peso máximo ni los límites del Centro de Gravedad). Precondición Existe un avión cargado en el sistema (Archivo XML) (DAP01). Flujo Normal Paso Acción 1 El sistema muestra 3 Pickers con los valores que se pueden modificar. 2 El usuario cambia los valores según el vuelo que realice. 3 El sistema carga los datos de Carga y Centrado del XML del avión (DES01, DES03). 3 El sistema calcula y muestra en la parte inferior en verde “M&B OK” si se encuentra dentro de la envolvente. 4 Al salir de la actividad se guardan los datos en el estado de la aplicación (DST05). Flujo Alternativo Paso Acción 3A Los datos introducidos no entran en la envolvente. El sistema muestra en la parte inferior en ROJO “NO GO!!” e indica la razón por la que se sale de ella (por exceso de peso o por límites del CdG). Se vuelve el flujo Normal en el paso 2. B.1 El usuario pulsa ver gráfico. B.2 El Sistema muestra un gráfico 2D definido en el XML del Avión (DES03) donde se señala la posición del avión en la envolvente según los datos introducidos. Postcondición El sistema ha calculado la carga y centrado del avión. Cuadro 47. Caso de Uso PA07 - Calcula Mass & Balance Caso de Uso : PA08 Añadir Estación Aeropuerto Descripción El Sistema añade una estación meteorológica nueva en la lista disponible. Precondición Existe una conexión a Internet Este Caso de Uso es llamado por PA01 - Mostrar Lista Ítems sólo en el caso de haber sido llamada por PA05 – Ver METAR TAF Flujo Normal Paso Acción 1 El sistema muestra un campo de entrada de texto y un botón de añadir Estación. 2 El Piloto introduce el código OACI del aeropuerto que desea conocer y Pulsa el botón de añadir. 3 El sistema Añade la opción a la Lista. 4 Se devuelve el Flujo al caso de uso PA01 - Mostrar Lista Ítems. Flujo Alternativo Paso Acción 2A El piloto no realiza ninguna acción. Se Devuelve el Flujo a PA01 Mostrar Lista Ítems. Postcondición El sistema ha añadido una estación meteorológica en la lista de ítems disponibles. Cuadro 48. Caso de Uso PA08 - Añadir Estación Aeropuerto 59 4.4 Subsistema Navegación En esta parte de la aplicación se agrupan los casos de uso referentes a sistemas y ayudas a la navegación como son: Instrumentos de Stand-By, HSI, y procedimientos IFR. El diagrama de Casos de Uso es el siguiente (Figura 12): Figura 12. Diagrama de Casos de Uso - Subsistema Navegación Los detalles de cada caso de uso se muestran en los siguientes cuadros (del Cuadro 49 al Cuadro 56): Caso de Uso : NV01 Calcular Posición VOR Descripción El sistema calcula la posición relativa a un VOR predefinido (Radial y Distancia) a partir de los datos del sensor GPS del dispositivo. Precondición Debe ser llamado por otro caso de uso que utilice la posición VOR. Hay un VOR seleccionado. El dispositivo dispone de Antena GPS y/o GLONASS. Flujo Normal Paso Acción 1 El piloto mantiene el VOR que ya está seleccionado (DAP04). 2 El sistema pide los datos de posición al sensor. 3 El sensor responde con la posición, altitud, track y velocidad. 4 El sistema calcula la posición en referencia al VOR actual desde el estado de la aplicación donde se conoce la posición del VOR. 5 El resultado del cálculo se compone de un Radial, una Distancia DME, una Distancia sobre el Suelo y una velocidad hacia la estación. 6 El sistema escribe en el estado de la aplicación el resultado del cálculo más el Track, velocidad y Altitud (DST06). Flujo Alternativo Paso Acción 1A El Piloto selecciona cambiar de estación VOR. Se llama al caso de uso NV02 - Cambiar Frecuencia 3a.1 No hay respuesta del sensor. El Sistema avisa al usuario indicando que no hay cobertura. 3a.2 Se devuelve el flujo al punto 3 hasta que haya cobertura. 60 3b.1 Postcondición La recepción GPS está apagada. El Sistema propone al usuario la opción de conectarla. 3b.2 Se devuelve el flujo al punto 3 hasta que haya cobertura. El sistema ha calculado la posición VOR del avión para ser usada por otros casos de uso. Cuadro 49. Caso de Uso NV01 - Calcular Posición VOR Caso de Uso : NV02 Cambiar Frecuencia Descripción El sistema permite al usuario cambiar de frecuencia VOR para utilizar otra estación VOR para la navegación o para la ayuda a la navegación. Precondición Es llamado por el Caso de Uso NV01 - Calcular Posición VOR Flujo Normal Paso Acción 1 El sistema muestra 2 Pickers con los valores que se pueden modificar (MHz en uno y Centésimas de MHz en otro), y también muestra una entrada de texto donde escribir 3 caracteres (identificación VOR). 2 El usuario modifica los valores y acepta el cambio. 3 El sistema busca en la base de datos de VOR en la Memoria Externa (DES05) la frecuencia introducida la estación correspondiente. 4 El sistema escribe en el estado de la aplicación la nueva estación VOR (frecuencia, identificación, posición GPS) (DST06), reescribe en la memoria el nuevo VOR utilizado (DAP04) y cambia los pickers o la entrada de texto con los valores de la estación elegida. 5 Se Devuelve el flujo a NV01 - Calcular Posición VOR. Flujo Alternativo Paso Acción 3a.1 El sistema encuentra varias posibilidades (misma frecuencia para distintas estaciones o misma id para distintas frecuencias). 3a.2 El sistema selecciona mediante una estimación de distancia la más cercana. Continúa el flujo en el punto 4. 3b.1 El sistema no encuentra ningún resultado en la base de datos. 3b.2 El sistema informa al usuario de que no encuentra resultados y no permite que la ejecución termine. Continúa el flujo en el punto 2. C El usuario cancela el cambio. Se pasa al punto 5. Postcondición El sistema ha cambiado la estación VOR de referencia. Cuadro 50. Caso de Uso NV02 - Cambiar Frecuencia 61 Caso de Uso : NV03 Usar HSI Descripción El Sistema muestra en pantalla una representación de un HSI, Horizontal Situation Indicator ,y de un DME, Distance Measuring Equipment. El Piloto puede utilizarlo como radioayuda usando la información que ofrece, cambiando el radial y la pínula. Precondición Hay un VOR seleccionado. Flujo Normal Paso Acción 1 El sistema muestra un HSI, un DME e información sobre la estación seleccionada (Identificación y frecuencia). 2 El sistema llama al caso de uso NV01 - Calcular Posición VOR. 3 Con los datos devueltos el sistema muestra la posición del avión en el CDI siguiendo los principios de funcionamiento del HSI según la posición del Course (DST06). 4 El sistema muestra en el DME la Distancia DME, velocidad a la estación y calcula el tiempo a ella para mostrarla (DST06). 5 El piloto navega con los valores actuales. 6 El flujo vuelve al punto 2 hasta que el usuario salga de la actividad. Flujo Alternativo Paso Acción 5A El usuario cambia los valores del Course. Continúa el Flujo en el punto 6. Postcondición El usuario ha utilizado el HSI como medio de navegación. Cuadro 51. Caso de Uso NV03 - Usar HSI Caso de Uso : NV04 Calcular Espera Descripción El usuario introduce las propiedades de la espera, el sistema calcula el tipo de entrada a la espera según la posición del avión e indica al piloto los pasos que debe realizar para entrar correctamente. Precondición Hay un VOR seleccionado. Flujo Normal Paso Acción 1 El sistema muestra 3 campos a rellenar (outbound, espera no estándar y espera por encima de FL140) y la opción de cambiar de estación. 2 El piloto rellena el campo Outbound, y si procede marca que la espera no es estándar y/o está por encima de FL140. 3 El sistema llama al caso de uso NV01 - Calcular Posición VOR. 4 El sistema con la información que se devuelve del paso anterior (DST06) y con la que proporciona el piloto calcula el tipo de entrada. 5 El sistema muestra en pantalla el tipo de entrada (DIRECTA, GOTA o PARALELA) y los pasos que debe seguir. 6 El Piloto sigue los pasos. 7 En el momento de pasar por encima de la estación el sistema muestra en pantalla un cronometro en cuenta atrás. Al llegar a 0 emite un sonido y parpadea el cronometro. Flujo Alternativo Paso Acción 6a.1 El piloto cambia parámetros de la espera tras mostrarse los pasos. 6a.2 El sistema vuelve al punto 3. Postcondición El piloto ha conseguido entrar en la espera. Cuadro 52. Caso de Uso NV04 - Calcular Espera 62 Caso de Uso : NV05 Calcular Interceptación Descripción El usuario introduce la interceptación deseada, el sistema calcula el tipo de interceptación según la posición del avión e indica al piloto los pasos que debe hacer para realizarla correctamente. Precondición Hay un VOR seleccionado. Flujo Normal Paso Acción 1 El sistema muestra 1 campo a rellenar (ruta deseada), una selección de alejamiento o acercamiento y la opción de cambiar de estación. 2 El piloto rellena el campo “deseada” con el radial deseado y si se trata de acercamiento o alejamiento. 3 El sistema llama al caso de uso NV01 - Calcular Posición VOR. 4 El sistema con la información que se devuelve del paso anterior (DST06) y con la que proporciona el piloto calcula el tipo de interceptación. 5 El sistema muestra en pantalla el tipo de interceptación (DIRECTO o PASADO) y los pasos que debe seguir. 6 El Piloto sigue los pasos. Flujo Alternativo Paso Acción 5A En el caso de ser acercamiento pasado, al pasar abeam de la estación el sistema muestra en pantalla un cronometro de un minuto en cuenta atrás. Al llegar a 0 emite un sonido y parpadea el cronometro. 6a.1 El piloto cambia parámetros de la espera tras mostrarse los pasos. 6a.2 El sistema vuelve al punto 3. Postcondición El piloto ha conseguido realizar la interceptación correctamente. Cuadro 53. Caso de Uso NV05 - Calcular Interceptación Caso de Uso : NV06 Calcular Punto a Punto Descripción El piloto introduce el punto deseado referenciado al VOR actual, el sistema según la posición del avión calcula el rumbo al punto y lo muestra al piloto. Precondición Hay un VOR seleccionado. Flujo Normal Paso Acción 1 El sistema muestra 2 pickers (Radial y Distancia DME) además de la opción de cambio de frecuencia. 2 El piloto selecciona los valores del punto al que quiere ir. 3 El sistema llama al caso de uso NV01 - Calcular Posición VOR. 4 El sistema con la información que se devuelve del paso anterior (DST06) y con la que proporciona el piloto calcula el rumbo a seguir. 5 El sistema muestra en pantalla el rumbo. 6 El Piloto sigue los pasos. Flujo Alternativo Paso Acción 6a.1 El piloto cambia parámetros del punto tras mostrarse el rumbo. 6a.2 El sistema vuelve al punto 3. Postcondición El piloto ha conseguido ir de un punto a otro. Cuadro 54. Caso de Uso NV06 - Calcular Punto a Punto 63 Caso de Uso : NV07 Calcular Arco Descripción El usuario introduce las propiedades del arco, el sistema según la posición del avión calcula el rumbo a marcar para entrar en dicho arco y el error que tiene el piloto. Precondición Hay un VOR seleccionado. Flujo Normal Paso Acción 1 El sistema muestra 2 campos a rellenar (Distancia DME y sentido de giro) y la opción de cambiar de estación. 2 El piloto rellena el campo con la distancia requerida y el sentido de giro establecido. 3 El sistema llama al caso de uso NV01 - Calcular Posición VOR. 4 El sistema con la información que se devuelve del paso anterior (DST06) y con la que proporciona el piloto calcula el rumbo y el error. 5 El sistema muestra en pantalla rumbo y el error (Izquierda o derecha y error en NM) 6 El Piloto sigue los pasos. Flujo Alternativo Paso Acción 6a.1 El piloto cambia parámetros de la espera tras mostrarse los pasos. 6a.2 El sistema vuelve al punto 3. Postcondición El piloto ha seguido el arco deseado. Cuadro 55. Caso de Uso NV07 - Calcular Arco Caso de Uso : NV08 Ver Instrumentos de Stand-By Descripción El Sistema muestra en pantalla una serie de relojes que imitan el tablero de un avión. El piloto solo puede visualizar la información (excepto el Altímetro). Precondición El dispositivo dispone de Sensor GPS y sensores de Movimiento. Flujo Normal Paso Acción 1 El sistema muestra los relojes: Se muestran: • Velocidad (etiqueta GPS) • Posición respecto el horizonte • Altitud (etiqueta GPS) • Régimen y coordinación de viraje • Rumbo • Cambio de altitud 2 El sistema pide información a Sensores de Movimiento y a Sensor GPS. 3 Con los datos de los sensores el sistema calcula y muestra en cada reloj su dato correspondiente. Flujo Alternativo Paso Acción 2a.1 El dispositivo dispone de Giróscopo. 2a.2 El Sistema pone la etiqueta GYRO en el Horizonte. 3a.1 El Dispositivo dispone de barómetro. 3a.2 El Sistema elimina la etiqueta GPS del altímetro. 3a.3 El piloto cambia la Capsula de Kollsman presionando el altímetro. 3a.4 El sistema muestra un Picker con los valores en milibares para poner en la capsula. 3a.5 El sistema calcula la altitud mediante el barómetro y el valor de la cápsula de Kollsman. 3a.6 El Flujo vuelve al punto 3. 64 Postcondición 3b.1 No hay respuesta del Sensor GPS y se avisa al usuario indicando que no hay cobertura. 3b.2 Se marcan con aspas rojas los instrumentos implicados (Velocidad y/o Altitud). Se devuelve el flujo al punto 2. 3c.1 La recepción GPS está apagada y se propone al usuario la opción de conectarla. 3c.2 Se marcan con aspas rojas los instrumentos implicados (Velocidad y/o Altitud). Se devuelve el flujo al punto 2. El usuario ha utilizado los instrumentos de emergencia. Cuadro 56. Caso de Uso NV08 - Ver Instrumentos de Stand-By 4.5 Subsistema Utilidades En esta última parte están aquellos casos de uso que están relacionados con herramientas para el piloto, como pueden ser: cálculo de equivalencias de unidades, cálculo de combustible, cálculo de Viento y Velocidad Real, Cronometro, Notas e Información de vuelo. El Diagrama de Casos de Uso de este subsistema es el siguiente (Figura 13): Figura 13. Diagrama de Casos de Uso - Subsistema Utilidades 65 64): El detalle de cada caso de uso se nombra a continuación (del Cuadro 57 al Cuadro Caso de Uso : UT01 Mostrar Nota Descripción El Sistema muestra en pantalla una lista de Notas escritas por el Piloto anteriormente y este accede a una de ellas para ver su contenido. Precondición Ninguna. Flujo Normal Paso Acción 1 El sistema llama al caso de uso PA01 - Mostrar Lista Ítems indicando la lista de notas guardadas ubicada en la memoria de la aplicación. (DAP03). 2 Es sistema según el Ítem (Nota) seleccionado abre una nueva ventana y muestra el texto anteriormente introducido por el Piloto. Flujo Alternativo Paso Acción 1A No hay ninguna nota en la lista. El sistema llama al caso de uso PA01 - Mostrar Lista Ítems pero al no haber ítems se muestra una lista vacía y por consiguiente el piloto no elige ninguno. 1b.1 El Piloto desea crear una Nota. 1b.2 El sistema llama al caso de uso UT02 – Crear Nota. 1c.1 El Piloto desea borrar una de las Notas. 1c.2 El sistema llama al caso de uso UT03 – Borrar Nota. Postcondición El usuario ha consultado una nota. Cuadro 57. Caso de Uso UT01 - Mostrar Nota Caso de Uso : UT02 Descripción Precondición Flujo Normal Flujo Alternativo Postcondición Crear Nota El piloto desea crear una nueva nota y el sistema la crea y la guarda Este caso de uso es llamado por Mostrar Notas – UT01. Paso Acción 1 El sistema muestra una ventana con un campo de texto para rellenar. 2 El piloto rellena la nota con la información que desea guardar. 3 El piloto selecciona guardar nota. 4 El sistema le pone de nombre la fecha y el inicio de la nota, y la guarda en la memoria de la aplicación (DAP03). 5 El sistema muestra al usuario que se ha guardado correctamente. Paso Acción 1a.1 El usuario sale de la aplicación tras iniciar la nota nueva. 1a.2 El sistema guarda la nota en el estado de la aplicación hasta que se vuelva a la aplicación (DST07). 3a.1 El piloto descarta la nota. 3a.2 El sistema borra la nota. Fin del caso de uso. 4A El sistema no puede guardar la nota y se lo comunica al usuario. Continúa el flujo en el punto 5. El usuario ha creado una nota nueva y se ha guardado. Cuadro 58. Caso de Uso UT02 - Crear Nota 66 Caso de Uso : UT03 Borrar Nota Descripción El piloto desea borrar una nota ya creada. Precondición Este caso de uso es llamado por UT01 - Mostrar Nota. Existe al menos una nota en la memoria de la aplicación. Flujo Normal Paso Acción 1 El Piloto accede al menú de selección de Android. 2 El piloto selecciona las notas que desea borrar. 3 El piloto pulsa la opción de borrar. 4 El sistema borra de la lista las notas seleccionadas. 5 El sistema muestra al usuario que se han borrado las notas y muestra una opción de deshacer. 6 El sistema borra las notas de la memoria de la aplicación (DAP03). 7 Se devuelve el flujo a UT01 - Mostrar Notas. Flujo Alternativo Paso Acción 3A El usuario cancela el borrado y sale del menú de selección de Android. Se pasa al punto 7. 6a.1 El usuario presiona el botón deshacer. 6a.2 El sistema vuelve a mostrar en la lista las notas borradas. Postcondición El usuario ha borrado una nota. Cuadro 59. Caso de Uso UT03 - Borrar Nota Caso de Uso : UT04 Descripción Precondición Flujo Normal Flujo Alternativo Postcondición Convertir Unidades El piloto desea consultar una equivalencia entre dos unidades distintas. Ninguna. Paso Acción 1 El sistema muestra una pantalla con distintas pestañas disponibles en función del tipo de unidades que desea buscar (U. Geográficas, U. Físicas o U. Medioambientales). 2 El Piloto selecciona el grupo al que pertenecen las unidades deseadas. 3 El Piloto selecciona entre las distintas unidades la unidad de origen y la unidad de destino. 4 El Piloto introduce mediante el teclado el valor deseado 5 El sistema calcula, en función de las dos unidades seleccionadas y el valor introducido, la equivalencia en la unidad de destino. 6 El sistema muestra en un campo el resultado del cálculo. Paso Acción 5a.1 El usuario presiona el botón de intercambio de unidades. 5a.2 El sistema cambia la unidad de origen por la de destino y viceversa. 5a.3 Se vuelve al flujo normal en el punto 5. El usuario ha consultado una equivalencia de unidades. Cuadro 60. Caso de Uso UT04 - Convertir Unidades 67 Caso de Uso : UT05 Calcular Datos del Aire Descripción El Sistema muestra en pantalla 2 parámetros numéricos (Temperatura e IAS) que el piloto debe seleccionar correctamente a fin de que el sistema calcule la velocidad Real (TAS) y el viento que está afectando la aeronave (Rumbo/Intensidad). Precondición El dispositivo dispone de Antena GPS/GLONASS y sensores de movimiento. Flujo Normal Paso Acción 1 El sistema muestra 2 Pickers con los valores que se pueden modificar y un aviso para recordar al usuario que oriente el dispositivo perpendicularmente al rumbo del avión. 2 El Piloto coloca correctamente el dispositivo (a 90º del morro del avión, con la pantalla mirando al Piloto). 3 El Piloto selecciona los valores deseados de temperatura y velocidad indicada. 4 El sistema pide información al sensor GPS y a los sensores de Movimiento. 5 El sistema calcula en función de los datos del piloto y los de los sensores la TAS, la dirección del viento y su intensidad. 6 El sistema muestra en pantalla la TAS y el Viento. Flujo Alternativo Paso Acción 5a.1 No hay respuesta del sensor. Se avisa al usuario indicando que no hay cobertura. 5a.2 Se devuelve el flujo al punto 4 hasta que haya cobertura. 5b.1 La recepción GPS está apagada. Se propone al Piloto la opción de conectarla. 5b.2 Se devuelve el flujo al punto 4 hasta que haya cobertura. C El dispositivo no dispone de Giróscopo. El sistema muestra en pantalla un aviso de que la información solo es válida en vuelo recto y nivelado. Postcondición El sistema ha calculado los datos del aire. Cuadro 61. Caso de Uso UT05 - Calcular Datos del Aire 68 Caso de Uso : UT06 Calcular Combustible Descripción El Sistema muestra en pantalla un campo que el piloto debe rellenar con el combustible que contiene la aeronave antes del despegue. Cuando la aeronave se encuentra en vuelo el sistema calcula el combustible remanente, el tiempo de funcionamiento del motor y la distancia aproximada que puede alcanzar con dicho combustible en función de la aeronave seleccionada. Precondición El dispositivo dispone de Antena GPS/GLONASS. Existe un avión cargado en el sistema (DAP01). Flujo Normal Paso Acción 1 El sistema muestra 1 campo de texto donde indicar el combustible a bordo, un botón de validación y los datos a mostrar (combustible remanente, tiempo de vuelo y distancia alcanzable). 2 El Sistema saca del estado de la aplicación la cantidad de combustible (DST05)(anteriormente calculada del caso de uso PA07 - Calcular Mass & Balance) y la valida automáticamente. 3 El sistema accede al XML del avión seleccionado para conocer su velocidad de crucero, capacidad del depósito y consumo medio (DES04). 4 El sistema pide información al sensor GPS. 5 El sistema detecta que el avión está en vuelo (el dispositivo se mueve a una velocidad mínima determinada) y empieza a contar el tiempo de vuelo. 6 El sistema calcula en función de los datos suministrados y del tiempo de vuelo la cantidad remanente, tiempo hasta agotar combustible y distancia alcanzable. 7 El sistema muestra en pantalla los datos calculados y los guarda en el estado de la aplicación (DST05). Flujo Alternativo Paso Acción 2a.1 El sistema no encuentra el dato de combustible en el estado de la aplicación (DST05). 2a.2 El Piloto introduce la cantidad de combustible en los tanques y valida el dato con el botón. 2a.3 Se devuelve el flujo normal en el punto 3. 5a.1 No hay respuesta del sensor. Se avisa al usuario indicando que no hay cobertura. 5a.2 Se devuelve el flujo al punto 4 hasta que haya cobertura. 5b.1 La recepción GPS está apagada. Se propone al Piloto la opción de conectarla. 5b.2 Se devuelve el flujo al punto 4 hasta que haya cobertura. 7a.1 El Piloto cambia la cantidad de combustible y presiona el botón validar. 7a.2 El sistema pone a cero el tiempo de vuelo y recalcula los datos con la nueva información guardando los correspondientes en el estado de la aplicación(DST05). Postcondición El sistema ha calculado el combustible remanente. Cuadro 62. Caso de Uso UT06 - Calcular Combustible 69 Caso de Uso : UT07 Usar Cronómetro Descripción El piloto desea cronometrar un tiempo y el sistema le proporciona un cronómetro que cuenta desde/hasta que el piloto decide o suena una alarma si se trata de una cuenta atrás. Precondición Ninguna. Flujo Normal Paso Acción 1 El sistema muestra los dígitos de un cronómetro, un botón de Inicio/Parada, un botón de Restablecer y una opción de cuenta atrás de 1m y 1m30s. 2 El piloto selecciona no tener una cuenta atrás. 3 El piloto pulsa el botón de Inicio/Parada 4 El sistema Inicia el cronómetro en un servicio independiente de la actividad y muestra el tiempo correr en la actividad. 5 El piloto presiona el botón Inicio/Parada. 6 El sistema muestra el tiempo total. 7 El piloto presiona Borrar. 8 El sistema borra el tiempo y pone el contador a 0. Flujo Alternativo Paso Acción 2a.1 El piloto selecciona tener una cuenta atrás de 1m o 1m30s. 2a.2 El usuario presiona el botón Inicio/Parada. 2a.3 El sistema Inicia el cronómetro en un servicio independiente de la actividad y muestra el tiempo correr en la actividad. 2a.4 El tiempo se agota. El sistema emite un sonido y parpadea la pantalla dentro de la aplicación. Fuera de ella envía un mensaje a la barra de Notificaciones. 2a.5 Se vuelve al flujo normal en el punto 8. Postcondición El usuario ha utilizado el cronómetro. Cuadro 63. Caso de Uso UT07 - Usar Cronómetro Caso de Uso : UT08 Descripción Precondición Flujo Normal Flujo Alternativo Postcondición Ver Información de Vuelo El piloto desea ver la información del vuelo actual. Ninguna. Paso Acción 1 El sistema busca todos los datos que existen en el estado de la aplicación así como algunos de la memoria de la aplicación (avión actual, datos del Mass&Balance, tiempo de vuelo del cálculo de combustible, ultimo METAR consultado, información del FPL,…) (DAP01, DST03, DST04, DST05, DST06, DST08). 2 El sistema muestra dichos datos en la pantalla en modo texto. 3 El piloto consulta dicha información. Paso Acción El usuario ha consultado la información de vuelo. Cuadro 64. Caso de Uso UT08 - Ver Información de Vuelo 70 Capı́tulo 5: Diseñ o En este capítulo se muestra todo el desarrollo del diseño de la aplicación. En una parte se diseña el interfaz gráfico y en la segunda parte se diseña el comportamiento básico de la aplicación y la funcionalidad de Checklists. 5.1 Interfaz Gráfica En esta parte se expone el diseño de la interfaz gráfica de toda la aplicación, y más profundamente la interfaz de la funcionalidad del uso de Checklists. Se explica, para la funcionalidad de Checklists, las posibilidades que tiene el usuario dentro de ella y sus consecuencias en la aplicación. Durante el diseño de esta, se ha seguido los principios de Google (ver 2.9 Interfaz de Usuario) y se ha perseguido conseguir una interfaz que sea fácilmente usable por el piloto (ver Cuadro 35. Req.No Funcional RNF04 - Facilidad de uso en Vuelo). Otro de los objetivos de esta interfaz es tener compatibilidad con dispositivos con pantallas grandes (ver Cuadro 34. Req.No Funcional RNF03 - Interfaz funcional en Tablets), debido a eso se necesitan 2 diseños distintos; uno para móviles y otro para Tablets. Como después se comprueba durante la implementación, Android provee a los desarrolladores de herramientas que permiten evitar hacer el trabajo dos veces. Elementos Comunes En la totalidad de la aplicación existe un elemento que es común en todas las pantallas, la barra Action Bar (ver 2.9 Interfaz de Usuario - Patrones de Diseño). El icono de la aplicación se ha obtenido partiendo de SVG’s de dominio público y modificados a gusto del alumno. Se trata de un HSI (de la FAA americana) y una avioneta por delante (obtenido de la Open Clip Art Library). Indica de forma gráfica el uso objetivo y la funcionalidad más atractiva. Figura 14. Icono de la Aplicación 71 Prototipo de la Interfaz Gráfica (Anexo C) Debido a la ingente cantidad de pantallas que contiene la aplicación se hace inviable mostrarlas todas en esta memoria. Decidimos exportar la lista de pantallas a un Anexo (Anexo C). En éste se le ha añadido la posibilidad de interactuar entre los distintos botones de la aplicación haciendo más fácil el visualizado de la interfaz. Las Interfaces que finalmente se implementan, y por tanto, las que se detallan en esta memoria son las siguientes: Menú Principal En el menú principal se muestran 4 botones asociados a 4 categorías. Cada uno de ellos contiene funcionalidades asociadas a esa categoría. De esta forma el Piloto no pierde tiempo buscando la actividad deseada en una larga lista, pues conociendo dicha actividad sin dudas averiguará la categoría a la que pertenece (ver Figura 15). Al hacer clic el piloto en una de las categorías se muestra una lista con las funcionalidades que ésta contiene. En el caso de tener un dispositivo móvil la lista se mostrará en una ventana nueva ocultando el menú principal. En caso de usar una Tablet se mostrará a la izquierda el menú principal y a la derecha la Lista de Funcionalidades (ver Figura 17). Figura 15. Diseño de la Pantalla Menú Principal Figura 16. Diseño de la Pantalla Lista de Funcionalidades 72 En la versión móvil, en la Action Bar se muestra como nombre un Spinner con las 4 Categorías permitiendo así la posibilidad de entrar en otra con menos pasos. A la derecha del Spinner se muestra un botón que accede a las Checklists de emergencia. Lista de Funcionalidades El contenido de estas dependerá de la categoría a la que se haya accedido. En este caso se estudia el funcionamiento de la categoría Papeles por ser la que contiene la funcionalidad de Checklists (Ver Figura 16 y Figura 17). En ella se muestran en una lista simple las funcionalidades. Al hacer clic sobre Checklists la aplicación iniciará la actividad de Checklists. La Action Bar se mantiene igual que en el menú principal. Como se ha mencionado antes, en caso de disponer de una Tablet el menú principal y la lista de funcionalidades se muestran como una única interfaz (Figura 17). Figura 17. Diseño en Tablet de Menú Principal – Lista de Funcionalidades 73 Menú Checklists Al pulsar en Checklists en la lista de funcionalidades de Papeles se abre una nueva Actividad. En ella se muestran 2 pestañas; una llamada Normales (por defecto) y la otra Emergencia. Estas contienen una lista de las Checklists que han encontrado en el XML del Avión (ver Cuadro 26. Req.Datos DES02 - Checklists), cada una en su grupo. En el caso de ser Emergencia solo se trata de una lista de las diferentes Checklists. En el caso de ser Normales cada celda (cada Checklist) a su derecha puede llevar una imagen de un stick para indicar al piloto que esa Checklist ya ha sido utilizada y completada (ver Figura 18). El Piloto, en el caso de tener un dispositivo móvil, al hacer clic en una de las Checklist se abre (en una nueva ventana) la Checklist Actual ocultando la lista. En caso de usar una Tablet se mostrará a la izquierda el menú de Checklists y a la derecha la Checklist Actual (ver Figura 20). En la Action Bar ahora en el nombre pone Checklists (sin Spinner) y desaparece el botón de Checklists. Se mantiene el Action Overflow que añade la opción de reiniciar todas las Checklists (borrar las que se hayan completado). Figura 18. Diseño de la Pantalla Menú Checklists Figura 19. Diseño de la Pantalla Checklist Actual 74 Checklist Actual En esta pantalla se muestra una lista de ítems con formato (Objeto -- Acción) y a la derecha de cada uno una imagen que, dependiendo del Piloto, será o vacía o un stick. Cuando el piloto hace clic en el ítem correspondiente, este pasará de inicialmente vacío a mostrar un stick indicando que la acción ha sido realizada. La interfaz no permite que se puedan añadir sticks a ítems que no están inmediatamente debajo del anteriormente pulsado, por lo que obliga al piloto a realizar todos los pasos en secuencia). Al terminar todos los ítems se muestra un texto indicando “Checklist Completed” y marca con un stick la Checklist actual (ver Figura 19). Como se menciona en el punto anterior, en caso de ser una Tablet7 el Menú Checklists y Checklist Actual es una misma interfaz (Figura 20). Figura 20. Diseño en Tablet de Menú Checklists - Checklist Actual En la ActionBar se le añade al Action Overflow la opción de borrar la Checklist actual (elimina los ítems completados anteriormente). 75 Menú Ajustes Desde el Menú Principal se puede acceder, a través del Action Overflow, a los ajustes de la aplicación (Figura 21). Este menú da las opciones de: • • • Cambiar de avión: Al pulsar se abre una nueva ventana con una lista de los XML de aviones encontrados (ver Cuadro 25. Req.Datos DES01 Archivo XML del Avión). Reiniciar la aplicación: Borra todos los datos temporales del vuelo que estaba en curso. Cambiar el idioma: Permite cambiar el idioma de la interfaz (sin tener en cuenta las Checklists que provienen del XML y por lo tanto no son traducidas). Figura 21. Diseño de la Pantalla Ajustes Se descarta el diseño de una pantalla de ajustes para Tablet diferenciada porque el extra de espacio no aporta ninguna ventaja en este caso. Se mostrará la lista utilizando toda la pantalla disponible. 76 5.2 Diseño de los Procesos En este punto pasamos a mostrar el diseño principal de la aplicación desde el punto de vista funcional. Para una mejor comprensión se utilizan diagramas UML (actividad y clases). Para el diseño de este se ha tenido muy en cuenta el uso de recursos tal y como marca uno de los requisitos del proyecto (ver Cuadro 36. Req.No Funcional RNF05 Uso de Recursos). Otro de los puntos que se ha tenido en cuenta es seguir las recomendaciones de Google para el desarrollo de aplicaciones (evitando el uso de funcionalidades y librerías no estándar o no optimizadas para Android). Los diseños funcionales se centran en lo relacionado con los interfaces gráficos Menú Checklists y Checklist Actual. Mostrar Listas y Checklist En Menú Checklist se muestra una lista de Checklists que se carga desde un XML. Debido a que esta debe recordar qué Checklists han sido completadas no se trata solo de mostrarlas sino también de comprobar su estado (completado o no completado) y marcarlo con un stick para que el Piloto sea consciente de ello. Lo mismo ocurre con Checklist Actual, pero en vez de Checklists muestra los Ítems. En las siguientes figuras se ve el funcionamiento (Figura 22 y Figura 23). Figura 22. Diagrama de Actividad - Mostrar Listas Figura 23. Diagrama de Actividad - Mostrar Checklist En las acciones Mostrar Ítem Checklist de XML y Mostrar Ítem XML se carga la información desde un XML pero para mejorar el uso de recursos se crea una estructura de datos (que se ve más adelante) que lee al principio todo el XML y guarda la información dentro de forma que no haya que acceder al XML cada vez que se necesite información y así evitar el coste de memoria y procesador asociado a dicha lectura. 77 Proceso Usar Checklists Trata la funcionalidad asociada al interfaz Menú Checklists. En él se muestra la lista de Checklists generada por la actividad Mostrar Listas (ver Figura 22) y luego el Mostrar Ítems (ver Figura 23). A partir de aquí, el piloto va seleccionando cada uno de los ítems para confirmar su ejecución. Según va pulsando ítems estos se marcan con sticks y se añaden como ítems completados en la estructura de datos. Al final cuando todos están completados se añade la Checklist actual como completada y se informa al usuario que la lista ha sido completada. En la siguiente figura (Figura 24) se puede ver su funcionamiento: Figura 24. Diagrama de Actividad - Usar Checklist Se considera Ítem correcto a seleccionar el ítem inmediatamente inferior al último marcado. Con ello se asegura la ejecución de las tareas secuencialmente. 78 Proceso Usar Checklists de Emergencia Este proceso es similar a Ver Checklist con la diferencia de que no se guarda una relación de ítems y listas completadas, ya que una emergencia puede surgir varias veces y no son listas que se deban ejecutar todas. Figura 25. Diagrama de Actividad - Usar Checklist Emergencia En este caso (Figura 25) se muestran simplemente las listas disponibles sin verificar completadas y como en el caso anterior se comprueba que la ejecución sea secuencial y se marca con un stick (visualmente) indicando que se ha completado. En el caso de salir de la aplicación sí se guardará una relación de ítems completados, pero la gestión será desde el punto de vista de la interfaz. Al completar la lista se lo indica al Piloto y al salir no se guarda ningún ítem. 79 Borrar Checklists Completadas Dentro del interfaz Menú Checklists está (como se ha visto anteriormente) la opción de borrar toda las listas que se han completado o medio completado. El diagrama de actividad asociado sería el siguiente. Figura 26. Diagrama de Actividad - Borrar Checklists Completadas Borrar Ítems Completados Esta función está disponible cuando se muestra una Checklist (Interfaz Checklist Actual). Permite borrar los Ítems completados en ella hasta entonces y si la Checklist estaba completa permite también borrarla de la lista de completadas. Figura 27. Diagrama de Actividad - Borrar Ítems Completados 80 Diagramas de Clase (Libros de Checklists) Las Checklists se guardan en el archivo XML del avión en cuestión en la memoria externa (como ya se ha indicado anteriormente). Debido a que el acceso a un archivo XML es caro desde el punto de vista de recursos, se opta por leer una vez y guardar las Checklist en objetos dentro de la aplicación. Dichos objetos serán instancias de la clase PlaneChecklists (Figura 28). Se instanciarán 2 objetos; uno para Checklist Normales y la otra para las Checklist de Emergencia. La razón de no contenerlas todas en la misma clase es por su separación física en la interfaz y porque las Checklist de emergencia no necesitan guardar su estado. Todas las clases diseñadas para esta aplicación se incluyen dentro de un mismo paquete (package). Las 3 clases que se van a implementar son: PlaneChecklists, Checklist y CheckCompletas. PlaneChecklists: Es la clase principal y desde la que se opera para gestionar todo aquello relacionado con las Checklists. El encapsulado garantizará que el acceso a estas sea mediante sus métodos. Figura 28. Diagrama de Clases - Clase PlaneChecklists Teniendo en cuenta la Figura 28 tenemos: • • • ChecklistsBook (libro): Un Array de Objetos Checklist. Cada uno de estos objetos es una Checklist distinta. Completed: Objeto CheckCompletas que gestiona qué Checklists e Ítems internos están completados y cuáles no. numChecklists: Indica el número de Checklists que contiene el objeto. Útil para la implementación Android. 81 Por la parte de métodos públicos tenemos: • • • • • • • addChecklist(~): Añade una Checklist vacía al libro. addItem(~): Añade un ítem a una Checklist determinada. isCheckCompleted(~): Indica si la lista indicada está completada. getChecklistItems(~): Devuelve un array de Strings con todos los ítems de una Checklist concreta para ser listada en el interfaz mediante un adaptador Android. getAllChecklist(): Devuelve el array de Checklist para listar las Checklist en el interfaz mediante un adaptador Android. resetPlaneChecklists(): Borra todas las Checklists completadas y sus ítems. resetOneChecklist(~): Borra los ítems realizados de una Checklist en particular y si está completada también la desmarca. Checklist: Esta clase guarda la toda información de una Checklist en concreto. Solo se puede instanciar desde dentro del package. Figura 29. Diagrama de Clases - Clase Checklist Según vemos en la Figura 29 consta de: • • • • • • • • Nombre: El nombre de la Checklist (Before Take-off). NumItems: Número de Ítems de la Checklist. Ítems: Array de Strings con todos los Ítems con formato Objeto Acción. Los métodos que tiene son: Constructor. addItem(~): Se le indica el Ítem en forma Objeto - Acción y lo añade a la Checklist. toString(): Necesario para el uso de adaptadores Android. getAllItems(): Devuelve el Array de ítems para ser mostrados por un adaptador Android. getNumItems(): Devuelve el número de ítems que tiene la Checklist. 82 CheckCompletas: Esta clase es la encargada de guardar el estado de las Checklists y sus ítems (completado o no completado). Como la anterior sólo se puede instanciar desde dentro del package. Figura 30. Diagrama de Clases - Clase CheckCompletas Como se ve en la Figura 30, esta se compone de dos Arrays de Integers. La existencia de esta clase se basa en la optimización del uso de recursos. El funcionamiento es el siguiente: Inicialmente a la hora de extraer los datos del XML se crean estas listas de Integers. Según se va leyendo en esta se colocan el número de Ítems de cada Checklist. Cada vez que el usuario selecciona un ítem para marcar que está completado se resta uno al Integer de la lista correspondiente en listaCheck de forma que: • • • Si el Integer = número de Ítems Lista sin Iniciar. Si el Integer [1 - número de Ítems) Lista parcialmente completada. Si el Integer = 0 Lista completada. De la misma forma se puede conocer el número de ítems completados gracias al segundo array (starList) que siempre contiene el número de ítems totales de cada Checklist. También sirve para borrar las listas completadas y sus ítems. Así pues los métodos que contiene son: • • • • • addCheck(~): añade una nueva lista (Integer) a los arrays indicando su número de ítems. setCheck(~): Marca como completados el número de ítems que se indique en la lista correspondiente. resetAllCheck(): Vuelve a inicializar listaCheck con los valores iniciales (de startList) isCheckCompleted(~): Indica si la lista indicada está completada. resetOneCheck(~): Inicializa la lista marcada con el valor de startList asociado. 83 Archivo XML del Avión Como en apartados anteriores se ha mencionado, se utiliza un archivo XML ubicado en la memoria externa para guardar los datos del avión tal como: nombre, pesos, Checklist, etc. La razón de usar XML es poder facilitar a un usuario con un nivel medio de informática la realización de perfiles de avión nuevos. Cada XML comprende un modelo avión. El XML se dividirá en 3 grandes grupos (como se ve en el Cuadro 25). Estos son: Datos Generales, Checklists y Mass & Balance. Como en este proyecto solo se diseña e implementa el apartado de Checklists el XML no tendrá información de los otros 2 apartados (salvo la imprescindible). Así pues cualquier XML de avión seguirá el siguiente patrón: Figura 31. Prototipo de Archivo XML de Avión 84 Capı́tulo 6: Implementació n En este capítulo se muestran los aspectos más significativos de la implementación de la aplicación. Debido a la gran cantidad de trabajo que se sucede en este apartado no se nombrarán todos los procesos, problemas y decisiones que se toman a lo largo de la implementación. El objeto de este capítulo se centra en una visión general del trabajo realizado, los sucesos más importantes y los que han supuesto un cambio en el diseño propuesto. Aunque en la implementación van fuertemente unidos, se puede hacer una distinción desde el interfaz puramente gráfico (colocación de vistas) y la implementación de su funcionamiento. 6.1 Implementación del Interfaz Gráfico El Interfaz tal y como hemos visto en el diseño (5.1 dos versiones; una para móviles y otra para Tablets. Interfaz Gráfica) se divide en El interfaz en Android se especifica mediante archivos XML. Estos se guardan en una carpeta llamada layout dentro del proyecto. Cada archivo XML representa una vista individual, que puede contener dentro elementos visuales u otras vistas XML. Aprovechando esta cualidad se puede reusar las vistas y así se ha intentado durante la implementación. Como dependiendo de la configuración del dispositivo (vista normal o en apaisado) o del tipo de dispositivo (móvil o Tablet) se debe mostrar distintos interfaces el SDK y sus normas proporcionan una serie de modificadores que indican que ciertas vistas solo serán utilizadas en las condiciones que el modificador indique. Los modificadores se señalan en el nombre de la carpeta en la que se colocarán las vistas que tengan que activarse en esa configuración. Por ello tenemos: • • • layout: Todas las vistas que se encuentren aquí se cargarán por defecto, es decir, si no se encuentra una vista que coincida con la configuración actual. layout-land: El Sistema usa estas vistas cuando el dispositivo se encuentra en apaisado (Landscape) layout-sw***dp: El sistema usará estas vistas en el caso que el lado más pequeño de la pantalla disponible sea igual o superior a la cifra marcada (smallest width). Esto a la práctica permite diferenciar un dispositivo móvil de una Tablet. En el proyecto se usa un dp de 600 que suele ser el estándar utilizado para tablets pequeñas(6-7’’). 85 Además se permite la concatenación de modificadores, como es el caso de layoutsw600dp-land, de forma que la vista se utilizaría en el caso de que las 2 condiciones se cumplan. Para el correcto funcionamiento de este sistema los nombres de los archivos deben ser el mismo en cada una de las carpetas que existan modificaciones para que el sistema luego las utilice según la configuración. Para conseguir distintos idiomas se utilizan también modificadores en la carpeta de valores (values). Así tenemos los valores en ingles values–en, español values–es, francés values–fr, etc. Gracias a esta funcionalidad no se necesita una configuración de idioma, pues Android carga el idioma que se corresponda con el que está usando el usuario en el sistema. Si este no existe carga por defecto values (sin modificador). Layouts Principales Dicho esto en el proyecto tenemos los siguientes layouts principales: • main.xml: Determina el layout dependiendo de la configuración. Tiene 2 configuraciones; móvil y Tablet (con dos pequeñas variaciones de normal y apaisado) - En la versión móvil sólo se muestran los botones. Las categorías son mostradas por otra actividad distinta. - En la versión Tablet se muestran los botones en un lado y las listas en catFragment. Figura 32. Layout Principal main.xml • • category_list.xml: Contiene los botones del menú principal. Existen 2 versiones; normal y apaisado. Para el modo Tablet apaisado existe una pequeña modificación que permite ver bien los nombres. checklist_main.xml: Determina el layout del apartado Checklist (Figura 33). Contiene 2 versiones (móvil y Tablet): - En la versión móvil solo existe un apartado llamado frameChecklist y todas las vistas se cargan en ese contenedor (Listas e Ítems). - En la versión Tablet hay 2 apartados; bookChecklist que muestra las listas e itemsChecklist que muestra los ítems. 86 Figura 33. Layout Principal checklist_main.xml El código fuente de estos layouts se encuentran en el Anexo D. El Spinner de Categorías En la versión móvil al acceder a una de las categorías (presionando uno de los 4 Botones del Menú Principal) se muestra una lista con las funciones de dicha categoría. Al no tener disponible los botones (como ocurriría en la versión Tablet) se hace más complejo al usuario cambiar entre categorías por lo que se decide añadir un Spinner (Lista Desplegable) en la Action Bar tal y como recomienda Google. Para ello se utiliza el modo de la Action Bar NAVIGATION_MODE_LIST. Este permite añadir dentro del Action Bar una lista desplegable. Esto se consigue mediante un Adaptador con las opciones que debe mostrar, unos layouts de cómo visualmente van a mostrar los elementos y finalmente se debe implementar el Listener que será llamado cuando se seleccione una categoría desde el Spinner. Ver Figura 34. //Set the Action Bar ActionBar actionbar = getActionBar(); actionbar.setDisplayShowTitleEnabled(false); actionbar.setDisplayHomeAsUpEnabled(true); actionbar.setNavigationMode(ActionBar.NAVIGATION_MODE_LIST); //Set the Spinner Adapter ArrayAdapter<CharSequence> adapter = ArrayAdapter.createFromResource(this, R.array.catActivity_spinner, R.layout.simple_spinner_item); adapter.setDropDownViewResource(android.R.layout.simple_spinner_dropdown_item); //Set the Callback Listener actionbar.setListNavigationCallbacks(adapter, new OnNavigationListener() { @Override //When the user Changes the Category through the Spinner public boolean onNavigationItemSelected(int itemPosition, long itemId) { spinPos=itemPosition; //Set the Fragment Transaction with the new Fragment catFragment catDetail = catFragment.newInstance(spinPos); getFragmentManager().beginTransaction() .replace(android.R.id.content, catDetail) .setTransition(FragmentTransaction.TRANSIT_FRAGMENT_OPEN) .commit(); return true; } }); Figura 34. Código catActivity.java. onCreate() - Implementación del Spinner 87 Pestañas en las Checklists Para mostrar la lista de Checklists Normales o Emergencia se buscaba el uso de pestañas. A partir de Android 4 las pestañas forman parte de la Action Bar y no son una vista que se nombra en los XML de los GUI. Son implementadas desde el código Java y son el otro modo (junto al Spinner) de Navegación Lateral que proporciona Android. Para implementarlas el modo a utilizar debe ser NAVIGATION_MODE_TABS. Este modo necesita que se creen las pestañas necesarias con un nombre a mostrar (que en nuestro caso depende del idioma). A cada pestaña se le asocia una clase implementa el Listener de dicha pestaña (BookTabListener<T>) que indica el comportamiento de las pestañas al cambiar entre ellas. En este caso a dicho Listener se le proporciona una clase heredada de Fragment (bookNormTab y bookEmergTab) que indica el comportamiento y las vistas que tiene que mostrar. //Initiate ActionBar with tabs and up Button actionbar = getActionBar(); actionbar.setDisplayHomeAsUpEnabled(true); actionbar.setNavigationMode(ActionBar.NAVIGATION_MODE_TABS); //Add the Two Tabs Tab NormalChk = actionbar.newTab().setText(R.string.checklist_tab_normal); Tab EmergeChk = actionbar.newTab().setText(R.string.checklist_tab_emergency); //Set the Listeners NormalChk.setTabListener(new BookTabListener<bookNormTab>(this,PFStat.cFTAG_NORMAL,bookNormTab.class)); EmergeChk.setTabListener(new BookTabListener<bookEmergTab>(this,PFStat.cFTAG_EMERGENCY,bookEmergTab.class)); <MORE CODE> //Add the Tabs to the ActionBar and set Selected Tab through isEmergency actionbar.addTab(NormalChk, !isEmergency); actionbar.addTab(EmergeChk, isEmergency); Figura 35. Código CheckActivity.java. onCreate() - Implementación de Pestañas Recursos Visuales Para mejorar el interfaz y hacerlo más atractivo se han utilizado una serie de imágenes e iconos creados por el alumno. El primer recurso es el icono de Checklist de Emergencia. Un icono que muestra una Checklist y una señal de atención o peligro. Para un piloto la relación imagenacción es inmediata ya que tiene similitudes con la forma de una Checklist real. Figura 36. Icono Checklist de Emergencia El segundo recurso es un PNG-9-Pach (escalable dinámicamente) que consiste en una sombra con transparencia que, añadida en las pestañas, ofrece un efecto en 3D en el modo Tablet. 88 El tercer recurso a nombrar es una imagen de un avión simplificado usado en las opciones de la aplicación para elegir el avión actual. También se utiliza un recurso de Android (Iconos Estandarizados) para la opción de Reiniciar la Aplicación. Otros recursos son imágenes con transparencia en el modo Tablet que tienen un carácter puramente ornamental. En el Menú Principal se muestra el logo de la aplicación en grande y en las Checklists se muestra un dibujo de una Checklist. 6.2 Presentación de la Implementación del Sistema Antes de ahondar en los retos de la implementación del sistema vamos a mostrar una visión global de cómo está implementado el sistema. La aplicación puede dividirse en dos grandes grupos (separados además, en 2 paquetes Java distintos): Paquete Principal (com.gmail.mikepilot.PilotFMS) Este Paquete se encarga de la funcionalidad básica de la aplicación. Sus principales funciones y principales componentes son: • • • • • • • • • • • Mostrar el Menú Inicial al ejecutar la Aplicación. Contiene los Menús Principales. Comprobar que todos los recursos necesarios para el correcto funcionamiento están disponibles (incluso solucionar la falta de algunos). Realizar correctamente el comportamiento de las distintas vistas y menús cambiando entre unas y otras. También reubicar las vistas ante un cambio de la orientación del dispositivo. Contiene la implementación de la estructura de datos que guarda las Checklists en tiempo de ejecución (PlaneChecklists, ver 5.2 - Diagramas de Clase). Realizar la traducción de XML a dichas estructuras de datos. Encargarse de cambiar su funcionamiento según el tipo de dispositivo que lo ejecuta (Tablet o Smartphone). Contiene el apartado de Ajustes generales que se encarga de cambiar de avión seleccionado y de reiniciar la aplicación. Recuperar las estructuras de datos actualizadas que devuelven otras actividades. Mostrar una demostración (imagen estática) de las funcionalidades no implementadas en este proyecto. Contiene la implementación de los diálogos de alerta que se muestran en toda la aplicación. 89 A continuación se muestra una lista de las clases que están contenidas (Clase (clase que extiende)) y una breve descripción de su cometido: MainMenu (Activity): Actividad que se encarga mostrar la pantalla Principal y los menús, controla los recursos e inicializa estructuras de datos. MainFragment (Fragment): Muestra la pantalla inicial con los 4 Botones. Es gestionada por MainMenu. CatFragment (ListFragment): Muestra las distintas funcionalidades de cada categoría dependiendo de qué categoría en cuestión se haya pulsado. También es la encargada de iniciar la funcionalidad que desee el usuario y mandar los datos necesarios, así como recibirlos al volver de dicha funcionalidad. Es gestionado por MainMenu o por CatActivity (si se trata de un Smartphone). CatActivity (Activity): Actividad puente que se utiliza en el caso de usar un Smartphone para mostrar las categorías (CatFragment) en una sola vista. Añade una funcionalidad que es el Spinner (Lista Desplegable) que permite cambiar entre categorías desde la misma vista (sin volver Atrás). PilotAlertDialog (DialogFragment): Pequeño Fragment que muestra una ventana de alerta en los casos que la memoria no esté disponible y cierra la actividad. AppPreferences (Activity): Actividad que aloja el Fragment de las preferencias. AppPreferencesFrag (PreferenceFragment): Fragment que se encarga de las preferencias del sistema. Carga la vista, se encarga de buscar archivos XML de aviones para ofrecérselos al usuario en caso de que quiera cambiar de avión y permite, en su caso también, que se reinicie la aplicación. PFStat: (PilotFMS Statics) Contiene todas las constantes estáticas (Strings y Enteros) que se usan en toda la aplicación para evitar el uso de hardcode. PlaneParser: Clase que se encarga de la operación de leer un archivo XML y pasarlo a estructuras de datos que entiende la aplicación. PlaneChecklists, Checklist y CheckCompletas: Implementación de la estructura de datos que contiene las Checklists (ver más atrás). DemoView (Activity): Actividad que muestra una imagen (demostración) de las funciones que aún no han sido implementadas a fin de poder tener, de un modo gráfico, una visión general del futuro sistema completo. TwoOptionAlertDialog(DialogFragment): Fragment que se encarga de mostrar alertas genéricas con dos opciones. TOAlertDialogListener(Interface): Interface que debe indicar comportamiento que tienen los 2 botones de TwoOptionAlertDIalog. 90 el Paquete Checklists (com.gmail.mikepilot.PilotFMS.Papers.Checklist) Este Paquete se encarga exclusivamente de todo lo relacionado con la funcionalidad de Checklists. Sus principales funciones son: • • • • • • Muestra la pantalla de Checklists (que dependiendo del dispositivo serán distintas) y carga la información del avión. Crea 2 Pestañas en la Action Bar (una con las Checklists de Emergencia y otra con las Normales) en las que se muestra una lista de checklists. Muestra las listas de ítems que debe realizar el Piloto en una Checklist previamente seleccionada. Permite al usuario hacer uso de las Checklist haciendo clic en los ítems. Gestiona el funcionamiento de todas las ventanas y menús dentro de la funcionalidad Checklist (moverse hacia una Checklist, volver atrás, Arriba, cambiar orientación, etc.). Devuelve a la aplicación principal las Checklists actualizadas. Estas Funcionalidades están implementadas en las siguientes clases: CheckActivity (Activity): Es la Actividad principal en Checklists. Es la encargada de mostrar las vistas, de crear las pestañas e iniciarlas, de activar las Checklist de emergencia en caso de que el usuario use el Botón Emergencia, controlar las vistas (mostrar las vistas según el dispositivo, entrar en una Checklist determinada, subir o volver atrás, cambiar la orientación), borrar las checklists completadas, etc. BookTab (ListFragment): Fragment abstracto que determina las funcionalidades en común que tienen las pestañas (emergencia y normal). Entre ellas están el mostrar las vistas (dependiendo del dispositivo), marcar la Checklist seleccionada en el modo Tablet,… BookNormTab (BookTab): Especificación de BookTab para las listas normales. Llama al Interface onChecklistSelectedListener (que implementa CheckActivity) para mostrar la Checklist Normal seleccionada. BookEmergTab (BookTab): Especificación de BookTab para las listas de emergencia. Llama al Interface onChecklistSelectedListener (que implementa CheckActivity) para mostrar la Checklist de Emergencia seleccionada. BookTabListener (TabListener): Se encarga de gestionar las pestañas (BookNormTab y BookEmergTab). Las Inicializa y controla cuando se cambian entre ellas o se pulsa sobre la que está activa. Según el caso, realiza un cambio de vista (en la pantalla que ocupan), o también realizan alguna tarea de borrado de datos o ajuste de parámetros. ChecklistDetails (ListFragment): Se encarga de mostrar los ítems de una Checklist determinada por CheckActivity, y de guardar las listas 91 completadas y los ítems de cada una de ellas que estén completados. También añade la opción de borrar sólo la Checklist actual. OnChecklistSelectedListener (Interface): Interface implementado en la práctica por CheckActivity que determina el método onChecklistSelected(), que se encarga de hacer que el dispositivo muestre una Checklist elegida por el usuario (es decir, muestre sus ítems). 6.3 Vista General del Sistema Para desarrollar aplicaciones con distintas versiones, dependiendo del dispositivo (a partir de Ice Cream Sandwich), se han encontrado dos posibilidades: • • Usar varias Actividades para mostrar los distintos Fragments que muestran las vistas de forma que el control de la aplicación se distribuye entre ellas. Usar una única actividad que va mostrando todos los Fragments según se vayan necesitando y por tanto se encarga de todo el control de la aplicación. Dado que ambas son válidas y depende del tipo de aplicación y del desarrollador, para enriquecer más los conocimientos de Android decidimos realizar cada paquete de una forma distinta; el paquete principal contiene 4 actividades que se reparten las tareas y el paquete Checklists utiliza una única Activity que gestiona todo el trabajo. Figura 37. Relación Activities-Fragments En el cuadro anterior (Figura 37) se muestra la relación entre las distintas Activities y los Fragments que gestionan en cada paquete por separado. El movimiento 92 entre Activities se realiza mediante Intents (ver Intent). Las actividades pueden reusar un mismo Fragment de forma que se aprovecha el código y la funcionalidad para varios apartados. El caso de CatActivity solo ocurre si se utiliza un SmartPhone porque se crea una segunda vista para ver el contenido de la categoría. Si se usa una Tablet todo se muestra en la misma pantalla y CatActivity nunca se crea. 6.4 Elementos Comunes del Sistema Aunque cada clase tenga su propio cometido, todas contienen una serie de elementos comunes que se explican a continuación y que ayudan a entender mejor la implementación de una aplicación Android. Los dividimos en dos apartados Métodos (de una clase o clases) y Procedimientos (entendiendo como formas de proceder). Métodos Comunes Como ya se explica en 2.6 - Ciclo de Vida de una Activity, utilizamos las llamadas que son realizadas por el sistema según cambian el estado de la actividad. De todas esas posibilidades, en la práctica se usan unas pocas (onCreate, onStart y onCreateView). Sin embargo sí existen otras llamadas que realiza el sistema para muchos otros casos, y son, junto con las antes nombradas, las que dan autentica movilidad al sistema. En nuestro caso los métodos que más utilizamos son: onCreate(Bundle estadoGuardado): Lo utilizamos para comprobar que los recursos están disponibles, inicializar variables, cargar valores enviados por otra aplicación, indicar el comportamiento de elementos como la ActionBar y establecer su layout XML. También es la encargada de recuperar los datos de un estado anterior. Esto ocurre porque al cambiar la orientación Android re-crea la actividad completa para mostrar su nueva vista. onCreateView(Bundle estadoGuardado): Se ejecuta cuando la Actividad/Fragment va a ser mostrado en pantalla. Tiene más sentido usarlo en los Fragments ya que puede darse el caso de crear un Fragment pero no mostrarlo inmediatamente en pantalla. También contiene el Bundle que te permite recuperar datos de un estado anterior. onStart(): Se ejecuta cuando se va a iniciar la actividad, ya sea por primera vez , al volver de otra actividad o de otra aplicación del teléfono. En este proyecto se utiliza para modificar o actualizar valores que han podido ser cambiados por otras aplicaciones. onActivityCreated(Bundle estadoGuardado): Esta es exclusiva de los Fragments y se ejecuta una vez la actividad asociada a ese Fragment (en ese momento) termina la ejecución de su onCreate(). En este caso lo usamos porque dentro de este método nos aseguramos que podemos acceder a cualquier elemento de la Activity con el convencimiento de que está todo inicializado y es 93 funcional (por ejemplo el acceso a los Books de Checklists que se crean en la actividad). Por ello, en este método realizamos todo lo que hace onCreate() del Fragment por lo que normalmente, si existe onActivityCreated() no existe un onCreate(), y si existe tiene poca carga. onSaveInstanceState(Bundle estadoSalida): Este método es el que se tiene que encargar de guardar todos los datos que sean necesarios ante una destrucción del Fragment/Activity. Se ejecuta automáticamente al destruir una Activity/Fragment. Principalmente lo usamos para guardar posiciones del cursor, vista cargada y también guarda los Books de Checklist para no tener que volver a buscarlos en el XML. onCreateOptionsMenu(Menu menu): Este se utiliza para añadir opciones en el ActionBar, ya sean iconos u opciones de texto. Las carga de un XML (alojado en la carpeta menú) o también se puede crear en el código a través de la clase Menu. En nuestro caso utilizamos los 2 métodos a lo largo de la aplicación. Hay que tener en cuenta que este método sólo crea la vista (icono, nombre, etc.) y no le da funcionalidad ninguna. onOptionsItemSelected(MenuItem menu): Este método se ejecuta cuando un ítem de la ActionBar es pulsado. El Ítem pulsado se reconoce por el MenuItem que se le pasa. En nuestra aplicación usamos el método menu.getItemId() para obtener su identificador y hacer un switch a fin de discriminar qué opción se ha pulsado y, en consecuencia, qué acción se debe tomar. Por ejemplo, aquí es donde se da funcionalidad al botón Arriba, al botón de Checklist de Emergencia, opción de borrar Checklist… onBackPressed(): Se ejecuta cuando se pulsa el botón volver del dispositivo. Como regla general funciona de forma autónoma volviendo a la pantalla anterior, pero en algunos casos hay que sobrescribirla y guardar datos o mostrar vistas que por defecto no mostrarían. En nuestro caso tenemos que implementarla porque según sea un Smartphone o una Tablet el comportamiento es distinto. Además se encarga también de devolver los Books actualizados a la actividad superior ya que sino se perderían. onItemListClick(Listview lista, View ítem, int posición, int id): Es propio de los ListFragments (subclase de Fragments que contiene una Lista). Se ejecuta cuando el usuario hace clic en un Ítem en particular. Es donde se le da funcionalidad. Para ello se puede conocer el ítem por la posición en la lista (Int) o por alguna propiedad (View). En nuestro caso utilizamos la posición y lo hacemos en muchos lugares: elegir categoría, elegir función, elegir lista, seleccionar ítem completado… 94 Procedimientos Comunes Iniciar Actividades y devolver Elementos: Ya hemos hablado de pasar datos a una Activity mediante Intent y devolver datos, pero no hemos concretado cómo se hace: • Primero hay que crear una instancia y meter los datos dentro como pares llave-valor usando un método universal para todo tipo de datos: intent.putExtra(“nombre”, variable). También existe la posibilidad de crear un Intent pasándole al constructor un Bundle, por lo que automáticamente metería todo lo que hay en él dentro del Intent. • Segundo hay que indicarle al Intent quien es el Destinatario. En nuestro caso utilizamos el método intent.setClass(contexto, clase.java) donde le añadimos la clase que implementa la Activity que queremos que se ejecute. Existen otros métodos de mandar un destinatario de forma no explicita (lo elige Android), pero que no se utilizan en este proyecto. • Entonces se ejecuta el método startActivityForResult(Intent, Código de Respuesta). A este se le indica el Intent creado y un código que servirá para identificar luego el retorno de la aplicación. Este método hace que se cree la actividad y se muestre en pantalla. • Dentro de la nueva Actividad se accede al intent mediante intent=getIntent() y una vez tenemos la instancia de éste accedemos a sus extras guardados usando variable=intent.get___Extra(“nombre”), que varía según el tipo devuelto. • Cuando se pulsa atrás o Arriba dentro de la nueva actividad estos deben ser programados para que recojan los datos necesarios, marquen la actividad como correcta y la finalicen. Para ello se utiliza setResult(resultado, Intent) de igual forma se le añaden los datos al Intent, se ejecuta esta orden y finalmente la orden finish(). • Cuando se finaliza la actividad el flujo vuelve a la actividad que había llamado y se ejecuta el método onActivityResult(código de Respuesta, Resultado, Intent). Dentro de este se debe realizar la comprobación de que sea correcto y que se trate de la actividad deseada. Una vez realizada la comprobación se accede al Intent y se recogen los datos mediante variable=intent.get___Extra(“nombre”). 95 Guardar/Recuperar el Estado Anterior: Como hemos mencionado anteriormente existe una llamada onSaveInstanceState() que usamos para guardar datos necesarios. El procedimiento que se lleva a cabo es el siguiente: • Se sobrescribe el método onSaveInstanceState(Bundle bdle) de la siguiente forma: Se usa el Bundle para introducir los valores dentro de él mediante pares llave-valor usando los métodos bdle.put___(llave, variable) según el tipo de variable. • Al cerrarse la Actividad/Fragment el sistema llama a este método y guarda los datos. • Al crearse de nuevo en el método de inicialización (ya sea onCreate(), onActivityCreated() u onCreateView()) se hace una condicional al Bundle aportado. Si es NULL significa que no hay estado guardado y no hay nada que recuperar. Si por el contrario tiene información se recupera usando variable=bdle.get____(llave) para cada uno de los datos guardados. Transacción de Fragments: Android llama Transacción en este contexto a cambiar la vista actual definida por un Fragment por otro distinto dentro de la misma Actividad. Para realizar estas transacciones se utiliza el FragmentManager, que es la clase que gestiona los cambios de Fragments. Estos cambios se denominan FragmentTransaction y se realizan de la siguiente forma: • Se consigue el Fragment Manager y se le pide una nueva transacción mediante el método de la Actividad transaction=getFragmentManager().beginTransaction(). • Se le añade un tipo de animación que se usará al cambiar el Fragment con transaction.setTransition(tipo de animación). • En algunas ocasiones interesa que la vista que se queda detrás se guarde para luego acceder a ella al volver atrás o subir arriba, para ello se usa la opción transaction.addToBackState(true). Esto produce que la vista quede guardada en una pila de Fragments que crea Android. • Se le indica el cambio de pantalla donde se aporta el nuevo Fragment a mostrar. Para ello se usa: transaction.replace(contenedor, Fragment, Tag identidicativo) El contenedor es donde la vista es mostrada, que dependiendo del dispositivo puede ser distinta; el Fragment es el nuevo a mostrar, y el Tag identificativo sirve para luego poder rescatar la vista de la pila de fragments. • Finalmente y para que la transacción se lleve a cabo hay que ejecutar el método transaction.commit(). En algunos casos (volver atrás o arriba) 96 puede ser interesante borrar la pila de Fragments (o parte de ella) ya que los guardados ya no tienen sentido en la posición actual, el método que permite eso es getFragmentManager().popBackStack() o su variante con la opción de introducir el Tag hasta el cual borra. Muestra de Diálogos: Los diálogos son ventanas que se muestran al usuario tapando parcialmente la vista del programa. Como comentamos anteriormente (ver 2.9 - Patrones de Diseño) sólo se deben mostrar al usuario cuando hay un cambio o suceso importante en la aplicación que repercute directamente al usuario. En nuestro caso lo utilizamos en los casos siguientes: Falta de acceso a la memoria externa (por la que se nutre de los datos de checklists), cambios de configuración y reinicio de todas las checklists. Para ello se crea una nueva clase que extiende a DialogFragment. Dicha clase tiene: • Constructor estático newInstance(título, mensaje, ok, cancel): En él se le indican los recursos String que contienen el título, el mensaje, el mensaje en el botón ok y el mensaje en el botón cancelar. Este crea una instancia de la clase y le añade todos los strings como extras (Bundle). • Método obligado onCreateDialog(bundle estadoGuardado). Este método se ejecuta al mostrarse el diálogo. Este crea el diálogo usando los argumentos anteriores y también debe definir un comportamiento para los botones OK y CANCEL mediante builder.setPositiveButton() y builder.setNegativeButton(). Cada uno de estos métodos se define mediante una clase anónima que implementa las acciones que realizan cada uno de ellos. En nuestro caso ejecuta los métodos (para cada caso) de un Interface (el Listener TOAlertDialogListener) que la Activity que quiere mostrarlo debe implementar. Finalmente debe instanciarse el diálogo de la siguiente forma: • Se llama al constructor estático y se le pasan los parámetros antes mencionados. myAlertDialog.newInstance(__,__,__,__). • Se le indica al dialogo que debe ser mostrado medante: myAlertDialog.show(Gestor de Fragments, Tag Identificativo). 97 6.5 Principales Retos y Cambios de Diseño En este apartado se exponen los hechos más destacables de la implementación de la aplicación; los que han significado un cambio en el planteamiento inicial y aquellos que han supuesto un esfuerzo para superarlos. En primer lugar los cambios de diseño: Cambio de Diseño - Mostrar Lista y Mostrar Ítems En el diseño inicial (ver punto 5.2 Diseño de los Procesos) se contemplan dos procesos: uno para mostrar las lista de checklists y otro para mostrar los ítems de una checklist. Durante la implementación se realizan una serie de cambios respecto a lo diseñado. Mostrar Lista: En el caso de Mostrar Lista, decidimos eliminar la característica de mostrar si una lista ha sido completa por 2 razones: primero, porque no supone una funcionalidad importante (un piloto conoce en qué parte de un vuelo se encuentra); y segundo, por simplificar la complejidad el proyecto. En consecuencia el diagrama de Actividad se modifica y termina por resultar una sola acción, que es “Mostrar Ítem Checklist de PlaneChecklsits” hasta que se muestren todas las Checklists. Dicha acción se realiza automáticamente con la utilización del Adaptador de Listas que proporciona Android de la siguiente manera (ver Figura 38). public void onActivityCreated(Bundle savedInstanceState) { super.onActivityCreated(savedInstanceState); //Set the adapter with the Checklist information from CheckActivity CheckActivity parentAct = (CheckActivity) getActivity(); setListAdapter( new ArrayAdapter<Checklist>( getActivity(), android.R.layout.simple_list_item_activated_1, parentAct.normalbook.getAllChecklists() ) ); } Figura 38. Método onActivityCreated() de BookNormTab.java En este ejemplo (de las listas Normales) se puede ver como se llama al método SetListAdapter() que espera un Adaptador con la lista a mostrar. Este Adaptador se crea de forma anónima ya que no va a ser utilizado por nadie más. Se realiza de la siguiente manera: new ArrayAdapter<Tipo de elemento a mostrar>( contexto, formato visual de la celda, lugar donde se encuentran los objetos);. El tipo de elemento debe tener definido el método toString() para que pueda ser impreso en el ítem correspondiente. El lugar de los elementos en este caso es la estructura de datos PlaneChecklist (una instancia suya llamada normalBook que contiene las checklists normales). 98 Mostrar Checklist: En el caso de mostrar una checklist el cambio es más bien puntual. En vez de realizar el marcado de ítems al mostrar (tal y como se plasma en el diagrama, ver Figura 23), éste se produce en un segundo pase ya que la muestra de ítems es gestionada internamente por Android. Para ello utilizamos un método llamado checkSavedItems() (ver Figura 39). void checkSavedItems(){ // Get the number of completed items for the current Checklist. completedItems = actualBook.getCheckNumItems(currentChecklist) actualBook.getRemainingItems(currentChecklist); // Mark (with a stick) that number of items that are already done. for(int i=0;i< completedItems;i++){ getListView().setItemChecked(i, true); } } Figura 39. Método checkSavedItems() de CheckDetail.java En este código primero se calcula el número de ítems que hay que marcar (aprovechando la particularidad de que se completan de forma secuencial) y, una vez conocido el número, se marcan. Cambio de Diseño - Borrar Checklist En el diseño de la aplicación (ver punto 5.2 Diseño de los Procesos - Borrar Ítems Completados) se muestra un diálogo de confirmación del usuario, pero consideramos que para el borrado de una checklist no queda suficientemente justificado su existencia debido a que si se pulsa por error no supone un gran esfuerzo repetir la checklist. Por lo cual se decide eliminar el diálogo. Cambio de Diseño – Usar Checklist de Emergencia El proceso Usar Checklist de Emergencia (ver punto 5.2 Diseño de los Procesos) también sufre cambios en la implementación. Debido a que Android destruye la actividad cuando se cambia la configuración (cambio de orientación) se deben guardar los ítems para que se vuelvan a cargar. Ese cambio hace que el proceso de usar las checklist de emergencia sea igual que el de checklists normales, con una diferencia; al salir del proceso se borran todos los cambios realizados usando el método de PlaneChecklists resetPlaneChecklists(). Este cambio resulta un poco problemático debido a que existen varias formas de salir del proceso (botón atrás, botón arriba, pulsar pestaña,…) y debe de realizarse dicho borrado en esos eventos. 99 Implementación de PlaneChecklists Tal y como se describe en el capítulo 5.2 Diseño de los Procesos - Diagramas de Clase, las checklists se guardan en una estructura de datos que evita el tener que acceder al XML cada vez y soluciona el problema de guardar las checklists e ítems completados. La implementación en un primer momento se realiza siguiendo el diseño, pero, con la experiencia ganada de haber programado parte de la aplicación, nos damos cuenta de que se pueden eliminar algunas variables y se necesitan nuevos métodos. Los cambios que se realizan se nombran a continuación: Checklist.java: En esta clase los cambios son: • Se elimina la variable int numitems, debido a que el ListArray contiene el método listArray.size() que ya lo proporciona. • El método toString() que devuelve un String con el nombre de la Checklist se debe declarar como público para que el Adaptador de las Listas de checklists puedan llamarla y conseguir el nombre. CheckCompletas.java: En esta clase las modificaciones son: • Se añade una variable nueva llamada modified de tipo Boolean. Esta indica si las checklists (Array de enteros) han sido modificadas, es decir, si no se ha realizado ningún ítem en ninguna lista. Esta variable se utiliza para mejorar el rendimiento evitando realizar operaciones sobre los Arrays cuando no es necesario realizarlas. • Se añade el método int getRemainingItems(int iden). Este devuelve, para una Checklist dada, el número de ítems que queda por realizar. La razón por la que se crea este método es que, a la hora de redibujar los Ítems que ya han sido realizados necesitamos conocer los que quedan por realizar (que es lo que realmente se almacena). PlaneChecklists.java: Esta clase es la que gestiona todo y por la cual se accede al resto. Por ello es la que más varía: • En primer lugar se realiza un cambio en la forma en la que se inicia. Debido a que al inicializar no se conocen el número de checklists e ítems ya que son añadidas secuencialmente por el lector de XML hay que esperar a tener toda la información para inicializar el CheckCompletas. Por ello se crea el método void enableChecklistStatus() que se debe ejecutar una vez se han cargado todos los datos (Checklist e ítems) del XML en el libro. • Se añade un Boolean saveStatus que indica si el libro ya ha sido inicializado con enableChecklistStatus(). 100 • Eliminamos la variable int numChecklist ya que el ArrayList de Checklist nos proporciona ese dato con su método size(). • Se añade el método int getReamainingItems(int iden) que responde al método de CheckCompletas. • Nos percatamos de que no se había declarado un método en esta clase que redujera el número de ítems que se han completado, por lo que desde la aplicación no se podía reducir el número de ítems remanentes. A este nuevo método se le nombra void setNewCheckedItems(int iden, int numOk) y responde al método de CheckCompletas llamado setCheck(int iden, int numOk). • Finalmente se añade otro nuevo método: Checklist getOneChecklist(int iden). Este devuelve el objeto Checklist elegido. La necesidad de este método se debe a que en modo Smartphone el nombre de la Checklist se pone en la ActionBar y por lo tanto se necesita acceder individualmente a dicho Checklist para luego usar su toString() y cargar ese String en el subtítulo de la ActionBar. Definidos los cambios del diseño de cada clase hay que añadir otro cambio que afecta a todos, que no es más que definir los constructores de la clase como públicos en vez de package porque son instanciados desde fuera del paquete en la aplicación. El último cambio a esta clase es la implementación del interface Parcelable (buscar Parcelable en [4]). Resumiendo, este interface consigue algo parecido a Serializable de Java, es decir, permite que esta estructura de datos se pueda pasar entre distintas actividades-programas, pero de una forma mucho más eficiente y preparada específicamente para Android. La razón por la cual implementamos este interface es porque los Libros de Checklists se van pasando entre aplicaciones y no se pueden guardar tal cual en un Bundle. Dicha implementación se realiza siguiendo las pautas de Android Developers [4]. De modo esquematizado se realiza tal que así: • • • Se escribe la función writeToParcel(Parcel save, int flag) que permite guardar en el Parcel tipos básicos de variables y también otros objetos Parcelables (se pueden anidar). Se sobrecarga el constructor para que se inicialice con un parámetro Parcel. En dicho Parcel se puede acceder a los valores guardados por writeToParcel(). Se crea una variable estática Parcelable.Creator que es la que inicializa una instancia de la clase principal usando el constructor sobrecargado. 101 • Se escribe la función describeContents() y que devuelve 0. Su función no es necesaria en este proyecto. Finalmente mostramos los retos que ha supuesto el añadirle dos versiones distintas según si la aplicación se ejecuta desde un móvil o una Tablet. Versiones SmartPhone y Tablet – Pestañas Las pestañas han sido uno de los elementos que más problemas han causado debido a los cambios que Android ha realizado en las últimas versiones. En un principio las pestañas de las Checklists (Normales o Emergencia) eran independientes y estaban ligadas a la ventana en la que se abría (una nueva ventana en versión Smartphone y la ventana de la izquierda en versión Tablet). Así en principio, el tipo de dispositivo era inherente al comportamiento de estas. Pero las nuevas directrices de Android cambian el ámbito de las pestañas al de la Actividad, por lo que no se pueden implementar de forma aislada y deben tener en cuenta el resto de elementos de la vista. En una primera versión se implementaban dentro de la clase de la actividad de checklists, CheckActivity; pero el código se volvía muy confuso y se hacía difícil el depurado de errores. La solución más limpia y elegante que se encuentra es la de crear 2 Listeners (BookTabListener.java; una instancia para cada pestaña) que responden a los cambios que se realizan en cada una ellas por separado. La declaración en la clase principal se muestra en el Punto 6.1 Implementación del Interfaz Gráfico – Pestañas en las Checklists (ver más atrás). En el Listener, los 3 métodos que se implementan son: • • • onTabSelected() (al ser seleccionada): Realiza en la ventana correcta (dependiendo de la versión) la transacción del Fragment (pone delante el Fragment que contiene dicho Listener, ya sean las listas Normales o las listas de Emergencia). onTabReselected() (al seleccionar la pestaña ya activa): En este caso sólo tiene función si es un smartPhone; vuelve a las listas (volviendo atrás en la pila de Fragments), borra el nombre de Checklist del título y si además son emergencia borra los ítems realizados. onTabUnselected() (al ser seleccionada otra pestaña): Dependiendo de la versión, o vuelve atrás en los Fragments(Smartphone) o crea una vista vacía(Tablet), borra los índices que muestran la Checklist elegida anteriormente y, si es el caso, borra los ítems de las Checklist de Emergencia. 102 Hasta llegar a este modelo hubo que realizar muchos cambios debido a problemas como: realizar el trabajo 2 veces, superponer dos vistas, no mostrar un elemento antes marcado… Versiones SmartPhone y Tablet – Up & Back Como se ve en 2.9 Interfaz de Usuario - Patrones de Diseño, los botones Arriba y Atrás tienen comportamientos distintos, pero dependiendo del dispositivo también cambia. En el caso de Tablet el botón atrás responde casi siempre a volver a la Actividad anterior, pero en el caso de Smartphone no es así, ya que dentro de una misma actividad hay varias vistas, es por ello que se ha tenido muy en cuenta estos comportamientos. El botón arriba es parecido, pero así como el botón atrás funciona de forma más o menos autónoma, en este hay que programar todo su comportamiento. La diferencia en este proyecto entre ambos botones radica en la posibilidad de iniciar las checklists de emergencia desde cualquier punto de la aplicación, por lo que Atrás deberá volver a la función anterior (donde se pulso el botón Emergencia) y Arriba debe siempre volver a la categoría Papeles. La dificultad de estas funcionalidades en este proyecto está en la actividad de las Checklist, CheckActivity, ya que es la que se debe encargar de luego volver donde debe, devolviendo además los libros de Checklist actualizados. Durante la implementación surgieron problemas en los que no se volvía donde debía, o las listas no se devolvían actualizadas. Versiones SmartPhone y Tablet – Nombre de Checklist Aunque a la práctica pueda parecer una nimiedad, en la versión Smartphone dentro de una Checklist concreta se debe notificar al usuario de alguna forma en qué Checklist está. En un principio se pensó en un texto justo encima de los ítems tal que el nombre del avión en las listas. Supuestamente con la declaración de un TextView debería ser suficiente, pero debido a la forma en la cual se definen las vistas de los ítems en la actividad ocurría un error; no se mostraban los ítems. Se estuvo buscando el origen del problema, pero el código estaba correcto y no se pudo solucionar. La razón reside en el funcionamiento interno de Android, así que tuvimos que replantear el problema. La solución ha sido añadir este nombre de la checklist en el título de la aplicación como subtítulo. Con este cambio se soluciona por completo e incluso deja la vista más limpia y aprovecha el espacio limitado de un móvil. 103 Capı́tulo 7: Pruebas En este pequeño capítulo se detallan las pruebas realizadas con la aplicación final. Dado que son muchas las pruebas, se han dividido en distintos ámbitos para una mejor lectura y comprensión de estas. Hay que puntualizar que una ventaja que ofrece Eclipse y el plug-in de Android es el de poder ir probando la aplicación sin terminarla según se va implementando, por lo que la mayoría de las pruebas realizadas al finalizar ya se habían comprobado durante la implementación. Para todas estas pruebas se tiene en cuenta las dos versiones de la aplicación (Smartphone y Tablet), así pues siempre que no se puntualice sobre ninguna en concreto se supone que la prueba se refiere a las 2 versiones, es decir, se realiza la prueba 2 veces, una para cada versión. 7.1 Pruebas Visuales En este apartado se tienen en cuenta los aspectos visuales como son, posición y tamaño de botones, tamaño de Texto, colores, imágenes, etc. • • • • • • Icono: El icono se muestra correctamente tanto en la aplicación como en el Launcher del móvil. Menú Principal – Posición, tamaño y color de los Botones: Correcto en todas las configuraciones (tiene 3 versiones; normal, móvil apaisado y Tablet). Muestra correctamente la transparencia del logo de la aplicación en modo Tablet. Menú Categorías – Pruebas visuales: Se muestran las listas correctamente con según la elegida y un tamaño adecuado. Se muestra correctamente el Spinner (versión móvil) y permite cambio entre ellas a través de él. Menú Ajustes – Pruebas visuales: Muestra correctamente las 2 opciones con las imágenes correctas y los subtítulos que corresponden. Proceso Checklists – Pruebas visuales: Se muestra correctamente las pestañas. En modo Tablet se muestra la transparencia con una Checklist dibujada. Proceso Checklists – Lista de Checklists: Se muestran correctamente las listas con un tono más oscuro. En modo Tablet se muestra el sombreado 3D correctamente. 104 • Menú Checklists – Lista de Ítems: Muestra los Ítems correctamente con su Stick adosado con el color que la versión de Android lleva por defecto. Se ha comprobado que en dispositivos Sony el stick no resalta demasiado, pero es un problema inherente a la aplicación. 7.2 Pruebas de Versiones En este apartado se prueba que la aplicación cambia su forma de mostrarse según si se trata de un smartphone o de una Tablet. • • • • Menú Principal: Se comprueba satisfactoriamente que en la versión móvil se muestra correctamente el menú de botones y luego el de categorías y en la versión Tablet se cargan ambos a la vez. Menú Categoría: En la versión móvil se muestra correctamente el Spinner y en la Tablet no se muestra. Proceso Checklists: Se comprueba satisfactoriamente que en la versión móvil se muestra correctamente la lista de Checklists y luego la de ítems, y en la versión Tablet se cargan ambas a la vez. Proceso Checklists – Checklist Actual: Se comprueba que en la versión móvil se muestra el nombre de la checklist actual en el título y en la versión Tablet se queda marcada la checklist actual. 7.3 Pruebas de Orientación Debido a que Android re-crea las actividades al cambiar la orientación del dispositivo (normal-portrait y apaisado-landscape) hay que tener en cuenta que funcione todo correctamente al realizar el cambio. • • • • Menú Principal: Se comprueba el en el cambio se guardan todos los elementos (libros y la categoría en Tablet) y se redibuja correctamente. Menú Categoría: En la versión móvil, al cambiar la orientación se muestra correctamente la lista de funciones que estaba mostrada anteriormente. El Spinner también muestra correctamente la categoría actual. Proceso Checklists: Se comprueba satisfactoriamente que al cambiar la orientación se guarda la pestaña elegida y los libros. En la versión Tablet se selecciona y se carga también la checklist si había sido elegida. Proceso Checklists – Checklist Actual: Se comprueba que al cambiar orientación se cargan de nuevo los ítems con los sticks tal y como estaban antes del cambio. 105 • • Menú Ajustes: En el cambio de orientación se muestra correctamente la vista y se seleccionan correctamente los ajustes que estaban elegidos. Vista Demo: Al pulsar cualquier función no implementada se comprueba que muestra una imagen de demostración que no cambia aunque se cambie la orientación (no responde al cambio). 7.4 Pruebas sobre el Guardado de Datos Aunque en el apartado anterior ya se tiene en cuenta el guardado que ocurre al cambiar la orientación, también existen otras razones por las que se puede perder algún dato. • • • • • • Menú Principal: Se escriben correctamente los Libros de Checklist desde el XML. Al entrar en una categoría o al pulsar el botón emergencia estos se pasan correctamente. Menú Categoría: En versión móvil recibe y carga correctamente los libros y la categoría a mostrar. Al seleccionar la función deseada envía los datos correctamente a la actividad asociada. Proceso Checklists: Recibe y carga correctamente los libros y si proviene del botón emergencia activa automáticamente la pestaña Emergencias. Al volver devuelve correctamente los libros actualizados. Proceso Checklists – Checklist Actual: Se comprueba que guarda los ítems pulsados. Menú Ajustes – Cambio de Avión: Al cambiar un ajuste se guarda correctamente. Cambiar de Aplicación: Se comprueba que si se pulsa el botón Home; o se atiende a una, llamada, mensaje; o se accede a alguna aplicación mediante una notificación, al volver a la aplicación recupera su estado y datos exactamente como estaban. El tiempo por el que permanecen intactos depende del dispositivo. 106 7.5 Pruebas sobre la Disponibilidad de Recursos Esta serie de pruebas se encargan de asegurar que la aplicación gestiona bien los recursos del dispositivo. • • • • • • • Menú Principal – Sin Almacenamiento Externo: Se comprueba que la aplicación avisa que no se tiene acceso a la memoria externa y se cierra la aplicación. Menú Principal – Almacenamiento USB conectado: Se comprueba que la aplicación avisa cuando el almacenamiento está conectado y cierra la aplicación. Menú Principal – Archivos en la memoria Externa: Se comprueba que la aplicación crea los directorios y archivos necesarios básicos cuando estos no existen en la memoria externa. Menú Principal – Avión Cargado: Se comprueba que la aplicación carga correctamente el avión del archivo XML seleccionado. Menú Principal – Avión Cargado Borrado: Se comprueba que la aplicación cambia al avión básico cuando se ha borrado el archivo XML del avión que estaba elegido en ese momento. Menú Ajustes – Almacenamiento externo Disponible Al elegir otro avión comprobamos en el caso de que no se pueda acceder a la memoria externa (por USB conectado en modo compartir o por falta del mismo), la aplicación avisa con un Diálogo y cancela el cambio de avión. Menú Ajustes - Archivos: Al elegir otro avión comprobamos que se han cargado todos los XML que se encuentran en la carpeta Planes. 107 7.6 Pruebas de Navegación En este apartado se realizan pruebas sobre la navegación entre los distintos menús y usando todas las posibilidades que existe para moverse entre ellos. • • • • • • • • • De Menú Principal a Categoría: Se prueba que la aplicación accede correctamente a la categoría elegida. En versión móvil también se comprueba que el cambio entre categorías usando el Spinner funciona correctamente y que pulsando Atrás y Arriba se vuelve al menú principal. De Categoría a Checklists: Se comprueba que desde categoría se accede a Checklists correctamente. En versión móvil Atrás y Arriba devuelven al mismo sitio (Categoría). De Cualquier sitio a Emergencia: Se comprueba que al pulsar el botón “Checklist de Emergencia” se abre directamente las Checklists con la pestaña emergencia. Al pulsar Atrás vuelve correctamente al sitio de antes. Al pulsar Arriba vuelve al Menú Principal (o categoría si es móvil). De Checklists a Lista de Ítems: Al pulsar una lista concreta se accede correctamente a los Ítems. Al pulsar Atrás o Arriba se comprueba que vuelve a la lista de checklists (o al menú principal si es Tablet). En la Lista de Ítems: En la versión móvil, dentro de la lista de ítems se comprueba que al pulsar una pestaña muestra la lista de checklist seleccionada. De Menú Principal a Ajustes: al pulsar el Action Overflow y seleccionar ajustes se abre una nueva vista con los ajustes de forma correcta. Al pulsar Atrás o Arriba se devuelve correctamente al menú principal. De menú Principal a cualquier Vista Demo: Se abre correctamente una ventana con una imagen de demostración de la futura función. Al pulsar Atrás o Arriba devuelve correctamente al Menú Principal (o categoría si es Móvil). Cambiar de Aplicación: Se comprueba que si se pulsa el botón Home; o se atiende a una, llamada, mensaje; o se accede a alguna aplicación mediante una notificación, al volver a la aplicación se abre en la ventana que se había dejado. Cerrar la Aplicación: Se comprueba que si se pulsa el botón Atrás en menú principal se cierra la aplicación olvidando todos los datos temporales. 108 7.7 Pruebas de Funcionamiento de Checklists Las siguientes pruebas se encargan de ver el correcto funcionamiento de las Checklists. • • • • • • Muestra de Avión: Se comprueba que en la lista de Checklist aparece el nombre correcto del Avión seleccionado. Cambio de Pestañas: Al cambiar la pestaña se carga correctamente la lista de Checklists correspondiente. Elegir Checklist: Al elegir una Checklist se muestra correctamente sus ítems cargando además los que ya están completados. Al cambiar a otra también los carga sin problema. Muestra de checklist: Al estar en una checklist (móvil) se comprueba que el nombre del título de la aplicación cambia a tener el nombre de dicha checklist y que cambia según se cambie de checklist o desaparece al salir. Si se tiene seleccionada una checklist (Tablet) se comprueba que siempre se queda marcada la checklist que se está viendo en ese momento. Seleccionar Ítems: Se comprueba que al seleccionar un Ítem solo lo marca si es el secuencialmente correcto. Checklist Completada: Al completar una Checklist se comprueba que avisa al usuario mediante un Toast. 7.8 Pruebas de Borrado de Datos En este apartado se comprueba que el borrado de datos en los distintos apartados de la aplicación se efectúa correctamente. • • • Borrado de Checklist Actual: Dentro de una checklist se pulsa la opción de borrar la checklist y se comprueba que los sticks desaparecen. Borrado de todas las Checklists: En la lista de Checklists (o en la actividad de Checklists si es Tablet) se pulsa la opción de borrar las checklists y se comprueba que aparece un diálogo pidiendo confirmación, y en el caso de aceptarlo todos los sticks de todas las listas desaparecen. Además en modo Móvil se comprueba que dentro de una checklist la opción de borrar todas las checklists desaparece. Ajustes - Reinicio de la Aplicación. Se comprueba que al pulsar reiniciar aplicación aparece un diálogo y al aceptar se borran los sticks de todas las listas informando al usuario de ello. 109 7.9 Pruebas de Cambio de Idioma En este apartado se comprueba que al cambiar de idioma el sistema Android la aplicación cambia también de forma autónoma el idioma. Existen 3 versiones, inglés, español y catalán-valenciano. • • • • Idioma del sistema Español: Se comprueba que todos los menús y textos (excepto las Checklists) están en español. Idioma del sistema Catalán-Valenciano: Se comprueba que todos los menús y textos (excepto las Checklists) están en catalán. Idioma del sistema Ingles: Se comprueba que todos los menús y textos (excepto las Checklists) están en inglés. Cualquier otro Idioma: Se comprueba que todos los menús y textos (excepto las Checklists) están en inglés, que es el idioma por defecto. 7.10 Pruebas en distintos Dispositivos Se han realizado pruebas satisfactorias en los siguientes dispositivos: • • • • • • • • • HTC Desire (4.2 Jelly Bean). Custom ROM. Sony Xperia S (4.0 Ice Cream Sandwich).Dispone de Botón Menú. Sony Xperia U (4.0 Ice Cream Sandwich). Dispone de Botón Menú. Sony Xperia T (4.0 Ice Cream Sandwich). Sin botones físicos. LG Optimus Black (4.0 Ice Cream Sandwich). Samsung Galaxy Tab (4.0 Ice Cream Sandwich). Tablet. Asus Transformer (4.0 Ice Cream Sandwich). Tablet. Asus Transformer (4.2 Jelly Bean). Tablet. Custom ROM. Airis Kira 10’’ (4.0 Ice Cream Sandwich). NetBook. Touch Screen. 110 Capı́tulo 8: Resultado Final En este capítulo se presenta el resultado final de la aplicación y sus funcionalidades. Para ello, se dispone de capturas de dispositivos reales y una breve explicación sobre ellas. Se mostrarán agrupadas siguiendo un orden de navegación, mostrando en cada apartado el resultado con Móvil y Tablet. 8.1 Menú Principal – Vista de Categorías En la versión Móvil se compone de dos ventanas distintas. La primera ventana es el Menú Principal. A través de los 4 botones de categorías accedemos al contenido de estas en una nueva ventana (en este caso la categoría Papeles) (ver Figura 40 y Figura 41). Figura 40. Captura Móvil - Menú Principal Figura 41. Captura Móvil - Menú Categorías En ambas pantallas se puede acceder a un botón situado en el Action Bar que lleva directamente a las checklist de emergencia. En la pantalla Menú Categorías se dispone de un Spinner que te permite cambiar entre categorías sin volver al menú principal (ver Figura 43). En la versión Tablet ambas pantallas están integradas en una sola. En un primer instante la parte de la derecha permanece en blanco (con la imagen del logotipo como 111 fondo) hasta que se presiona un botón de la izquierda que muestra las categorías (como se ve en la Figura 42). Figura 42. Captura Tablet - Menú Principal. Estas pantallas también tienen en cuenta el cambio de orientación: Figura 44. Captura Móvil - Menú Principal (Landscape) Figura 43. Captura Móvil - Menú Categoría (Spinner Desplegado) (Portrait) 112 Figura 45. Captura Tablet - Menú Principal (Portrait) Figura 46. Captura Tablet - Menú Ajustes Cambiar Avión (Portrait) En la Figura 44 se puede ver que, al cambiar la orientación los botones se redistribuyen para ser mostrados todos correctamente sin necesidad de hacer scroll. En la Figura 45, en modo Tablet, cambia la proporción de espacio que ocupa cada uno de los 2 layouts. También se aprecia como al mantener pulsado el botón aparece su texto indicando qué significa éste. 113 8.2 Menú Ajustes Al menú Ajustes se accede haciendo clic en el Action Overflow (icono de 3 puntos en el Action Bar) o usando el botón físico del dispositivo si dispone de él (en cuyo caso no se mostrará el Action Overflow). Tiene la misma presentación tanto en móvil como en Tablet. A través de él (Figura 47) se puede cambiar de avión o reiniciar la sesión. En el caso de cambiar de avión se muestra una lista para elegir el deseado (Figura 46). En el caso de Reiniciar sesión muestra un diálogo de confirmación para borrar la sesión actual y empezar un nuevo vuelo (Figura 48). Figura 47. Captura Móvil - Menú Ajustes Figura 48. Captura Móvil - Menú Ajustes Reiniciar Sesión 114 8.3 Actividad Checklists Esta es la única funcionalidad implementada en la aplicación. Las demás solo muestran una imagen estática de demostración. Para acceder a ella hay que acceder a la categoría Papeles y seleccionar Checklists (Figura 41 y Figura 42). La versión Móvil contiene 2 pantallas separadas. Al principio muestra una lista de Checklists (Figura 49), y según la pestaña seleccionada muestra las normales o las de emergencia. Al pulsar sobre una checklist se abre una ventana que muestra los ítems de ésta marcando, si los hay, aquellos que ya han sido completados anteriormente (ver Figura 50). En ésta se nombra la checklist actual para conocimiento del piloto. Figura 49. Captura Móvil - Función Checklists Lista de Checklists. Figura 50. Captura Móvil - Función Checklists Ítems de Checklist. En la versión Tablet, ver Figura 51, ambas vistas se combinan en una sola. Para conocer qué checklist está usando el piloto en ese momento, su nombre queda marcado en la lista de forma permanente (siempre que se encuentre en dicha lista). 115 Figura 51. Captura Tablet - Función Checklists. Finalmente para borrar las listas se dispone de dos opciones en el Action Overflow: Una borra la lista que está abierta en ese momento y la otra borra todas las checklists. Esta última abre un diálogo de confirmación antes de borrarlas (Figura 55). En la versión Móvil se ve la opción de borrar todas las checklists sólo en la lista de checklists (Figura 52), y la opción de borrar la checklist actual solo es visible si se está dentro de una checklist (Figura 53). En la versión Tablet ambas opciones son visibles (ver Figura 54). 116 Figura 52. Captura Móvil - Función Checklists - Reiniciar Checklists Figura 53. Captura Móvil - Función Checklists - Reiniciar Checklist Actual Figura 54. Captura Tablet - Función Checklists Opciones de Borrado Figura 55. Captura Tablet - Función Checklists Confirmación de Borrado 117 Capı́tulo 9: Conclusiones En este último capítulo se exponen las conclusiones técnicas y personales, y se hace una valoración sobre los trabajos futuros que se deben realizar a partir de este proyecto. 9.1 Conclusiones Técnicas Desde un punto de vista técnico y funcional se ha conseguido: • • • • • Diseñar toda una aplicación que suple las necesidades de un piloto de aviación general. Crear la base de dicha aplicación móvil, haciéndola mínimamente funcional. Implementar además, una de las funcionalidades de esta, que es el seguimiento de Checklists. Que ésta aplicación se pueda utilizar en distintos dispositivos con distinto tamaño. Que ésta sea fácil de usar para un piloto mientras vuela. Estos hechos consiguen superar con creces los objetivos del proyecto, por lo que podemos concluir que el trabajo realizado en este es satisfactorio. 9.2 Conclusiones Personales Este proyecto ha sido una experiencia muy enriquecedora. Tras muchas horas de estudio, trabajo y resolución retos nos ha permitido: • • • • Aprender a gestionar proyectos de una forma que la teoría no puede enseñar. Ahondar en la filosofía de diseño de aplicaciones para el sistema Android, que a día de hoy es el sistema más extendido a nivel mundial. Aprender a programar Java y Android de forma ordenada y eficiente. Practicar el modelado de sistemas informáticos con ayuda de estándares como UML que nos ha facilitado la tarea de diseño e implementación. 118 • • Hemos aprendido a ser flexibles con nuestro diseño principal y cambiarlo y mejorarlo sobre la marcha ante un problema no planteado. Hemos puesto en práctica muchos de los conocimientos adquiridos durante la carrera como Programación, Sistemas Operativos, Estructuras de Datos, Programación distribuida o Multimedia, entre muchas otras. A nivel personal, este proyecto ha sentado las bases para una dedicación profesional en este campo que nos brinda la posibilidad de conseguir una remuneración económica sin depender de una empresa en estos tiempos en la que la contratación es tan escasa. 9.3 Trabajo Futuro En el contexto de este proyecto, el trabajo futuro es más que evidente debido a las particularidades de este. Como la implementación sólo se ha llevado a cabo en una pequeña parte de la aplicación se sobreentiende que el trabajo subsiguiente es implementar el resto de la aplicación tal y como se modela y diseña en este proyecto. Aun así, del trabajo realizado se pueden realizar otra serie de trabajos como son: • • • • • • Añadir una guía de usuario dentro de la aplicación que sea interactiva. Añadir nuevos idiomas a la aplicación. Mejorar el rendimiento de la aplicación usando programación con varios hilos. Realizar un análisis para reutilizar funcionalidades y código. Personalizar la aplicación y dotarla de un interfaz más gráfico y atractivo. Crear una aplicación en PC que permita a los pilotos crear Checklists de Avión propias. 119 Bibliografı́a [1] Wikimedia, «Wikimedia - Accidente del vuelo JK5022,» 10 Marzo 2013. [En línea]. Available: http://es.wikipedia.org/wiki/Vuelo_5022_de_Spanair. [2] Wikimedia, «Wikipedia - Android,» 2 Mayo 2013. [En línea]. Available: http://es.wikipedia.org/wiki/Android. [3] A. Lee, "Android Goes Beyond Google," RTC Magazine, p. http://www.rtcmagazine.com/articles/view/102586, 2012. [4] Google Inc., "Android Developers," 2012. [Online]. Available: http://developer.android.com/. [5] Pragmatic Programers, LLC, Hello, Android, Ed. Brunette, 2010. [6] Wikimedia, «Wikipedia - Técnica de revisión y evaluación de programas,» 5 Abril 2013. [En línea]. Available: http://es.wikipedia.org/wiki/PERT. [7] G. Allen, Beginning Android 4, Apress, 2012. [8] S. Komatineni and D. MacLean, Pro Android 4, Apress, 2012. [9] R. C. Palomino, «Desarrollo en Android v1.0,» 2010. [10] E. Avilés, «TechMi,» 14 11 2010. [En línea]. Available: http://techmi.es/blog/cursos/curso-android-avanzado/. [Último acceso: 20 11 2012]. [11] H. @s0ulbuzz, «Android HAL and Graphics,» Watching The v0ld, p. http://soulbuzz.net/?p=175, 2010. [12] D. Felker, Android Application Development for Dummies, Hoboken: Wiley Publishing, Inc., 2011. [13] M. Gargenta, Learning Android, Sebastopol: O'Really, 2011. 120 Anexo A Definiciones y Abreviaturas ADF: Ver NDB. API (Application Programming Interface): Interfaz de programación de aplicaciones es el conjunto de funciones y métodos que ofrece cierta librería para ser utilizado por otro software como una capa de abstracción. Arco: Procedimiento Instrumental por el cual, tomando como centro una estación VOR/DME y determinando una distancia DME, se realiza una trayectoria que dibuja un circulo con radio la distancia DME. Aviación Ligera: Se refiere a todo lo relacionado con aviones de Pistón de menos de 5700kg (Procedimientos, aviones, Licencias, infraestructuras). Avioneta: Aeroplano ligero de menos de 5700kg con motor de combustión interna. Carga y Centrado: Ver Mass & Balance. Checklist: Lista de acciones que deben realizarse para un momento determinado del vuelo. Estas tienen el nombre del momento específico para el cual están diseñadas. Las acciones en ellas escritas buscan la seguridad del vuelo y son de obligatorio seguimiento. En aviación ligera se disponen todas las acciones a realizar, pero en aviones más grandes solo se muestran los ítems que afectan directamente la seguridad del vuelo. Todas las Checklist tienen por ley un mismo formato, en el que se escribe a la izquierda el objeto y a la derecha la acción o valor que se le debe aplicar. Declinación Magnética: Diferencia en grados entre el Norte Magnético y el Norte Geográfico. Deriva: Desvío del rumbo al que apunta el avión respecto a la trayectoria que sigue debido al viento. DME: Equipo dentro de un avión que, si la estación sintonizada tiene tal sistema, es capaz de mostrar la distancia lineal desde el avión a la estación y la velocidad a la que se acerca/aleja de esta. A esa distancia se le llama Distancia DME. Espera: Ver Hold. Estación: Infraestructura fija en el suelo que emite señales electromagnéticas en una frecuencia dada y cuya posición es conocida. 121 Ficha (de aeropuerto): Papel de tamaño A5 que contiene información sobre un aeropuerto. Su función es la de ayudar a los pilotos a seguir los procedimientos, normativas y mostrarles de forma gráfica las rutas y calles de rodaje. Existen principalmente 5 tipos de fichas: Info/Briefing: Muestra datos sobre el aeropuerto y planos de este. VFR (Visual Flight Rules): Fichas que muestran como llegar a un aeropuerto basándose en referencias visuales. Son las más utilizadas en aviación ligera. SID (Standard Instrumental Departure): Son fichas que muestran por donde debe ir un avión para salir del aeropuerto usando radioayudas. STAR (Standard Arrival): Muestran cómo llegar al aeropuerto y colocarse en un punto específico cerca de él con el uso de radioayudas. APP (Approach): Muestran cómo llegar a una pista específica para aterrizar en ella. Su inicio es el punto específico donde te lleva una STAR. Existen distintos subtipos dependiendo de la radioayuda que se use para aterrizar. Flight Plan: Formulario estandarizado que se debe enviar a las autoridades aeronáuticas (a los controladores) para los vuelos que se realicen dentro de un espacio aéreo controlado o para cualquier vuelo que tenga distinto aeropuerto de salida que de llegada. Su cometido es informar a los controladores y equipos de emergencia de los datos de un vuelo en particular (horas de salida y llegada, tipo de avión, ruta, equipamiento, número de ocupantes, piloto al mando…). GS (Ground Speed): Velocidad del avión respecto el suelo. GUI (Graphic User Interface): Ver UI. Hold: Consiste en una serie de circuito ovalado encima de una estación con el fin de que los aviones en vuelo entren en éste y permanezcan en él mientras esperan a ser atendidos/autorizados por los controladores para continuar su vuelo. Existen dos tipos; Estándar (giros a derechas) y No Estándar (giros a izquierdas). HSI (Horizontal Situation Indicator): Instrumento de Navegación por radiobalizas que es capaz de indicar mediante un giróscopo el rumbo actual y además también es capaz de informarte sobre qué radial de la estación VOR que tengas sintonizada te encuentras. IAS (Indicated Airspeed): Velocidad indicada por el anemómetro del avión. Se calcula con la diferencia de presión de impacto respecto la presión estática. IDE (Integrated Development Environment): Un entorno de desarrollo integrado es un programa informático compuesto por una serie de herramientas de programación 122 (editor de código, compilador, depurador, constructor de interfaz gráfica) que funcionan de manera conjunta. Interceptación: Es el procedimiento para cambiarse de radial en un NDB (no da ayuda para seguir encima de un radial como sí lo hace un VOR). IFR (Instrumental Flight Rules): Normativa referente al vuelo usando instrumentos de navegación basado en radiobalizas. Libros (de Checklists): En el contexto de este proyecto son las estructuras de datos que contienen una serie de checklists con sus ítems y que guardan una relación de los ítems completados. Lista de Chequeo: Ver Checklist. Mass & Balance: Cálculo del peso y de la posición del centro de gravedad del avión. Estos deben estar comprendidos entre unos valores (la envolvente de vuelo) para que sea segura su operación. Se suelen calcular mediante tablas y gráficos. METAR: Previsión meteorológica descrita en texto siguiendo un código estandarizado para un aeropuerto. MTOW (Maximum Take-off Weight): Peso máximo al despegue certificado que un avión puede soportar. NDB (Non Directional Beacon): Estación que emite en una frecuencia dada a fin de que un avión equipado con un ADF (Automatic Direcion Finder) pueda establecer la dirección que debe tomar para llegar a esta. Plan de Vuelo: Ver Flight Plan. Punto a Punto: Procedimiento Instrumental por el cual, desde la posición actual del avión respecto a una estación VOR/DME que es conocida, se procede a otro punto respecto a la misma estación (punto determinado por un radial y una distancia DME). QDM: Es el ángulo medido entre el Norte magnético por donde pasa el avión y la línea imaginaria que une a éste con la estación NDB, es decir,el rumbo que tendría que poner el piloto para dirigirse a dicha estación. QDR: Es el ángulo medido en sentido horario entre el Norte Magnético en la estación y la línea imaginaria que une a ésta con el avión. QDR es el ángulo opuesto al QDM. QNH: Presión atmosférica a nivel del mar que se calcula, para un aeropuerto dado, tomando como base la presión local en ese aeropuerto y una corrección de la elevación de este. Radial: Posición relativa de un avión (en grados) respecto a una estación tomando como referencia el Norte Magnético en la estación. Existen 360 radiales, uno por grado. 123 TAS (True Airspeed): Velocidad del avión respecto al aire compensando los errores de posición del instrumento, de compresibilidad y de densidad del aire. TOW (Take-off Weight): Peso del avión al despegue. UI (User Interface): Interfaz de Usuario, serie de vistas, botones textos que contiene una pantalla de un dispositivo con cuya función es facilitar al usuario el uso de una aplicación o programa. URI (Uniform Resource Identifier): Es una cadena de caracteres que identifica inequívocamente un recurso dentro de un sistema (archivo, contacto, cita de calendario…) VFR (Visual Flight Rules): Normativa referente al vuelo usando referencias visuales (carreteras, ríos, pueblos,…) para orientarse y navegar. VOR (VHF Omnidirectional Range): Estación que, mediante diferencia de fase, es capaz de mostrar al piloto en qué radial de esta se encuentra un avión o, seleccionado un radial especifico, hacia donde tiene que virar para montarse sobre él. VOR/DME: Estación que contiene un VOR y un DME que emiten en la misma frecuencia. 124 Anexo B Manual de Usuario Este Anexo contiene el manual de usuario de la aplicación implementada. Contenido La Aplicación ................................................................................................ 126 Menú Principal ............................................................................................ 127 Menú Ajustes................................................................................................ 128 Categorías ..................................................................................................... 129 Checklists ...................................................................................................... 130 Idioma ............................................................................................................ 132 Almacenamiento Externo ........................................................................ 132 Creación de Nuevas Checklists .............................................................. 133 125 La Aplicación Esta aplicación se inicia desde el Launcher de tu dispositivo móvil (Tablet o Smartphone). Para ello hay que tocar el icono de la aplicación. Tras ello se abre la aplicación principal donde podemos destacar: Ilustración 1. Disposición Móvil Ilustración 2. Disposición Tablet La Action Bar Se utiliza para conocer la actividad actual, navegar por la aplicación y acceder a funciones especiales como los ajustes, el botón de Emergencia y el borrado de checklists mediante el Action Overflow, que es el icono con 3 puntos situado a la derecha de la Action Bar. Si quieres subir en el orden jerárquico de la aplicación usa el icono de la aplicación (que contendrá una flecha a la izquierda cuando se pueda subir). Para volver a pantallas anteriores en las que has estado usa el botón Atrás de tu dispositivo. Layout Principal Muestra el apartado Actual. Donde el usuario debe realizar la acción que requiere. Al pulsar sobre algún apartado el layout cambia y muestra la siguiente pantalla (en la versión Móvil). Layout Secundario Solo visible desde una Tablet. Muestra la vista detalle de la acción realizada en el Layout Principal. Se puede interactuar con ella como si de una pantalla individual se tratara. 126 Menú Principal En el menú principal encontramos 4 Botones que nos permiten ir a cada una de las 4 Categorías. En nuestro caso pulsa la categoría Papeles. Ilustración 3. Móvil Pulsa Papeles Ilustración 4. Tablet - Pulsa Papeles También se puede acceder a las checklist de emergencia pulsando el Botón “Checklist de Emergencia”, que es el botón de una checklist y una señal de aviso. Ilustración 5. Móvil Botón Emergencia Ilustración 6. Tablet - Botón Emergencia 127 Finalmente se puede acceder a los ajustes pulsando el Action Overflow y eligiendo Ajustes. Ilustración 7. Móvil Accede a Ajustes Ilustración 8. Tablet - Accede a Ajustes Menú Ajustes En este menú se puede cambiar de avión actual para cargar las listas de uno distinto. Para ello pulsa sobre Cambiar Avión Actual y luego elige uno de la lista: Ilustración 9. Tablet - Pulsa Cambiar Avión Actual. 128 Ilustración 10. Móvil Elige Avión Nuevo. También se puede reiniciar la aplicación para iniciar un nuevo vuelo. Para ello pulsa sobre Reiniciar Sesión y luego confirma la ventana que aparece. Finalmente vuelve al menú Principal pulsando Arriba: Ilustración 11. Móvil Pulsa para Reiniciar la Sesión. Ilustración 12. Tablet - Vuelve al menú Principal pulsando Arriba Categorías Cuando se pulsa un botón se accede a una de las categorías donde se ven todas las funciones disponibles para esa categoría actual. Si es una Tablet esta se muestra en el layout Secundario. Para cambiar de categoría pulsa sobre el nombre de la categoría para abrir una lista desplegable (móvil) o pulsa otro botón en el layout principal (Tablet). Para acceder a las Checklists haz clic en el nombre Checklist. Ilustración 13. Móvil Accede Checklists Ilustración 14. Tablet - Accede a Checklists. 129 Checklists En la funcionalidad checklists se muestran dos pestañas; una Normal y otra Emergencia. Estas muestran una lista de Checklists (según cual) en el layout Principal. Pulsa la pestaña Normal para acceder a las Checklist Normales o pulsa la pestaña Emergencia para las Checklists de Emergencia. Luego selecciona la Checklist deseada: Ilustración 15. Móvil Pulsa la Checklist deseada. Ilustración 16. Tablet - Pulsa la Checklist deseada. Se mostrará en el layout Principal (Móvil) o en el Layout Secundario (Tablet) la lista de ítems de la Checklist elegida con aquellos realizados ya marcados: Ilustración 17. Móvil Lista de Ítems Ilustración 18. Tablet - Lista de Ítems. 130 Para marcar los Ítems tan solo haz clic en cada uno de ellos, pero recuerda que deben realizarse de forma Secuencial, por lo que si no seleccionas el ítem correcto no marcará nada. Ilustración 19. Móvil Marca un Ítem Realizado. Ilustración 20. Tablet - Marca un Ítem Realizado. Cuando la Checklist sea completada el móvil avisará con un mensaje. Borrar Listas Para borrar las marcas de los ítems de una Checklist hay que tener mostrada aquella lista que se desea borrar. Una vez mostrada pulsa el Action Overflow y selecciona Borrar Checklist Actual. La aplicación avisa con un mensaje cuando se haya borrado: Ilustración 21. Móvil Reiniciar Checklist Actual Ilustración 22. Tablet - Reiniciar Checklist Actual y Reiniciar Checklists. 131 Para borrar todos los ítems de todas las Checklists hay que estar en la lista de Checklists (móvil). Para ello solo tienes que pulsar el Action Overflow y seleccionar Reiniciar Checklists. Se mostrará entonces una ventana pidiendo la confirmación. Una vez Confirmes quedarán todas borradas. Ilustración 23- Móvil Reiniciar Checklists. Ilustración 24. Tablet - Confirmación de Reiniciar Checklists. Idioma Para cambiar el idioma cambia el idioma general de Android desde los Ajustes Generales del Sistema. Hay 3 idiomas: Español, Catalán-Valenciano e Inglés (por defecto). Eso quiere decir que cualquier otro idioma seleccionado en el dispositivo hará que se muestre en inglés. Almacenamiento Externo Esta aplicación necesita de un almacenamiento externo (Tarjeta SD o memoria Externa del dispositivo). Si este no está disponible o se encuentra compartido por USB (Almacenamiento Masivo) la aplicación avisa de ello con una ventana y cierra la aplicación. Hasta que no se encuentre disponible no será posible utilizar PilotFMS. 132 Creación de Nuevas Checklists Si deseas, puedes crear una checklists para un avión nuevo siguiendo estas reglas: • • • Coloca el archivo resultante en la carpeta del Almacenamiento Externo: <MemoriaSD>/PilotFMS/Planes. El nombre del archivo debe ser <nombre del avión>.xml El XML debe seguir el siguiente patrón (para que resulte más fácil se puede crear una copia de “Cessna 150L.xml” y modificarla para ahorrar trabajo): Ilustración 25. Prototipo de XML de Avión 133