Gestión de aparcamiento para Iphone integrado con Cloud Computing

! ! UNIVERSIDAD!POLITÉCNICA!DE! VALENCIA! Máster!en!Ingeniería!de!Computadores! ! ! ! ! GESTIÓN(DE(APARCAMIENTO(PARA(IPHONE(INTEGRADA( CON(CLOUD(COMPUTING( ! ! Alumno:!Jesús!Cano!Albir! Director:!Enrique!Hernández!Orallo! ! Departamento!de!Informática!de!Sistema!y!Computadores! ! Fecha:!Julio!2012! ! ! ! ! ! ! 2! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! 3! 1.!INTRODUCCIÓN!.....................................................................................................!5! Motivación!.................................................................................................................................................................!6! Objetivo!.......................................................................................................................................................................!6! Alcance!........................................................................................................................................................................!6! 2.!ESTADO!DEL!ARTE!..................................................................................................!9! Plataformas!móviles!..............................................................................................................................................!9! IPHONE!.....................................................................................................................................................................!15! APPLE!IOS!................................................................................................................................................................!18! OBJECTIVEYC!..........................................................................................................................................................!19! XCODE!.......................................................................................................................................................................!20! GOOGLE!APP!ENGINE!.........................................................................................................................................!22! JDO!(Java!Data!Object)!........................................................................................................................................!23! CLOUD!COMPUTING!............................................................................................................................................!24! MODELO!DE!DATOS!............................................................................................................................................!25! ECLIPSE!....................................................................................................................................................................!26! 3.!ARQUITECTURA!DE!LA!SOLUCIÓN!........................................................................!27! PASOS!PREVIOS!.....................................................................................................................................................!28! ESPECIFICACIONES!FUNCIONALES!.............................................................................................................!29! Aplicación)Iphone).................................................................................................................................................)29! Servidor)JDO)(Cloud)Computing))...................................................................................................................)38! Tecnología!empleada!..........................................................................................................................................!40! 4.!DISEÑO!E!IMPLEMENTACIÓN!DE!LA!APLICACIÓN!..................................................!43! Pestaña!Home!........................................................................................................................................................!45! Pestaña!Ubicación!................................................................................................................................................!48! Pestaña!Huecos!Libres!.......................................................................................................................................!49! 5.!DISEÑO!E!IMPLEMENTACIÓN!DEL!SERVIDOR!........................................................!53! Clase!Hueco!y!HuecoL!.........................................................................................................................................!53! Clase!PMF!.................................................................................................................................................................!54! Servlets!para!iniciar!un!Hueco!........................................................................................................................!55! Servlets!para!eliminar!un!hueco!....................................................................................................................!56! Servlets!de!listado!de!contenido!....................................................................................................................!57! 6.!PRUEBAS!.............................................................................................................!59! 7.!CONCLUSIONES!....................................................................................................!61! 8.!TRABAJO!FUTURO¿?!............................................................................................!65! 9.!BIBLIOGRAFÍA!......................................................................................................!67! ! ! ! ! ! ! 4! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! 5! ! (1.(INTRODUCCIÓN( ! El objetivo perseguido en la realización de la presente tesis de máster, ha sido la realización de una aplicación móvil destinada a realizar estacionamientos de vehículos de una forma más eficiente y de un modo colaborativo, orientado a aplicar dicha aplicación de un modo práctico. El propósito de la aplicación , de un modo resumido, es almacenar información sobre posibles emplazamientos para estacionar nuestro vehículo (basándonos en la coordenadas de los individuos en un momento determinado) con la finalidad de que el conductor disponga de una sencilla herramienta que le pueda facilitar el estacionamiento del mismo. De este modo, un usuario podrá acceder a las facilidades aportadas por la aplicación mediante las coordenadas que proporcione su localizador GPS integrado en el dispositivo móvil. Revisando posibles opciones e implementaciones para poder llevar a cabo, se observa que en la actualidad los problemas de estacionamiento son habituales en la ciudades, por lo que hemos optado por destinar las capacidades y herramientas que proporciona el geoposicionamiento de los dispositivos móviles, así como, las ventajas que nos ofrecen los servicios de “Cloud Computing” para poder diseñar una aplicación que facilite y agilice la tarea de estacionamiento de vehículos. En concreto, el dispositivo escogido para la realización del mencionado proyecto ha sido el iPhone de Apple y la tecnología escogida para llevar a cabo las tareas de “Cloud Computing” son las ofrecidas por Google, mediante su servicio Google App Engine. Una vez hemos puesto en situación en lo referente al contenido de la memoria, podemos pasar a la descripción más detallada de la misma y relatar de un modo más clarividente el aspecto y funcionamiento de las herramientas empleadas. ! 6! MOTIVACIÓN! Los motivos que me han impulsado a decantarme por este tipo de tecnologías para el desarrollo de mi aplicación son por un lado la posibilidad de poder desarrollar para una plataforma móvil, en concreto iPhone debido al auge y popularidad de la que goza en la actualidad, así como aprender su lenguaje y metodología, totalmente desconocidas para mi, para poder ampliar mis conocimientos y por otro lado la posibilidad de poder combinar dicha aplicación con los servicios de “Cloud Computing” que también están gozando de una gran popularidad ya que proporcionan gran flexibilidad al desarrollador para poder llevar a cabo sus tareas. OBJETIVO! El objetivo que persigo en la realización de este proyecto es aprender sobre un nuevo e interesante campo de la programación para dispositivos móviles (dispositivos iPhone y compatibles en concreto) y basándome en dicho aprendizaje, realizar una aplicación en la que pueda extrapolar los conocimientos adquiridos combinados con la utilización de Google App Engine para poder hacer que la aplicación sea más flexible y móvil haciendo que la información de la que queremos disponer se obtenga en tiempo real, algo parecido como lo que ocurre en otro tipo de plataformas muy populares como pueden ser Facebook o Twitter. Todo esto además, se pretende llevar a cabo con un diseño que sea sencillo de cara al usuario para que puede utilizar la aplicación sin acciones complejas, de una forma intuitiva, pues como usuario habitual de la plataforma móvil que se ha escogido, mi preferencia a la hora de poder instalar una aplicación en mi dispositivo, es que la misma, sea sencilla, fácil e intuitiva. ALCANCE! El proyecto pretende realizar una aplicación destinada a dispositivos iPhone y compatibles (iPad, iPod Touch) destinada a aquellos usuarios que dispongan de dicha tecnología (puesto en la parte referente a Google App Engine es totalmente transparente al usuario) con el fin de facilitar en la medida de lo posible las tareas de estacionamiento de vehículos, pues la misma se ha convertido en una ardua tarea en emplazamientos de gran volumen de tráfico. De este modo se presenta información ! 7! (calle y ciudad) de un modo colaborativo sobre ciertos lugares en los que se encuentra un vehículo estacionado y que previamente ha utilizada dicha aplicación para poder notificar la reserva/estacionamiento del vehículo en la una posición determinada. Del mismo modo ese mismo usuario cuando fuese a desalojar su plaza de estacionamiento, puede llevar a cabo la liberación/notificación de dicha plaza para que aparezca en un listado y que otro usuario potencial de la aplicación pueda observar los lugares más cercanos a él en los que podrías estacionar su vehículo y poder realizar la pertinente reserva/estacionamiento de su vehículo. La aplicación en sí se compone de diferentes tareas que se llevan a cabo en cada una de las tres diferentes sub-vistas que la componen:  Por un lado tendríamos la vista Home. Esta sería la vista principal de la aplicación y la cual se ejecuta en el momento que la aplicación arranca desde el dispositivo. En dicha vista podríamos realizar la reserva de la posición donde se va a estacionar, en el caso de que no se encontrase en la lista de las libres previamente establecidas, mediante un botón destinado a tales efectos. Mientras que por otro lado podríamos realizar la liberación de ese hueco reservado, la cual, nos llevará a otra vista en la que podremos observa un listado de todos los huecos de aparcamiento que se encuentran ocupados en la actualidad. Para llevar a cabo la liberación simplemente bastaría con editar la tabla y borrar la celda correspondiente a nuestro hueco de estacionamiento y la aplicación se encargará del resto.  La segunda vista, está denominada con el nombre Ubicación. En la misma y tal como se puede intuir por su nombre, aparece una vista de un mapa, el cual nos muestra la posición actual en la cual nos encontramos para tener una visión general de la zona por la que nos estamos moviendo.  Por ultimo tenemos la vista Resumen, la cual nos ofrece un listado de las posibles plazas de estacionamiento que podríamos ocupar y que se encuentran libres, previa liberación de los usuarios en la vista Home mencionada anteriormente. El mecanismos para llevar a cabo la reserva del lugar de estacionamiento es análoga a la que utilizábamos en la vista Home, por lo que solo tendremos que editar la vista de tabla que se nos presenta, eliminando la celda de la misma correspondiente al lugar que queremos reservar y automáticamente, éste desaparecerá de listado para aparecer en el listado en el que se muestran los huecos que se encuentran ocupados en la actualidad. ! 8! De este modo lo que nos permite esta aplicación es poder agilizar las tareas de estacionamiento de vehículos así y por consiguiente poder mejorar las condiciones de circulación de las calles por las que transitamos. Esta tarea resulta bastante costosa y desesperante en ocasiones, por lo que el carácter colaborativo que tiene esta aplicación, hace que dicha búsqueda se lleve a cabo de una forma más sencilla y directa. También ofrece ventajas en cuanto al ahorro de combustible pues con el uso de esta aplicación conseguimos ir de un modo directo al lugar donde vamos a estacionar el vehículo sin necesidad de tener que estar dando vueltas constantes para poder localizar el lugar. Y aunando los dos puntos de vista anteriores, podemos también decir que el uso de la aplicación incorpora ventajas ecológicas, puesto que cuanto menos tiempo estemos circulando con nuestro vehículo, menos gases estaremos emitiendo a la atmósfera ! 9! 2.(ESTADO(DEL(ARTE( Es aquí es donde procederemos a realizar un pequeño repaso en cuanto a las tecnologías destinadas a la realización de la tarea que nos ocupa para tener una idea general del estado actual respecto a lo que podemos encontrar en el mercado en la actualidad. Hay que tener en cuenta a la hora de realización del proyecto, las características propias de cada uno de los productos disponibles en el mercado para observar cual es el que mejor se adapta a nuestras características y necesidades. Más concretamente nos estamos refiriendo al hecho de que al centrar las posibilidades y habilidades de nuestra aplicación a la aplicación de términos de posicionamiento con un fin determinado, deberemos escoger un dispositivo o tecnología que presente características fiables a tales efectos, para que el funcionamiento de la misma sea lo más preciso y fidedigno posible. PLATAFORMAS!MÓVILES! Como decíamos anteriormente, existen diversas plataformas móviles sobre las que desarrollar nuestro proyecto, decantándose por uno por otro dependiendo de las circunstancias citadas. Principalmente podemos distinguir, de entre todas las posibilidades, cuatro grandes plataformas que copan el panorama móvil actual: Se trata de un sistema operativo móvil desarrollado por Microsoft y que fue lanzado en 2010, concebido para reemplazar la plataforma “Windows mobile”. A diferencia de su antecesor está destinado al sector de uso cotidiano y generalista, no con fines comerciales y empresariales como su antecesor. La compañía con sede en Redmon, decidió dar un vuelco a la tecnología móvil que venía desarrollando hasta entonces y esa revolución les llevó a desarrollar un nuevo sistema operativo móvil objeto de nuestra descripción. Fruto de esa revolución y cambio de rumbo por parte de Microsoft, obtenemos un sistema operativo que presenta una nueva interfaz (“Metro”) que enfatiza el contenido y ! 16! Si bien decíamos que el espacio suponía una limitación a la hora de poder presentar nuestras aplicaciones sobre la pantalla del dispositivo, podemos utilizar herramientas propias de diseño que nos lleven a poder realizar aplicaciones tan complejas como puede resultar un software de escritorio. Las opciones a la hora de mostrar gráficos pueden incluir complejas visualizaciones animadas en 2D y 3D gracias a la implementación OpenGL ES (estándar industrial orientado a la definición y manipulación de imágenes, ampliamente utilizado en la creación de juegos, principalmente) disponible en todos los modelos de iPhone y que son mejorados mediante un chipset 3D actualizado. 2)(Limitaciones(en(los(recursos(de(aplicaciones( Apple se ha esforzado mucho para hacer que el iPhone responda correctamente sin importar lo que estamos haciendo. Sin embargo, desafortunadamente, esto ha contribuido a una de las limitaciones más grandes en la plataforma: sólo puede ejecutarse al mismo tiempo una aplicación de terceros. Esto significa que el programa debe proporcionar las funciones necesarios para el usuario sin que éste tenga que acceder a otras aplicaciones. Del mismo modo, también quiere decir que la aplicación debe permanecer activa para comunicarse con el usuario. ! 17! Otra de las limitaciones que debemos tener el cuenta a la hora de realizar nuestros desarrollos para esta plataforma es la limitación de memoria RAM, pues sólo disponemos de de 512 MB en el caso de los dispositivos iPhone 4/4s y iPods de nueva generación y de 256 MB en el caso de iPhone 3Gs y 128 en el 3G. Por lo que esta observación deberá ser tenida a la hora del desarrollo para libera aquellos recursos de los cuales no se vaya a volver a hacer uso, para que otros ocupen su lugar en memoria y tener un óptimo rendimiento. 3)(Conectividad( Se trata precisamente de una de las áreas en las que este dispositivo brilla, debido a su capacidad para mantenerse conectado permanentemente a través de la conexión por medio de un proveedor móvil, viéndose esta capacidad mejorada en la medida que van apareciendo en el mercado nuevas versiones del dispositivo. Además, este acceso a Internet se ve complementado mediante el acceso a las tecnologías Wifi (puede ofrecer velocidades similares a las que podríamos obtener en nuestro propio ordenador) y Bluetooth (usado para tener conectados varios dispositivos a nuestro terminal). Lógicamente durante la etapa de desarrollo, puede hacerse uso de este tipo de tecnologías para mantener actualizada nuestra aplicación en el caso de que así lo requiriese. 4)(Entrada(y(retroalimentación( El iPhone es especialmente brillante cuando hablamos de este tipo de mecanismos, así como en las capacidades de las que disponemos a la hora de trabajar con ellos. Lo que nos permite este tipo de técnicas es poder recibir datos de entrada desde la pantalla multi-táctil, captar el movimiento e inclinación por medio del acelerómetro o determinar la posición actual por medio del GPS (precisamente esta es la técnica que tendremos en cuanta a la hora de desarrollar nuestra aplicación). El iPhone también es compatible con la captura de imágenes y video directamente desde nuestras aplicaciones, abriendo así un amplio abanico de posibilidades para poder interactuar con la aplicación. Por último cabe mencionar que, para cada acción que el usuario realice en la aplicación, podemos proporcionar retroalimentación, refiriéndonos con esto a que podemos responder a cualquier acción que se realice sobre nuestra aplicación con elementos disponible dentro del propio dispositivo, como bien pueden ser vibraciones, sonidos, alertas, etc. ! 18! APPLE!IOS! Cuando nos referimos a este concepto, estamos haciendo referencia al sistema operativo propio de los dispositivos Apple. Se trata de un sistema operativo basado en una variante del Mach Kernel propio de Mac OS X. Para realizar una descripción más comprensiva y que pueda resultar clarividente vamos a basarnos en el la siguiente figura, la cual constituye el diagrama correspondiente a la arquitectura del sistema. - Core OS Layer: Se trata de la capa que ocupa el lugar más bajo de la pila que compone el sistema operativo y como tal, se asienta directamente sobre el hardware del dispositivo. Esta capa es la encargada de proveer una variedad de servicios incluyendo los relacionados con el nivel de red, acceso a accesorios externos y los usuales servicios de sistema operativo como la administración de memoria o el manejo del sistema de ficheros e hilos de ejecución. - Core Services Layer: Esta capa contiene los servicios fundamentales del sistema, los cuales, son usados por todas las aplicaciones. Incluso si no lo usamos directamente, puede que algunas partes del sistema estén construidas en base a esta capa. ! 19! - Media Services Layer: Es la encargada de gestionar todo lo relacionado con las tecnologías gráfica, de audio y video orientadas a la existencia de una mejor experiencia multimedia disponible en el dispositivo. - Cocoa Touch Layer: La última capa de la arquitectura contiene los framework clave para poder construir aplicaciones en el sistema operativo iOS. De este modo define la estructura básica de aplicación y da soporte a tecnologías clave como son la multitarea, la entrada basada en pulsaciones, las notificaciones push (básicamente se refiere a notificaciones que indican que existe nueva información disponible) y otras tantas tecnologías de alto nivel. OBJECTIVEYC! Se trata de lenguaje de programación utilizado para poder realizar aplicaciones que han de estar disponibles para dispositivos Apple y que fue creado hallá por 1980. Objective-C es un lenguaje de programación simple diseñado para habilitar el desarrollo de una sofisticada programación orientada a objetos. Este es definido como un pequeño pero potente conjunto de extensiones del lenguaje estándar ANSI C, por lo que constituye un enfoque de programación orientada a objetos completa al lenguaje C, haciéndolo de una forma sencilla. Como ejemplo de lo sencillo que puede llegar a ser este lenguaje podemos poner un ejemplo y observar que se puede deducir de forma intuitiva y sin la necesidad de soluciones complejas, cual será el resultado de la ejecución de dicho fragmento de código: NSString *string; [string isEsqualToString:@”Hola mundo” ];! Como podemos observar no parece complicado deducir cuál será el resultado almacenado en la variable string. Se declara una variable de tipo String que en este caso recibe el otro nombre concreto y a se le asigna un valor en concreto mediante un método que a juzgar por su nombre parece bastante ilustrativo de la acción que llevará a cabo. ! 20! XCODE! Se trata del IDE, o entorno de integrado de desarrollo, que gestiona los recursos de nuestras aplicaciones y nos permite editar el código que enlaza entre si las distintas piezas. La herramienta aúna e integra todo lo necesario para el desarrollo de nuestras aplicaciones, permitiéndonos en una única herramienta disponer de todos los elementos y accesorios necesarios para la realización de la misma (desarrollo, depuración, diseño,…). Además incorpora herramientas que nos permiten obtener a tiempo real una visión de cuan correctamente se esta llevando a cabo nuestro proyecto, debido a que utiliza una herramienta denominada “live issues” que nos va informando mediante la aparición de un globo informativo, de la posible presencia de errores o advertencias en las sentencias escritas para desarrollar nuestro código. Una vez tenemos una visión un poco general de lo que representa Xcode, podemos pasar a detallar los componentes de los que dispone, para aunar en una sola herramienta todos los medios necesarios para el desarrollo. COMPILADOR(APPLE(LLVM((APPLE(LLVM(COMPILER)( ( El compilador incorporado en la herramienta va más allá del simple hecho de compilar nuestra aplicación. Básicamente se basa en la idea de utilizar el mismo compilador que utiliza Xcode para archivos C/C++ se utiliza también para compilar archivos en lenguaje Objective-C. Se encuentra continuamente evaluando las expresiones introducidas durante el desarrollo mediante la citada herramienta Live issues y partir de las mismas propone un abanico de posibles soluciones en tiempo real, con la finalidad de poder eliminar el fallo detectado, pudiendo elegir el usuario entre la mas adecuada al comportamiento deseado en el código. Como muestra de esta explicación, podemos observar una imagen que nos indica a las claras lo que se pretende explicar. ! 21! INSTRUMENTS(FOR(PERFORMANCE(AND(BEHAVIOR(ANALYSIS( Lo que se pretende a la hora de desarrollar una aplicación es que la experiencia de usuario sea buena y no simplemente se refiere a cuestiones de diseño y a un funcionamiento intuitivo. Las aplicaciones deben responder de un modo óptimo para mejorar todavía mas si cabe lo conseguido en la fase de diseño y eso es precisamente lo mas importante. Es por esto que Xcode incorpora una herramienta de desarrollo denominada Instruments que se encarga de localizar los cuellos de botella que pueden darse en el funcionamiento de nuestra aplicación. Para ello, recolecta datos tales como disco, memoria y CPU con nuestro dispositivo conectado, mostrándonos de manera gráfica los resultados, hecho que nos lleva a poder identificar y localizar de un modo rápido la causa de los problemas de nuestra aplicación para poder solventarlos. SIMULADOR(IOS( Es el encargado de ejecutar nuestra aplicación del mismo modos de que se produciría en un dispositivo real. Debido a que es rápido de ejecutar y de depurar, esta herramienta se convierte en un test perfecto para nuestra aplicación y así poder hacer una estimación sobre el correcto comportamiento que tiene nuestra aplicación frente a los diferentes casos de prueba a los que puede verse sometida. MODELSVIEWSCONTROLLER( Finalmente para encajar todas las piezas de puzle descrito y que componen el modo de desarrollo llevado a cabo para realizar nuestras aplicaciones, debemos mencionar en el patrón de diseño que han de seguir las mismas, ajustándose al patrón establecido por la compañía tanto en iPhone como en Macintosh, y este no es otro que MVC (ModelView-Controller). Se trata de un modo de mantener organizados nuestros proyectos de aplicaciones, para que podamos ampliarlos y actualizarlos en el futuro, estableciendo una separación clara entre los componentes críticos de nuestra aplicación, definido en tres partes: ! 22! - Un modelo proporciona los datos internos y los métodos que ofrecen información al resto de la aplicación (el modelo no define la apariencia o el comportamiento de la aplicación. - Una o más vistas construyen la interfaz de usuario. - Un controlador suele estar vinculado con una vista. El controlador es responsable de recibir la entrada del usuario y reaccionar en consecuencia. Como muestra explicativa del funcionamiento del modelo, se expone a continuación una imagen ilustrativa que ayuda a extrapolar los conceptos teóricos del modelo a una compresión visual de las acciones que se llevan a cabo en el mismo. GOOGLE!APP!ENGINE! Se trata de un servicio que nos permite poder ejecutar nuestras aplicaciones en la propia infraestructura de Google. Las aplicaciones App Engine son fáciles de crear, de mantener y de ampliar al ir aumentando el tráfico y las necesidades de almacenamiento de datos. Con App Engine no es necesario utilizar ningún servidor: simplemente basta con subir la aplicación para que los usuarios puedan empezar a utilizarla. Se puede dotar a nuestra aplicación de su propio dominio (http://www.example.com/) o bien utilizar el que la plataforma nos ofrece por defecto appspot.com. Se puede utilizar este servicio de forma totalmente gratuita siempre y cuando no supere los 500 MB de espacio de almacenamiento y pueden utilizar la suficiente CPU y ancho ! 23! de banda como para permitir un servicio eficaz de alrededor de cinco millones de visitas a la página al mes. Los servicios de los que podemos disponer a la hora de poder implementar para esta tecnología son tales como: - servidor web dinámico, totalmente compatible con las tecnologías web más comunes. - almacenamiento permanente con funciones de consulta, clasificación y transacciones. - escalado automático y distribución de carga. - API para autenticar usuarios y enviar correo electrónico a través de Google Accounts. - un completo entorno de desarrollo local que simula Google App Engine en tu equipo. - colas de tareas que realizan trabajos fuera del ámbito de una solicitud web. - tareas programadas para activar eventos en momentos determinados y en intervalos regulares. Sobre todos los servicios relatados podemos basar el funcionamiento de nuestra aplicación escogiendo aquel que se adapte mejor a las prestaciones que queramos ofrecer al usuario. Sin duda, tanto la amplia variedad de posibilidades y servicios ofrecidos así como la gratuidad, hacen de este servicio una opción bastante atractiva a la hora de poder desarrollar nuestras aplicaciones sin la necesidad de tener que montar un servidor propio e independiente. JDO!(JAVA!DATA!OBJECT)! Se trata de una especificación de almacenamiento de objetos en Java, la cual, no se limita al almacenamiento de objetos en bases de datos relacionales únicamente, pudiendo también utilizarse contras ficheros XML, documentos de OpenOffice, objetos JSON, etc. Esta versatilidad facilita la integración entre JDO y el datastore de Google App Engine, el cual, no utiliza un modelo relacional por debajo. Lo que si utiliza JDO por debajo es el API de nivel inferior y como muestra de ello la siguiente figura pretende ilustrar esta afirmación. ! 24! El API JDO es uno de los APIs más fáciles de aprender de toda la tecnología existente actualmente para la persistencia de objetos estandarizada. Una razón de la simplicidad de JDO es que permite trabajar con objetos normales de Java (POJOs plain old Java objects) en lugar de con APIs propietarios. Además permite que los desarrolladores puedan centrarse más en qué quieren buscar, almacenar, eliminar, modificar, etc. que en el cómo hacerlo. El poder centrarnos en el qué queremos hacer en lugar del cómo, nos hace disponer de un grado de abstracción alto, claramente mayor que el que tendríamos si tuviésemos que desarrollar nuestra aplicación con el API de nivel inferior, sin embargo, perderemos el disponer de un control absoluto sobre lo que hacemos. JDO ha recibido ataques por muchas razones, entre las que se incluyen: el modelo de mejora de código debería reemplazarse por un modelo de persistencia transparente; los vendedores podrían perder sus bloqueos propietarios; JDO se solapa demasiado con EJB y CMP. A pesar de estos puntos de resistencia, muchos expertos están aconsejando JDO como una enorme mejora sobre las tendencias actuales de tecnologías objeto-adatos y datos-a-objeto. CLOUD!COMPUTING! Con este término nos estamos refiriendo a un paradigma que permite ofrecer servicios a través de internet. Toma su nombre del concepto de internet como nube que alberga ! 25! todo y se basa en la capacidad de que la computación que un sistema informático puede llevar a cabo sea ofrecida como un servicio. Esto quiere decir que se nos ofrece la posibilidad de que nuestro sistemas como tal (hardware y software) que debería ser mantenido y ubicado por nosotros mismos, pueda ser albergado en la “nube” con la única necesidad de dotar al mismo de las capacidades que nosotros queramos otorgarle. Como se puede deducir de la explicación anterior, esto conlleva un ahorro bastante considerable pues utilizando este tipo de medios podemos disminuir costes de infraestructura, hardware, software, mantenimiento, etc. “Cloud Computing” puede ofrecer mecanismos de almacenamiento en red (dropbox), aplicaciones genéricas en la red, servicios web o bien aplicaciones propias. El inconveniente que presentan es precisamente que depende del proveedor que es el que nos ofrece la posibilidad de utilizarlas así como de posibles cortes de red que se puedan producir. Este servicio está compuesto de los siguientes componenetes: - Clientes (teléfonos móviles, navegadores, ordenadores con aplicación cliente,…) - DataCenter (colección de servidores, normalmente virtualizados, que pueden estar distribuidos en diversas ubicaciones) o Virtualización (todo el hardware es emulado) o ParaVirtualización (no todo el hardware es emulado, lo que permite un mejor escalado de las aplicaciones) - Internet El objetivo que persiguen los servicios ofrecidos por esta tecnología es por un lado, proporcionar un fácil acceso para aquellas empresas pequeñas que no dispongan de medios necesarios para poder llevar a cabo la tarea por su cuenta, ofrecer una alta escalabilidad y ofrecer independencia del dispositivo que se emplee para poder acceder a nuestro servicio. MODELO!DE!DATOS! ! Enlazando con el apartado anterior podemos indicar que existen diferentes posibilidades en cuanto al modelo de datos a utilizar se refiere y como en el resto de aspectos, a la hora de optar por uno u otro dependerá de las características de las que queramos dotar a nuestra aplicación. ! 32! podrá configurar. Como muestra de lo expuesto en el párrafo anterior, podemos apreciar en las siguientes imágenes: Si pulsamos sobre cualquiera de los objetos de la tabla, cada uno de los cuales hace referencia a “huecos” que en este momento están siendo utilizados, iremos a otra nueva vista en la que nos aparece un mapa indicando exactamente la ubicación de ese “hueco”. ! 33! Como podemos observar en la figura anterior, el punto azul en el mapa representa nuestra ubicación actual, mientras que la anotación de color rojo representa la ubicación del hueco ocupado a liberar en cuestión. Si pulsamos sobre el icono rojo de la anotación nos aparecerá un cuadro de texto indicando a distancia a la que nos encontramos de dicho hueco. Por último el botón edit nos permite poder eliminar cualquier dato de la tabla. Esta última opción no se basa simplemente en eliminar una fila de la tabla, si no que se centra en las consecuencias que ellos conlleva, es decir, si nosotros eliminamos una fila de dicha tabla, lo que estamos haciendo en cierto modo, es notificando el abandono del hueco de estacionamiento en el cuál nos encontramos y por lo tanto “liberando” nuestro hueco. Por lo tanto cuando eliminamos una fila de esta tabla lo que estamos haciendo es liberar nuestra posición de estacionamiento y generando un nuevo “hueco” libre que se notificará en la pestaña resumen que comentaremos posteriormente. ! 34! La siguiente pestaña que encontramos es la denominada como Ubicación. Esta pestaña es la encargada de indicarnos en el mapa la posición actual sobre la que nos encontramos. En la figura observamos un punto azul que representa la ubicación actual en la que nos encontramos. La funcionalidad del mapa incluye la opción de poder hacer zoom sobre el mismo o alejar la imagen y poder desplazarnos por el mismo para poder observar cualquier cosa que pueda resultar de nuestro interés. ! 35! Finalmente, la tercera y ultima pestaña de la que consta la aplicación, recibe el nombre de Resumen y su cometido es de listarnos en una tabla los “huecos” libres que se encuentran disponibles en ese momento determinado, para poder realizar la reserva de los mismos. La procedencia de estos “huecos” es, como decíamos más arriba, aquellos huecos disponibles en la tabla que se encuentra en la pestaña Home y de los cuales hemos procedido a borrarlos de la lista y por tanto liberándolos. Los datos mostrados en dicha tabla, corresponden a todos los huecos existentes en la base de datos que se encuentran a una distancia inferior a seis kilómetro de nuestra posición actual, con el propósito de evitar listar ciertos huecos que por su lejanía, nos resulten inservibles en ese momento. Automáticamente a la eliminación de ese objeto de la tabla, se realiza una llamada al servidor con los datos de ese “hueco” liberado para que se proceda a la creación de otro “hueco” de carácter libre para poder realizar la conveniente notificación de que dicho espacio queda libre para el estacionamiento. Al igual que ocurría en la pestaña Home, se ha incluido la posibilidad de establecer un filtro respecto a los huecos existentes en el servidor para poder dotar a la información que se muestra en la aplicación de una mayor utilidad y así poder excluir aquellos huecos que debido a la lejanía que existe de los mismos a nuestra posición actual no nos resultan de mucha utilidad. De este modo la apariencia que tendría nuestra aplicación en el caso de que esta circunstancia se diese, puede apreciarse en la figura siguiente, en la que del mismo ! 36! modo que en la primera de las pestañas, hemos establecido el límite para poder mostrar un hueco en 6 km. Del mismo modo que procedíamos anteriormente podemos realizar un refresco de los datos disponibles en la tabla, mediante el botón reload de la parte superior izquierda y podemos eliminar un elemento de la lista mediante el botón Edit, situado en la parte superior derecha de nuestra pantalla del dispositivo. Tal y como sucedía en la reserva de espacios de estacionamientos, la eliminación de uno de los elementos de la lista supone que el usuario ha localizado esta posición y pretende estacionar su vehículo en el mismo, por lo que procede a notificar que esa posición ya no estará libre y por lo tanto por eso procede a la eliminación de la lista. Dicha eliminación conlleva una llamada al servidor con los datos del “hueco” eliminado para crear un objeto “hueco” en el apartado de huecos ocupados. ! 37! Por último, otra funcionalidad que incorpora la aplicación es poder visualizar en el mapa el lugar concreto del “hueco” listado. Para ello, tan solo debemos pulsar sobre cualquiera de los objetos de la tabla, para poder acceder a la vista en el mapa con la posición concreta del hueco. En el mapa, aparecerá una anotación de color rojo que nos indica precisamente la posición concreta. ! 38! Se puede observar el punto azul en el mapa que representa nuestra ubicación y el pin de color rojo que representa la ubicación del hueco libre que disponemos para aparcar. Así si pinchamos sobre la anotación del hueco nos aparecería un cuadro de texto indicativo, con los metros o kilómetros a los que se encuentra dicho hueco respecto a nosotros. SERVIDOR!JDO!(CLOUD!COMPUTING)! ! Al otro lado de la aplicación estaría el servidor implementado en lenguaje Java, utilizando los principios de la computación en la nube y cuyo aspecto pasamos también a detallar para que lector de la presente memoria tenga conciencia de cómo está estructurado el funcionamiento de la aplicación tanto desde la parte iPhone (descrita arriba) y la parte servidora con la que interactúa. Para ello presentamos una imagen global de la estructura del servidor de la aplicación. ! ! Objeto Hueco (Libre y ocupado) (1) Generador de persistencia (2) Conjunto de Servlets (3) Nomenclatura de los servlets (4) ! 39! Una vez vista la apariencia principal de nuestro servidor, estamos en disposición de ir detallando un poco más cada una de las partes identificadas en el mismo y que a efectos de funcionamiento para nuestra aplicación, son las más relevantes. 1) En primero lugar tenemos las dos clases que establecen los objetos Java con los que se va a trabajar en la manipulación de datos por parte del servidor. Así pues existe tanto un objeto para “huecos libres” (HuecoL.java), como para “huecos ocupados”(Hueco.java) y cuyo aspecto es similar al de cualquier objeto que hayamos creado en Java, con sus constructores, modificadores, etc. 2) El segundo bloque corresponde con la clase PMF.java. Se trata del API de Java que nos permitirá que podamos almacenar nuestros objetos de forma persistente y que podamos utilizar los mismos a modo de base de datos, pudiendo hacer consultas sobre la misma (consultas simples) y volcado de datos. Es por tanto en esta clase donde establecemos los parámetros necesarios para poder utilizar este servicio. 3) La tercera parte de las establecidas, es la más extensa y la que engloba todo el grupo de servlets que llevarán a cabo las tareas asignadas al servidor. En el interior de cada uno de los servlets, cabe mencionar, que es necesario la utilización del elemento de persistencia previamente mencionado para que las operaciones que llevemos a cabo con los objetos, puedan ser almacenadas, eliminadas o modificadas y los cambios se vean reflejados en el servidor. El resto de la lógica que contiene cada uno de ellos viene determinada por la funcionalidad del mismo. Así como vemos en la nomenclatura asignada a cada uno, resulta sencillo imaginar que es exactamente lo que hará cada uno de los servlets. 4) Por último y no menos importante cabe mencionar el archivo web.xml. Es en este archivo donde especificaremos cual será la nomenclatura necesaria para poder llamar a los diferentes servlets que componen nuestro servidor para que realicen la tarea que deseamos. Por ello, en el interior del archivo debemos especificar el nombre del servlet en cuestión y asignarle la extensión que tendrá dentro de la url del mismo. Como muestra, se ofrece una imagen que permite ver a las claras a lo que nos estamos refiriendo. ! 40! Como se puede observar, escribiendo el lenguaje XML establecemos la estructura servlet mediante la expresión <servlet></servlet> en la que se indica la ruta completa de servlet en cuestión y posteriormente se establece su mapeo para poder utilizarlo a través de una URL, mediante las etiquetas <servletmapping></servlet-mapping>. Este proceso habría que realizarlo para todos y cada uno de los servlets que queremos incluir en el funcionamiento de nuestra aplicación. Aunque no lo hemos mencionado porque en el contexto de nuestra aplicación no se utiliza y no resulta útil, cabe mencionar la existencia de un archivo con extensión “.jsp” que es el encargado de realizar las funciones de mostrar el aspecto que tendrá el servidor si se le invoca desde un navegar o si queremos realizar alguna función en el mismo a través de la web. En este caso no resulta relevante porque nuestra aplicación en ningún momento ofrece una vista web del servidor y simplemente se comunica con él para poder realizar su cometido. En el caso de que si que lo hiciese, sería necesario configurar este archivo para poder ofrecer una vista depurada de nuestro servidor web. TECNOLOGÍA!EMPLEADA! Una vez hemos explicado la arquitectura de la solución propuesta, así como las funcionalidades de la misma y el modo de poder utilizarlas, es conveniente que expliquemos mas detalladamente las tecnologías utilizadas para llevarlas a cabo. ! 41! XML( Esta tecnología hace referencia al modelo de datos utilizado para llevar a cabo las comunicaciones entre el servidor y nuestra aplicación iPhone. Los datos intercambiados con el mismo en dicho lenguaje se limitan principalmente a transmitir las diferentes coordenadas (longitud, latitud) de los huecos de estacionamiento libres u ocupados residentes en el servidor así como la fecha de creación de los mismos y una breve descripción de los mismos, basada en indicar el número de identificador del “hueco” en el servidor. Lo que se pretende es tener la información en el tiempo menor posible, debido a que la finalidad de la aplicación es que el usuario disponga en su vehículo de una forma rápida, información del lugar donde podría estacionarlo, es por ello, que hemos elegido este tipo de intercambio de datos. Del mismo modo, la información hubiera podido ser almacenada de forma local en el dispositivo, pero con este mecanismo, tan solo dispondríamos de información propia al dispositivo y lo que se pretende es disponer de información que los usuarios de la aplicación hayan facilitado con el uso de la misma sobre los lugares de estacionamiento de los vehículos y posibles lugares donde poder estacionar el nuestro. Por todo ello, hemos optado por escoger el intercambio de datos por medio de XML que nos permite una comunicación rápida y un manejo de la información sencillo para poder ofrecerla al usuario de una forma intuitiva. GEOLOCALIZACIÓN( Basamos el funcionamiento de nuestra aplicación en el uso de las capacidades y características GPS de las que dispone el dispositivo, para poder identificar posiciones en el mapa y así poder ofrecer al usuario información no solamente textual, si no, que también pueda ver la misma plasmada en un mapa y facilitarle de este modo la utilización de la aplicación. JDO((JAVA(DATA(OBJECT(S(CLOUD(COMPUTING)( Como mencionábamos en la descripción de esta tecnología, es un servicio que Google nos facilita para poder aportar soluciones de hosting de una forma sencilla sin tener la necesidad de montar nuestro propio servidor. De este modo nuestra labor será construir nuestro servidor mediante la utilización de servelets (clase Java que puede recibir peticiones http y genera salidas normalmente en http, wml o xml y que se ejecuta en el servidor), los cuales, serán los encargados de llevar a cabo las tareas asignadas a la aplicación en la parte servidora. ! 48! ocupado en el módulo del servidor, eliminar dicho hueco del array que contiene la información de la tabla para que no aparezca en la visualización de la misma y por último crear el pertinente hueco libre en el módulo correspondiente del servidor.  didSelectedRowAtIndexPath es el último método de los implementados y se encarga de realizar el paso a la vista siguiente (visualización en el mapa del hueco en cuestión) cuando se pulsa sobre alguna de las celdas de la tabla, correspondiente a un hueco. - DetalleViewController.h/DetalleViewController.m: Se accede a ellas cuando presionamos sobre cualquiera de las filas disponibles en la tabla. Se trata de una clase de tipo UIViewController que tiene como delegada a MapViewDelegate, encargada de realizar las tareas de visualización en el mapa de los puntos de aparcamiento, en este caso ocupados, a tenor de las coordenadas de cada uno de los huecos almacenados en el servidor y que se encuentran a una distancia inferior a los kilómetros establecidos como umbral de visualización. Para la visualización del hueco en concreto es necesaria la creación de un objeto de tipo MKAnnotation, el cual, se encargara de aparecer en el mapa a modo de una chincheta en el mismo para mostrarnos la posición del hueco al que estamos haciendo referencia. Si pulsamos sobre el, nos aparecerá información de los metros a los que nos encontramos de la posición del hueco en concreto. PESTAÑA!UBICACIÓN! - (IBAction)buscarPosicion:sender; UIButton *boton; MKMapView *mapView; CLLocationManager *location; UbicacionViewController ! 49! En esta pestaña tan solo hacemos uso de una clase para llevar a cabo nuestro cometido. En ella se muestra la visualización de nuestra posición acutal en el mapa. UbicacionViewController.h/UbicacionViewController.m es la clase encargada de tal cometido. Se trata de una clase de tipo UIViewController, por lo tanto, una vista normal, pero con la salvedad que al igual que la descrita en último lugar en la pestaña “Home”, hereda de MapViewDelegate, con lo cual, se encarga de visualizar nuestra posición actual en el mapa. En ella no se ha llevado a cabo ninguna implementación adicional salvo la inicializar el objeto de localización en el método encargado de procesar la carga de la vista de la clase (viewDidLoad). En este caso se da código al método delegado didUpdateToLocation, el cual, se encarga de realizar las acciones pertinentes cuando se inicializa al objeto “locationManager”. Concretamente se establece el rango de visualización en el mapa y los parámetros necesarios para la visualización. PESTAÑA!HUECOS!LIBRES! ! 50! La tercera y última pestaña era la encargada de mostrarnos los huecos libres para poder estacionar el vehículo, que se encuentran almacenados en el servidor y que cumplen los requisitos, en cuanto a distancia a nuestra posición actual se refiere, de posición. En primera instancia nos aparece una vista con una tabla en la cual se listan los huecos libres almacenados en el servidor y que de nuevo cumplen los requisitos de restricción de distancia respecto a nuestra posición actual establecidas. Si pulsamos sobre cualquiera de las celdas, accederemos a una vista de mapa en la que observaremos exactamente la posición en el mapa de hueco seleccionado. Se trata por lo tanto, de un funcionamiento similar al que podemos encontrar en la primera pestaña. ListadoViewController.h/ListadoViewController.m son clases de tipo UITableViewController, por lo tanto son las encargadas de realizar la visualización de la tabla correspondiente a los huecos libres. Esta clase hereda de CLLocationManagerDelegate, con motivo de inicializar el objeto de este tipo para establecer la distancia entre nuestra posición actual y la del hueco disponible en el servidor. Del mismo modo que hacíamos en la pestaña “Home”, se implementan una serie de método delegados correspondientes a UITableView.  numberOfSectionsInTableView es un método en el cual se especifican cuantas secciones habrá en cada una de las celdas que componen nuestra tabla, que en nuestro caso hemos optado por establecer solo una, la correspondiente a la descripción del hueco en cuestión.  numberOfRowsInSection es el encargado de establecer el número de celdas que tendrá nuestra tabla, que en nuestro caso concreto viene establecido por el array encargado de almacenar los huecos libres disponibles en el servidor que se ajustan a los requisitos de limitación de distancia establecidos.  cellForRowAtIndexPath es el método delegado, encargado de establecer la información que se representa en cada una de las celdas de la tabla. Para el caso que nos ocupa, es tan sencillo como asignarle las descripción de cada uno de los huecos para cada una de las celdas.  commitEditingStyle se encarga de realizar las tareas necesarias cuando se lleva a cabo una modificación en la tabla, que en nuestro caso se limita únicamente al borrado. Cuando se borra una de las celdas de nuestra tabla estamos haciendo referencia al hecho de que estamos ocupando el hueco de aparcamiento que estaba libre, con lo cual, cuando hacemos dicha modificación el método se encarga de dar de baja el hueco libre en el módulo del servidor, eliminar dicho hueco del array que contiene la información de la tabla para que no aparezca en la visualización ! 51! de la misma y por último crear el pertinente hueco ocupado en el módulo correspondiente del servidor.  didSelectedRowAtIndexPath es el último método de los implementados y se encarga de realizar el paso a la vista siguiente (visualización en el mapa del hueco en cuestión) cuando se pulsa sobre alguna de las celdas de la tabla, correspondiente a un hueco. VistaDetalle.h/VistaDetalle.m finalmente son las clases de tipo UIViewController que heredan de MapViewDelegate, encargadas de realizar la visualización del punto exacto donde se encuentra el hueco seleccionado, mediante la creación de un objeto MKAnnotation, el cual, aparecerá en la vista del mapa como una chincheta de color rojo, de tal modo, que si pulsamos sobre ella, nos aparecerá información exacta sobre a que distancia nos encontramos de la posición del hueco en cuestión. ! 52! ! 53! 5.(DISEÑO(E(IMPLEMENTACIÓN(DEL(SERVIDOR( Una vez repasado el apartado técnico en lo que al aspecto de la aplicación en sí se refiere, lo que nos ocupa a continuación es establecer del mismo modo las bases y explicaciones técnicas referentes al desarrollo del servidor. Como hemos mencionado a lo largo de esta memoria, el desarrollo del servidor se basa en utilizar la tecnología que Google nos brinda por medio de Google App Engine para establecer un servidor que haga las veces de base de datos para nosotros poder almacenar y disponer de la información en el momento que nos sea preciso y poder establecer una comunicación entre el mismo y la aplicación en sí. El desarrollo está basado en lenguaje Java Data Object y simplemente es necesario para este caso observar los métodos necesarios y librerías a importar para poder utilizar esta metodología puesto que los fundamentos y el modo de proceder es exactamente igual al experimentado durante el desarrollo de la carrera universitaria. Como último apunte, cabe mencionar, que cada uno de los funcionamientos específicos de los que dispondrá nuestro servidor, se desarrolla en un “servlet” diferente, entendiendo por “servlet” a la función Java que desarrolla un cometido en concreto. CLASE!HUECO!Y!HUECOL! El desarrollo de estas clases corresponde con la creación de los objetos Java que son con los que interactuaremos a la hora de almacenar o borrar los mismos. La creación de estos objetos no conlleva mayor modificación que la que haríamos con cualquier objeto que queramos crear en lenguaje Java, es decir, un método o métodos constructores para el objeto, una serie de modificadores para cada uno de los atributos y una serie de métodos para obtener el valor de dichos parámetros. La única modificación que hay que llevar a cabo es la de establecer una serie de características a la hora de declarar los atributos que ha de tener el objeto. El objetivo a la hora de crear nuestros objetos es que estos sean persistentes para poder ser almacenados. El “dataStore” que nos proporciona Google App Engine, trabaja con entidades, mientras que JDO lo hace con objetos persistentes por lo que tendremos que hacer la conversión de los mismos mediante anotaciones y precisamente estas anotaciones constituyen las diferencias de los objetos declarados con un objeto normal de Java. ! 54! La directiva @PersistentCapable indica que una clase puede ser almacenada y recuperada mediante el soporte JDO. Es por este motivo por el que hacemos uso de esta clausula antes de la declaración de la clase para que podamos utilizar la misma como un objeto JDO y poder tratar con él en el “dataStore”. El siguiente elemento novedoso que encontramos es @PrimaryKey que constituye la clave primaria de la clase. Se refiere al hecho que para cada objeto que nosotros creemos de este tipo, tendrá un identificador que lo hará único en el servidor para poder tratar con él. En nuestro caso se ha optado por un identificador numérico de tipo “Long” que facilitará el trato y la representación de cada uno de los objetos hueco. Esta clausula irá obligatoriamente acompañada de la directiva @Persistent, puesto que también se almacenará. Precisamente la directiva @Persistent constituye el elemento necesario para poder almacenar dicho atributo perteneciente a la entidad en el “dataStore” y supone la última modificación reseñable de esta clase. CLASE!PMF! Se trata de la clase que nos proporcionará la opción de poder operar con los objetos persistentes almacenados en el servidor. En nuestro caso simplemente necesitamos realizar la instancia del mismo para poder utilizar dichas operaciones. Con todo, este es el aspecto que presenta la clase. ! 55! Como se puede observar, se crea para la clase PMF, un atributo “pmfinstance”, en el cual, se realiza la pertinente llamada al gestor de persistencia y creamos el método que nos devolverá dicho atributo. SERVLETS!PARA!INICIAR!UN!HUECO! Los “servlets” que tiene por objetivo crear un hueco, ya sea libre o ocupado, para que sea persistente en el servidor se basan en aceptar peticiones al método post del “servlet”, recogiendo los datos de la petición e instanciando al constructor pertinente del objeto hueco y así, una vez creado el mismo, poder dotarlo de la persistencia correspondiente. El aspecto que presenta es el que se puede apreciar en la figura que se presenta a continuación. 1 ( ( () ! 56! Como vemos en la zona marcada mediante el rectángulo lo que hacemos es una vez se ha llamada al método post, directamente o redirigido por el método get, se capturan los parámetros de la petición por medio de la instrucción getParameter, correspondiente a la variable “req” que es de tipo HttpServletRequest (variable que almacena los parámetros de la petición recibida por el servidor) y se van almacenado los valores correspondientes en consonancia a los parámetros que definen cada uno de los huecos que vamos a ir almacenando en nuestro servidor. Finalmente como se observa en la zona marcada mediante un círculo, apreciamos como haciendo uso del objeto de persistencia creado previamente (pmf), utilizamos su método makePersistent para hacer que nuestro servidor haga el objeto creado persistente en el datastore. El ejemplo representado hace referencia a la creación de un hueco libre. El aspecto que presenta el servlet encargado de inicializar huecos ocupados tiene el mismo aspecto, cambiando únicamente el constructor al que se invoca, una vez extraídos los parámetros de la petición. SERVLETS!PARA!ELIMINAR!UN!HUECO! En estos servlets lo que se pretende es que a través del identificador de cada uno de los huecos, tanto libres como ocupados, se pueda eliminar el hueco en concreto. Esto quiere decir que en cada petición al servidor, debemos pasar el identificador que habíamos definido mediante la claúsula @primaryKey, y a través del mismo proceder a la eliminación de forma persistente del datastore. La apariencia que tendrán nuestros servlets encargados de la eliminación es la que se presenta. ! 57! Como observamos en la figura, en primer lugar se crea una instancia del objeto de persistencia, para posteriormente capturar el id del mismo modo que capturábamos los parámetros de las peticiones de alta de huecos, mediante el método getParameter() y una vez tenemos el id, único para cada hueco almacenado en el servidor, debemos hacer una consulta al mismo para obtener el hueco en cuestión (mediante el método getObjectById) y su posterior eliminación (con el método deletePersistent, que eliminará de forma persistente el hueco del datastore). Del mismo modo que en el caso anterior, el ejemplo expuesto en la figura se corresponde con la llamada al servlet encargado de la eliminación de huecos ocupados, por lo que el código correspondiente a los huecos ocupados presenta el mismo aspecto, pero haciendo referencia lógicamente a ese tipo de hueco. SERVLETS!DE!LISTADO!DE!CONTENIDO! Por último, estos son los servlets encargados de mostrar el contenido de la aplicación, ya sea en el navegador o bien invocado por la propia aplicación que hemos diseñado. Básicamente lo que se realiza en ellos es una petición de consulta sobre el servidor para obtener una serie de objetos que se ajusten a un patrón de búsqueda simple (no se puede hacer una petición compleja en la que seleccionar varios parámetros para poder obtener los datos) para posteriormente establecer la estructura XML que tendrán los datos obtenidos en dicha consulta y redirigir los mismos a la salida estándar para que en el momento en que sean invocados por el navegador, la información se vea plasmada en el mismo y en el caso de que sean invocados desde la aplicación obtener la información en formato XML. Por todo lo mencionado el aspecto que presentarán estos servlets es el que podemos observar en la figura que se muestra a continuación. ! 64! ! 65! 8.(TRABAJO(FUTURO¿?( En el desarrollo de la aplicación nos hemos encontrado con ciertos problemas que no han facilitado la labor de llevar a cabo el desarrollo de la misma. El principal problema que he tenido en el desarrollo ha sido de parte del servidor. Hemos observado que las consultas que se realizan a la base de datos que Google nos proporciona mediante el uso de la tecnología Google App Engine, tan solo se pueden realizar de modo simple, es decir, no se pueden llevar a cabo consultas complejas en las que poder seleccionar diferentes parámetros para establecer un filtrado de los parámetros a mostrar, por lo que ha sido necesario realizar una selección de los datos de un modo interno en el código de la aplicación una vez éstos han sido descargados del servidor. Por otro lado es conveniente mencionar las diferentes modificaciones que pueden llevarse a cabo de la misma para poder dotar a la aplicación de un carácter más práctico, todavía si cabe. Podemos utilizar el sistema de integración con cuentas de Google que incorpora Google App Engine para poder utilizar datos del usuario que en un momento determinado esta utilizando la aplicación, para poder asociar los datos de un hueco determinado con los de un individuo determinado. Otro punto a tener en consideración para una posible mejora en el funcionamiento de la aplicación es la incorporación del uso de “notificaciones push” en la misma para que el usuario disponga de mensajes e información que se está produciendo en tiempo real. Por medio de esta herramienta, podemos suscribirnos a un canal de información, que en nuestro caso sería la cantidad de huecos libres disponible en el servidor, que nos irá ofreciendo puntualmente notificaciones ante posibles cambios en el servidor, en cuanto a huecos libres almacenados en el mismo se refiere. Del mismo modo, puesto que hemos establecido un filtro para mostrar únicamente aquellos huecos que por la distancia a la que se encuentran de nuestra posición pueden o no pueden ser mostrados en la aplicación, podemos dotar a la aplicación de funcionalidad para aparecer en el menú de ajustes de nuestro terminal para que el usuario ajuste, dependiendo de sus deseos el grado de precisión del filtro a aplicar a la información recibida del servidor, dotando a nuestra aplicación de una mayor interacción con el usuario puesto que él es en todo momento el que toma las decisiones sobre lo que desea o no desea mostrar. ! 66! ! 67! 9.(BIBLIOGRAFÍA( ! 1. Desarrollo(de(aplicaciones(para(iPhone(&(iPad,!Joe!Conway,!Aaron! Hillegass.!ISBN:!978Y84Y415Y2932Y8!(2011)! ( ( 2. Desarrollo(de(aplicaciones(para(iPhone,(John!Ray,!Sean!Jhonson.!ISBN:! 978Y84Y415Y2795Y9!(2011)! ! 3. Stackoverflow,(www.stackoverflow.com! ! 4. iPhone(Dev(SDK,(www.iphonedevsdk.com/forum! ! 5. Apple(Documentation,(developer.apple.com! ! 6. Imaginaformacion,(www.imaginaformacion.com/tutoriales! ! 7. AdictosAlTrabajo,(www.adictosaltrabajo.com/tutoriales! ! 8. Google(App(Engine,!developers.google.com/appengine! ! 9. Java(Data(Objects,!db.apache.org/jdo/pm.html! ! 10. Rose(India,!www.roseindia.net/servlets! ! ! !