UNIVERSIDAD JAUME I INGENIERÍA TÉCNICA EN INFORMÁTICA DE SISTEMAS CURSO PROYECTOS INFORMÁTICOS DE SISTEMAS (IS31)

Transcripción

1 UNIVERSIDAD JAUME I INGENIERÍA TÉCNICA EN INFORMÁTICA DE SISTEMAS CURSO PROYECTOS INFORMÁTICOS DE SISTEMAS (IS31) PROGRAMACIÓN CON LAS APIS DE FLICKR Y YOUTUBE EN DISPOSITIVOS ANDROID Proyecto presentado por: VÍCTOR ORTÍ PASCUAL y dirigido por: RAUL MONTOLIU COLÁS Castellón de la Plana, Junio de 2011

2 Resumen El presente proyecto pretende exponer el desarrollo de una aplicación informática para dispositivos móviles que disponen del sistema operativo Android y cuyas funcionalidades principales son: Acceder a la cuenta de un usuario (previamente registrado en la base de datos interna de la aplicación) del portal web Flickr y visualizar sus fotografías en diversos formatos y resoluciones. Acceder y visualizar tanto los videos almacenados en un canal del servidor web YouTube especificado por el usuario de la aplicación, como aquellos almacenados en una tarjeta de memoria externa de tipo SD Card. 1

3 Agradecimientos Bajo mi punto de vista, la conclusión del proyecto final de los estudios universitarios representa uno de esos momentos del periplo estudiantil en los que merece la pena echar la vista atrás y hacer balance de todo lo acontecido. No sólo significa el fruto de varios meses de estudio y desarrollo, sino que su entrega encarna la consumación de unos estudios universitarios a través de años de entrega, sacrificio y trabajo. La obtención de un título universitario no es posible entender si no se enmarca dentro de un proyecto mayor como es la vida. Por ello, he de estar agradecido a mi familia. También quiero dar las gracias a mi tutor en la universidad Jaume I Raúl Montoliu Colás y a todos los integrantes de la empresa Sofistic Telematic Security S.L. por su orientación, consejos y paciencia durante todo el proyecto. Su disponibilidad y el buen trato tenido siempre conmigo han sido de gran ayuda. Y gracias igualmente a todos aquellos y aquellas que han aparecido en la aventura de los estudios universitarios. 2

4 Índice general 1. Introducción Motivación del proyecto Objetivos Planificación Versión inicial del diagrama Versión final del diagrama Costes Entorno del proyecto Dispositivos móviles Clasificación de los dispositivos móviles Smartphones Sistemas operativos para dispositivos móviles Tecnologías utilizadas Bases de datos...21 Qué es una base de datos?...21 Puntos fuertes de una base de datos...22 Puntos débiles de una base de datos SQL...23 Qué es SQL?...23 Puntos fuertes de SQL...24 Puntos débiles de SQL HTTP...25 Qué es HTTP?...25 Puntos fuertes de HTTP...28 Puntos débiles de HTTP XML...29 Qué es XML?...29 Puntos fuertes de XML...29 Puntos débiles de XML Conceptos sobre Android Qué es una plataforma de software? Qué es Android? Breve historia Características de Android Arquitectura de Android Android SDK Anatomía de una aplicación Android Activity Intents Listeners Services Content providers Android manifest Tipos de aplicación Android

5 4.5.1 Tareas Procesos Threads Ciclo de vida de una aplicación en Android...40 Proceso en primer plano...41 Proceso visible...41 Proceso de servicio...41 Proceso en segundo plano...41 Proceso vacío Almacenamiento de datos Imágenes de disco Gráficos Direccionamiento en Android Recursos Herramientas de desarrollo Programación con las APIs de Flickr y Youtube en dispositivos Android Introducción Acceso a la API Flickr [13] Acceso a la API de datos de YouTube [14] Desarrollo del proyecto Análisis de la aplicación Análisis de los requerimientos de la aplicación Diseño de la aplicación Diseño de la interfaz Casos de uso Modelo de clases Desarrollo e implementación Pruebas Conclusión Valoración personal Líneas futuras Apéndice A. Manual de instalación de la aplicación Referencias

6 1. Introducción Entre todas las cosas que los dispositivo móviles han sido, son y llegarán a ser, una clara tendencia es el aumento en las capacidades de producción y consumo de media (medios audiovisuales) que ofrecen. Esta inclinación se inició con el advenimiento de la cámara en los teléfonos móviles a finales de los año noventa, y durante los últimos años ha empezado a tener éxito con la creciente popularidad de los smartphones. En términos de capacidades multimedia los dispositivos móviles son al mismo tiempo cámaras fotográficas, álbumes de fotos, videocámaras, reproductores de vídeo, reproductores de audio, máquinas de dictado y potencialmente mucho más. La motivación de la preferencia por el sistema operativo Android como elemento principal de la aplicación recae en su relativa reciente aparición en el mercado, por lo que en mi opinión es objeto de ser estudiado para descubrir sus posibilidades. En la actualidad existen multitud de aplicaciones que muestran sus funcionalidades. Por otra parte, su cualidad de abierto, permite la posibilidad de desarrollar cualquier aplicación propia y hacer uso de ella en el dispositivo, lo cual lo convierte en un campo de pruebas estupendo para experimentar y poner en práctica nuevas ideas. Por último, gracias a su completo SDK (siglas en inglés de Software Development Kit, paquete de desarrollo de software) y su emulador permite ahorrar costes económicos en el desarrollo y poder testear aplicaciones de una manera rápida y sencilla. Aunando todos las ideas expuestas, en este proyecto se ha buscado desarrollar una aplicación para el sistema operativo Android, que muestre algunas de sus funcionalidades básicas y algunas de las posibilidades que ofrece en el terreno multimedia [1]. La primera sección del proyecto describe las tecnologías empleadas en el entorno de trabajo, revelando aspectos tanto positivos como negativos. La segunda sección se concentra en el sistema operativo Android. Inicialmente se presenta de manera sucinta su origen, continuando con la observación de los recursos que brinda. La tercera sección traslada a un enfoque empírico, mostrando la planificación del proyecto, un diagrama de casos de uso y algunas capturas de pantalla de la aplicación a modo de diagrama de estados. Por último se revela la aplicación diseñada en la cual se pretende armonizar los conceptos explicados a lo largo del proyecto. Se detallan las funciones implementadas, así como algunas conclusiones adquiridas y posibles itinerarios posteriores. 5

7 1.1 Motivación del proyecto Si echamos la vista atrás y observamos el desarrollo científico-tecnológico que ha experimentado la Humanidad desde mediados del siglo XX hasta hoy, no cabe duda que además de un avance se ha producido una verdadera revolución. El descubrimiento de la informática, su gradual aplicación en todo tipo de áreas del conocimiento y la producción, así como su introducción en el común de la población a través de todo tipo de componentes puede que haya cambiado nuestra sociedad y nuestra economía más rápido que cualquier otro hecho o descubrimiento anterior. La computadora es uno de los inventos que mejor resume la nueva situación tecnológica. Se manifestaron primero como enormes y costosas máquinas que solamente estaban disponibles en importantes universidades o centros de investigación. Con la aparición de nuevas técnicas de fabricación, como los circuitos integrados; su dimensión, capacidad, y en especial su precio, variaron de tal manera que se convirtieron en otro producto de masas, como lo podían ser la televisión o la radio. El nacimiento de Internet, y sobre todo su apertura al público general, determinaron de manera inequívoca la presencia de las ordenadores en la vida social, laboral o académica de cualquier persona hasta el día de hoy. Simultáneamente al surgimiento de Internet como servicio abierto, a principios de la década de 1990, surgió otro medio de comunicación que, si bien era más antiguo, se volvía a inventar a sí mismo gracias a los cambios en su tradicional soporte: la telefonía móvil. El boom en la implantación de Internet, junto al furor de la telefonía móvil, confirmaba que esta revolución tecnológica no sólo afectaba a la investigación o la actividad económica, sino que implicaba un fenómeno sociológico donde la comunicación y el acceso a la información en cualquier lugar y momento eran sus pilares primordiales. Como no podía ser de otra manera, la reducción del tamaño de los componentes y el aumento de sus prestaciones permitió acercar cada vez más ambos mundos, de forma que a través de un teléfono móvil no sólo se podían hacer llamadas o enviar SMS (siglas en inglés de Short Message Service, servicio de mensajería breve), sino que además se podía tener un acceso más o menos limitado a Internet, o incluso funciones adicionales como realizar fotografías o vídeos. Otros aparatos de similar tamaño, no directamente relacionados con la telefonía, surgieron y se hicieron tan populares como los primeros. Desde ese momento puede empezar a usarse el término genérico dispositivo móvil. Así pues, un dispositivo móvil es un término general que describe una extensísima familia de aparatos electrónicos surgidos en los últimos años, de reducido tamaño, que ofrecen capacidades de procesamiento y almacenamiento de datos y que están orientados a una función concreta o varias de ellas: desde los teléfonos móviles más evolucionados (los llamados smartphones), a computadoras portátiles (laptops), cámaras digitales, consolas de videojuegos o reproductores de música. 6

8 La mayoría de estos aparatos cuentan con un sistema operativo de mayor o menor complejidad, que permite realizar las tareas de gestión de memoria y control de hardware que precisan. En el caso de las computadoras portátiles, con tanta o incluso mayor capacidad que los de sobremesa, los sistemas operativos habituales son perfectamente compatibles y funcionan sin diferencias. Sin embargo, en otros dispositivos móviles es preciso diseñar nuevos sistemas operativos adaptados específicamente a sus características: con restricciones de memoria y procesamiento, un consumo mínimo de energía o gran estabilidad en su funcionamiento, entre otros. Algunos de los sistemas operativos para dispositivos móviles más utilizados son Symbian, ios y Windows Mobile, la versión móvil del gigante Microsoft. Este reparto puede verse sustancialmente afectado por la incursión de otro gigante de Internet, Google, a través de su propio sistema operativo de nombre Android. Google es una joven compañía surgida a finales de los años 90 que pronto se hizo muy popular gracias al potente buscador del mismo nombre. Durante años, Google no ha dejado de crecer y de ofrecer toda clase de servicios basados siempre en Internet y en la combinación de la última tecnología disponible con la máxima experiencia del usuario. Android, más que un sistema operativo, representa toda una pila de software para dispositivos móviles que incluye gran cantidad de controladores, gestor de bases de datos, una completa framework de aplicaciones y numerosas aplicaciones de usuario. Android está basado en el núcleo de Linux y todas sus aplicaciones se escriben habitualmente en lenguaje Java, disponiendo además de una máquina virtual específica llamada Dalvik. Con la aparición de este sistema, Google pretende aprovechar al máximo la cada vez mayor capacidad de los dispositivos móviles, que llegan a incluir componentes como GPS (siglas en inglés de Global Positioning System, sistema de posicionamiento global), pantallas táctiles, conexiones rápidas a Internet, y por supuesto, todos los servicios asociados hasta el momento a los teléfonos móviles, además de aplicaciones de usuario que parecían limitadas a las computadoras, como clientes de correo, aplicaciones ofimáticas o videojuegos. En Android, cada aplicación se ejecuta en su propio proceso, donde el sistema decide en cada momento qué aplicación debe ser eliminada para liberar recursos en caso de necesitarlos, responsabilizándose igualmente de restaurarla de forma totalmente transparente al usuario. Navegar entre varias aplicaciones abiertas deja de ser una característica propia de computadores. Android se lanza bajo la licencia Apache, lo cual supone que, como software libre, cualquier desarrollador tiene acceso completo al SDK del sistema, incluidas todas sus API, documentación y el emulador para pruebas, siendo posible su distribución y modificación. Esta licencia permite además a los desarrolladores tanto publicar sus creaciones, como distribuirlas únicamente bajo pago ocultando el código fuente. Este nuevo sistema introduce también interesante conceptos, como es la composición de sus aplicaciones a través de combinación de módulos o bloques básicos, según la naturaleza de la aplicación, o la delegación en el sistema de determinadas acciones para que sean otras aplicaciones instaladas las que se hagan cargo de ellas. 7

9 Dada la creciente importancia y popularidad de estos dispositivos y su más que probable implantación masiva, cada vez con mayores prestaciones y capacidades, unida al éxito que suele acompañar a Google en sus proyectos, todo parece indicar que Android podría posicionarse en un futuro más o menos cercano como uno de los sistemas operativos más utilizados en el mundo en el ámbito de la telefonía móvil. 1.2 Objetivos Para poder dirigir con mayor éxito los esfuerzos por conocer y comprender las características de este nuevo sistema, es necesario fijar unos objetivos que abarquen las actividades que se pretenden realizar y, además, permitan al final de las mismas conocer el grado de desarrollo y cumplimiento alcanzado. Por ello, los objetivos perseguidos en el desarrollo de este proyecto final de los estudios universitarios son los enumerados a continuación: 1. Conocer las principales características de Android El primer paso para comprender este nuevo sistema debe consistir en indagar toda la información posible sobre él, a fin de conocer cuál es su arquitectura, sus componentes básicos, y cuál es su comportamiento al ejecutar las aplicaciones, documentándose acerca de todos estos aspectos. Además, es pertinente indagar cuáles son las ventajas y posibilidades reales que Android ofrece frente a otros sistemas de similar naturaleza. 2. Estudiar el entorno de desarrollo de Android Al lanzarse bajo una licencia de software libre, el SDK completo está disponible para cualquier desarrollador que desee descargarlo. Este incluye numerosas ayudas para comenzar a crear aplicaciones en Android, desde las API completas con todas las clases y paquetes, hasta herramientas de programación y un completo emulador para poder realizar pruebas. Todos estos elementos deberán ser cultivados y desarrollados en la medida de lo posible. 3. Desarrollar una aplicación completa para Android haciendo uso de las APIs de los portales web YouTube y Flickr para acceder a sus respectivos contenidos Una vez averiguadas las particularidades de este sistema, así como el entorno de desarrollo que ofrece y algunas de sus posibilidades a la hora de comunicarse con entornos web a través de una API, nos incumbe la creación de una aplicación que aproveche algunas de sus características fundamentales. A través de su desarrollo y la documentación del mismo, el lector debe poder comprender mejor el funcionamiento de aplicaciones para Android, así como animarse a crear sus propias aplicaciones. 8

10 2. Planificación En las figuras 1 y 2 se muestran el diagrama y la gráfica de planificación inicial diseñados durante la propuesta técnica del proyecto. En mi opinión la planificación realizada en tales diagramas no ha podido cumplirse por los siguientes motivos: Dificultad por mi parte para estructurar el proyecto en cada una de sus secciones. Dudas en la implementación de algunos objetos y/o funcionalidades asociadas. 2.1 Versión inicial del diagrama Figura 1: Diagrama inicial Figura 2: Planificación inicial 9

11 2.2 Versión final del diagrama En las figuras 3 y 4 se muestran el diagrama y la gráfica modificados. Figura 3: Diagrama final Figura 4: Planificación final 10

12 A continuación se explican con brevedad los distintos puntos que componen la planificación: Propuesta técnica Al tratarse de un proyecto no incluido en los sugeridos por la Universidad Jaume I, propuse realizar un nuevo proyecto en la empresa en la cual me encontraba realizando la asignatura de prácticas de empresa, la cual aceptaron y a continuación hubo que buscar un/a profesor/a que estuviera interesado/a en el proyecto y pudiera tutorizarlo. Cita inicial con el tutor Durante la primera reunión con el tutor se expuso de manera informal cual iba a ser el proyecto y sus objetivos iniciales. A partir de ese día se acordó realizar reuniones cada quince días para comentar la evolución y dudas que fueran surgiendo a lo largo del proyecto. Definición de objetivos Una vez acordada la realización del proyecto de manera informal, se pasó a diseñar las interfaces de usuario y los diagramas de casos de uso y clases. Búsqueda de documentación Este punto requirió bastante tiempo puesto que se trata de mi primera incursión en el lenguaje de programación Java y en el desarrollo para dispositivos móviles. Adquisición de conocimientos Pese a tratarse de un campo de investigación relativamente nuevo (al menos en el ámbito estudiantil universitario), Internet ya dispone de numerosos foros, blogs dedicados, tutoriales y libros electrónicos que tratan la materia. Instalación de las herramientas Una vez terminada la búsqueda y asimilación de información, era pertinente indicar los requisitos para realizar la aplicación. En este caso los tres elementos fundamentales son una computadora con conexión a Internet, el software Eclipse y las ADT (Android Development Tools) a integrar en el entorno de Eclipse, todas ellas gratuitas. Análisis y diseño Una vez conocidos los requisitos de la aplicación, se trataba de pensar cómo se iba a diseñar. A partir de los diagramas, diseñar cuantas clases, objetos y/o bases de datos serían necesarios junto con sus respectivos campos y métodos. Implementación Este punto para mi ha sido el más costoso en términos temporales, se trataba de codificar ideas y en mi opinión no es tarea fácil. 11

13 Pruebas iniciales de la aplicación y adaptaciones / revisiones Una vez terminada una primera versión de la aplicación, en la empresa estuve realizando pruebas con un dispositivo móvil que ellos mismos me proporcionaron para comprobar que la aplicación se comportaba según lo previsto y poder subsanar errores graves tanto de implementación como de seguridad. Redacción de la memoria La redacción de la memoria se comenzó una vez vi la parte de codificación bastante avanzada para poder incluir el progreso realizado durante el diseño del proyecto. 2.3 Costes Para la realización de este proyecto no hubo necesidad de realizar ninguna inversión económica inicial puesto que se disponía de las herramientas (adquiridas de forma gratuita a través de la WWW) y los equipos necesarios para empezar. Sin embargo, para los interesados en el desarrollo de Android adjunto la siguiente tabla que intenta describir todo aquello que un nuevo desarrollador de Android debería disponer: Tabla 1: Herramientas necesarias y costes aproximados para desarrollar sobre Android Kit de desarrollo de Software (Software Development Kit) Android SDK 0 Computadora Personal PC / Mac Dispositivo móvil con Android Dispositivo móvil Emulador 0 Android Market Subir la aplicación registrada 25 Coste Total Aproximado

14 3. Entorno del proyecto 3.1 Dispositivos móviles En mi opinión no existe un claro convenio a la hora de definir qué es ciertamente un dispositivo móvil y qué no lo es. Es frecuente que hoy en día este término se utilice para designar únicamente a ciertos modelos de teléfonos móviles con más o menos prestaciones. A pesar de ello, un dispositivo móvil no tiene por qué ceñirse únicamente al ámbito telefónico. Buscando ser más rigurosos, se podría denominar dispositivo móvil a todo dispositivo electrónico que cumple unas características muy básicas: Reducido tamaño, facilitando su transporte. Cierta capacidad de computación y almacenamiento de datos. Integración de elementos de entrada/salida básicos (habitualmente, pantalla y/o algún tipo de teclado). Más allá de estas propiedades comunes, los dispositivos móviles forman en la actualidad un grupo sumamente heterogéneo y pueden incorporar poco más o menos cualquier componente de hardware y software que amplía y diversifica su función inicial. El más frecuente sin duda es la conexión telefónica (incluyendo servicios como el envío de SMS, MMS y acceso WAP) o la conexión a la World Wide Web. Igualmente son habituales cámaras fotográficas y de vídeo, pantallas táctiles, teclados QWERTY, receptores de radio, conexiones mediante infrarrojos y Bluetooth, dispositivos de memoria extraibles, localizadores GPS, acelerómetros etc. Desde el punto de vista del software, pueden incorporar también un amplio abanico de aplicaciones tales como programas ofimáticos, reproductores de audio y vídeo, organizadores, videojuegos, navegadores web o clientes de correo electrónico, entre otros Clasificación de los dispositivos móviles Al igual que sucede a la hora de definir qué es un dispositivo móvil, la clasificación que se pueda hacer de estos aparatos está sujeta a diferentes valoraciones y a veces no existe un acuerdo amplio para ubicar un dispositivo móvil en una determinada familia. En la década de los 90, tras la aparición de los primeros dispositivos, establecer clasificaciones más o menos rigurosas era posible debido a que cada aparato estaba claramente definido para una determinada función o para un delimitado público. El aumento de las prestaciones y funcionalidades que en la actualidad puede ofrecer cualquier dispositivo móvil dificulta el poder agruparlo dentro de un conjunto determinado. 13

15 Por ejemplo, un smartphone representa una evolución de un teléfono móvil tradicional, esto es, su cometido es ofrecer comunicación telefónica; sin embargo, cuenta con otros servicios adicionales como la conexión a Internet, servicios propios de una computadora como la gestión de aplicaciones, cámara de fotos y de vídeo o la posibilidad de reproducir películas y entretenerse con juegos electrónicos. La clasificación que a aquí se propone utilizará como principal criterio la funcionalidad o servicio principal para la que ha sido diseñado bien el propio dispositivo móvil, o bien aquel dispositivo del que directamente procede y del que supone una evolución mejorada. Tal y como se deduce de todo lo anteriormente explicado, la pertenencia a una categoría concreta no implica en absoluto que el dispositivo no pueda ofrecer otras muchas características propias de otras categorías. Dicho la anterior, los dispositivos móviles pueden ser clasificados en los siguientes grupos: 1. Dispositivo de comunicación Un dispositivo de comunicación es aquel dispositivo móvil cuyo cometido principal es ofrecer una infraestructura de comunicación, principalmente telefónica. Estos dispositivos ofrecen además servicios como el envío de mensajes SMS y MMS, o acceso WAP. En esta categoría se incluiría el tradicional teléfono móvil, precursor indiscutible dentro de los dispositivos móviles, la BlackBerry y el smartphone, que amplía considerablemente las prestaciones del primero mediante la pantalla táctil, la conexión a Internet o la ejecución de aplicaciones. 2. Dispositivo de computación Los dispositivos de computación son aquellos dispositivos móviles que ofrecen mayores capacidades de procesamiento de datos y cuentan con una pantalla y un teclado afines a los de una computadora de sobremesa. Dentro de este grupo encontramos las PDA, muy populares a finales de los años 90 y que permitían al usuario disponer de un organizador mucho más completo que los ofrecidos por los teléfonos móviles del momento, e incluso en ocasiones la visualización de documentos o el acceso a la Internet. Por otro lado, un dispositivo de computación también es una computadora portátil, que dentro de los dispositivos móviles son sin duda los que mayores prestaciones hardware ofrecen(igualando o superando a los de sobremesa) pero también los que tienen, con diferencia, un mayor tamaño, peso y precio. Las calculadoras gráficas pueden ser igualmente incluidas en este grupo de dispositivos de computación. 3. Reproductor multimedia Un reproductor multimedia es aquel dispositivo móvil que ha sido específicamente diseñado para proporcionar al usuario la reproducción de uno o varios formatos digitales de datos, ya sea audio, vídeo o imágenes. Dentro de estos dispositivos encontramos reproductores de 14

16 MP3, los DVD portátiles, los lectores de libros electrónicos, y en los últimos años los reproductores multimedia de la popular familia ipod de Apple, que ofrecen tanto audio y como vídeo. Estos dispositivos son con frecuencia los de más reducido tamaño y, junto a los teléfonos móviles y smartphones, los más extendidos. 4. Grabador multimedia Dentro de los dispositivos móviles, un grabador multimedia es un dispositivo que posibilita la grabación de datos en un determinado formato digital, principalmente de audio y vídeo. En esta categoría se hallan las cámaras fotográficas digitales o las cámaras de vídeo digital. 5. Videoconsola portátil Una videoconsola portátil es un dispositivo móvil cuya única función es la de proporcionar al usuario una plataforma de entretenimiento. Las videoconsolas portátiles fueron, junto a los teléfonos, los primeros dispositivos móviles en convertirse en un producto de masas. Hoy en día representan un importantísimo volumen de ventas dada su gran aceptación en la sociedad y son objeto de auténticas guerras comerciales entre las principales compañías del sector. Algunos ejemplos de esta categoría son la Nintendo DS de Nintendo, o la PSP de Sony Smartphones Dentro de los dispositivos móviles, un smartphone (cuya traducción en español sería teléfono inteligente ) es una evolución del teléfono móvil tradicional que cuenta con ciertas características y prestaciones que lo acercan más a un ordenador personal que a un teléfono tradicional. Entre dichas características, se puede encontrar una mejora en la capacidad de proceso y almacenamiento de datos, conexión a Internet mediante Wi-Fi, pantalla táctil, acelerómetro, posicionador geográfico, teclado QWERTY y diversas aplicaciones de usuario como navegador web, cliente de correo, aplicaciones ofimáticas, reproductores de vídeo y audio, etc. incluyendo la posibilidad de descargar e instalar otras nuevas. A pesar de estas importantes mejoras con respecto a sus predecesores móviles, el reducido tamaño de los smartphones conlleva inexorablemente limitaciones de hardware que los mantienen claramente diferenciados de los ordenadores convencionales. Estas limitaciones se reflejan principalmente en pantallas más pequeñas, menor capacidad del procesador, restricciones de memoria RAM y memoria persistente, y necesidad de adaptar el consumo de energía a la capacidad de una pequeña batería. Estas limitaciones obligan a tener muy presente la capacidad real del dispositivo a la hora de desarrollar su software, ya sean aplicaciones de usuario o el propio sistema operativo. 15

17 3.2 Sistemas operativos para dispositivos móviles El sistema operativo destinado a ejecutarse en un dispositivo móvil necesita ser fiable y atesorar una gran estabilidad, ya que incidencias habituales y toleradas en computadoras personales como reinicios o caídas no tienen cabida en un dispositivo de estas características. Además, debe acondicionarse adecuadamente a las consabidas limitaciones de memoria y procesamiento de datos, proporcionando una exacta y excepcionalmente rápida ejecución al usuario final. Estos sistemas han de estar completamente testeados y libres de errores antes de incorporarse definitivamente a la línea de producción. Las posibilidades que existen en una computadora estándar de realizar actualizaciones e incluso reinstalar mejores versiones del sistema para cubrir fallos o deficiencias son más limitadas en un dispositivo móvil. Es posible incluso que un artilugio de esta naturaleza deba estar funcionando de manera ininterrumpida durante semanas e incluso meses antes de ser apagado y reiniciado, a diferencia de lo que acaece con un ordenador personal. El consumo de energía es otro asunto a considerar: es importante que el sistema operativo haga un uso lo más racional y fructífero posible de la batería, ya que esta es limitada y el usuario siempre exige una mayor autonomía. Todos estos aspectos de los dispositivos móviles, entre otros muchos, han de ser tenidos en cuenta a la hora de desarrollar un sistema operativo competente en el mercado, atractivo para los fabricantes y que permita al usuario sacar máximo provecho de su terminal. Existen varios sistemas operativos para toda la gama de dispositivos móviles con una cuota de mercado aproximada a la mostrada en la tabla 2 [2]. 16

18 Tabla 2: Cuota de mercado del smartphone por país: País/OS % cuota, Mar 2010 % cuota, Mar 2011 Cambio, % Total smartphones vendidos (millones) Alemania 2,75 Symbian 47,3 25,4-21,9 0,7 RIM 4 3,4-0,6 0,09 ios 35,6 24,4-11,2 0,67 Windows 9,4 3,9-5,5 0,11 Android 1,7 35,5 33,8 0,98 Otro 2 7,4 5,4 0,2 Francia 2,79 Symbian 28,7 15,6-13,1 0,44 RIM 9,4 12,1 2,7 0,34 ios 46,5 22,6-23,9 0,63 Windows 6,1 1,9-4,2 0,05 Android 6,7 35,8 29,1 1 Otro 2,6 12 9,4 0,34 Italia 1,04 Symbian 63,2 46,9-16,3 0,49 RIM 6,9 4,6-2, ios 18,8 20,3 1,5 0,21 Windows 6,7 5,9-0, Android 1,6 18,6 17 0,19 Otro 2,8 3,7 0,9 0,04 17

19 País/OS % cuota, Jun 2010 % cuota, Jun 2011 Cambio, % Total smartphones vendidos (millones) US 2,75 Symbian 10,1 1,2-8, RIM 32,5 10,6-21,9 1,41 ios 21,1 27,2-6,1 3,62 Windows 12,8 4,9-7, Android 19 54,7 35,7 7,28 Otro 4,5 1,4-3,1 0, Tecnologías utilizadas Figura 5: Principales tecnologías presentes en una aplicación web para dispositivos móviles 18

20 Dentro de este proyecto, el sistema operativo Android constituye los cimientos sobre los que se desarrolla la aplicación. Sin embargo, son necesarias una serie de tecnologías adicionales para que la aplicación presente las funcionalidades requeridas. Las tecnologías empleadas son las descritas a continuación: Bases de datos Qué es una base de datos? Una base de datos es un conjunto de datos pertenecientes a un mismo contexto y almacenados de manera sistemática para su posterior uso. Dentro de esta definición de carácter global, nos centramos en las bases de datos en formato digital, las cuales permiten almacenar datos de gran variedad/tipos [3]. Su empleo va desde la gestión de datos en corporaciones hasta el uso en entornos científicos. Gracias a las bases de datos son posibles, por ejemplo, los foros y las redes sociales. Para poder gestionar y manipular las bases de datos se precisa de unos programas denominados sistemas gestores de bases de datos (en inglés DBMS: Database Management System) que permiten almacenar y acceder a los datos de un modo rápido y estructurado. De entre los diferentes tipos de bases de datos, la más frecuente y la que se utilizará en el presente proyecto, es la base de datos del tipo dinámico relacional. Fueron enunciadas por Edgar Frank Codd en 1970 [4]. Las bases de datos relacionales se basan en el uso de relaciones o tablas, que a su vez están compuestas por registros también llamados tuplas (las filas de una tabla), y campos (las columnas de una tabla). La principal ventaja de estas bases de datos es que no importa el orden de almacenamiento de los datos. Para poder introducir datos o extraerlos se utilizan consultas a la base de datos. También permiten ser ordenadas tomando cualquier campo como criterio y generar informes que contienen sólo determinados campos de cada tupla o registro. Figura 6: Estructura de ejemplo en una base de datos relacional Imagen extraída de 19

21 Puntos fuertes de una base de datos Impide la duplicidad de registros, a través de campos claves o llaves(controla la redundacia reduciendo el espacio de almacenamiento). Integridad referencial; al eliminar un registro elimina todos los registros relacionados de manera dependiente. Consistencia: provee facilidades para la manipulación de grandes volúmenes de datos (modificaciones con impacto mínimo, copias de seguridad). Tiempos de desarrollo reducidos y excelente calidad del sistema desplegado si son bien explotados por parte de los desarrolladores. Usualmente, proveen interfaces y lenguajes de consulta que simplifican la recuperación y/o modificación de los datos. Favorece la normalización por ser más comprensible y aplicable. Puntos débiles de una base de datos Necesidad: con muy pocos datos no es eficiente el uso de una base de datos. Complejidad y vulnerabilidad: los DBMS son software muy complejo y las personas que vayan a hacer uso de ellos deben tener conocimiento de las funcionalidades del mismo para ser capaces de aprovecharlo al máximo. Tamaño: la complejidad y la gran cantidad de funciones que tienen lo hacen un software de tamaño elevado, que requiere bastante memoria para poder funcionar. Coste económico del hardware adicional: los requisitos de hardware para poner en funcionamiento un DBMS son por lo general elevados SQL Qué es SQL? SQL (siglas en inglés de Structured Query Language ó lenguaje de consulta estructurado) [5] es un lenguaje declarativo de acceso a bases de datos relacionales que posibilita la especificación de diversos tipos de operaciones sobre las mismas. Una de sus características es el manejo del álgebra y el cálculo relacional permitiendo lanzar consultas con el fin de recuperar, de una forma sencilla, información de interés de una base de datos, así como también hacer cambios sobre la misma. La versión original de SQL fue desarrollada en la empresa IBM por Donald D. Chamberlin y Raymond F. Boyce a principios de los años 70. Esta versión, inicialmente llamada SEQUEL, fue diseñada para manipular y recuperar datos almacenados en una base de datos relacional original de IBM (System R). 20

22 IBM patentó esta versión de SQL en el año 1985, mientras que el lenguaje SQL no fue formalmente estandarizado hasta 1986, por el ANSI. Las siguientes versiones del estándar de SQL fueron realizadas como estándares ISO. El lenguaje SQL se divide en diversas piezas: Statements (declaraciones) Tienen un efecto persistente en los esquemas y/o datos. Queries (consultas) Consultan datos basándose en un criterio especificado. Expressions (expresiones) Producen valores para las tablas. Predicates (predicados) Especifican condiciones que pueden ser evaluadas por SQL para limitar los efectos de los statements o queries. Clauses (claúsulas) Constituyen componentes de los statements o queries. Figura 7: Sub-elementos del lenguaje SQL Imagen extraída de Puntos fuertes de SQL Se trata de un lenguaje declarativo de alto nivel de abstracción. A través de su orientación al manejo de conjuntos de registros y no a registros individuales, permite una elevada productividad en codificación y orientación a objetos, pudiendo realizar en una sola sentencia varias operaciones de lenguaje de bajo nivel. Puntos débiles de SQL Al ser un lenguaje declarativo, especifica qué es lo que se quiere realizar y no cómo lograrlo, por lo que una sentencia no establece de manera explícita un orden de ejecución. 21

23 El orden de ejecución interno de una sentencia puede comprometer de forma acusada la eficiencia del DBMS, razón por la cual se hace necesario llevar a cabo una optimización antes de la ejecución de la misma. Muchas veces, el uso de índices acelera una instrucción de consulta, pero ralentiza la actualización de los datos. Dependiendo del ámbito de uso de la aplicación, se priorizará el acceso indexado o una rápida actualización de la información, siendo recomendable llegar a un compromiso. Otros aspectos adversos relacionados con el lenguaje SQL son la inconsistencia (incompatibilidad) entre las diferentes implementaciones de SQL y la sintaxis de SQL, que puede llegar a ser enrevesada dando lugar a peticiones equivocadas que alteren de manera errónea la base de datos HTTP Qué es HTTP? HTTP [7] (siglas en inglés de HyperText Transfer Protocol o protocolo de transferencia de hipertexto) es el protocolo usado en cada transacción de la WWW. HTTP fue desarrollado por el consorcio W3C [8] y la IETF [9]. Colaboración que culminó en 1999 con la publicación de una serie de RFC (siglas en inglés de Request For Comments), siendo el más importante de ellos el RFC 2616 [10], que especifica la versión 1.1. HTTP define la sintaxis y la semántica que utilizan los elementos software de la arquitectura web (clientes, servidores, proxies etc..) para comunicarse. Es un protocolo orientado a transacciones y sigue el esquema petición-respuesta entre un cliente y un servidor. Al cliente que efectúa la petición (un navegador o un spider) se lo conoce como user agent (agente de usuario). A la información transmitida se la llama recurso y se la identifica mediante un URL. Los recursos pueden ser archivos, el resultado de la ejecución de un programa, una consulta a una base de datos, la traducción automática de un documento, etc. HTTP es un protocolo sin estado, es decir, que no guarda ninguna información sobre conexiones anteriores, sin embargo, el desarrollo de aplicaciones web necesita frecuentemente mantener un estado. Para esto se usan las cookies, que es información que un servidor puede almacenar en el sistema cliente. Esto le permite a las aplicaciones web instituir la noción de sesión, y también permite rastrear usuarios ya que las cookies pueden guardarse en el cliente por tiempo indeterminado. 22

24 Figura 8: Arquitectura web básica Imagen extraída de Ejemplo simplificado de comunicación entre un cliente y un servidor utilizando el protocolo HTTP: La comunicación entre el cliente y el servidor se realiza en dos etapas: El navegador hace una petición HTTP. El servidor procesa la petición y envía una respuesta HTTP. En realidad, la comunicación se lleva a cabo en varias etapas si se tiene en cuenta el procesamiento de la petición por el servidor. PETICIÓN HTTP Una petición HTTP es un conjunto de líneas enviadas al servidor por el navegador. Incluye: Una línea de solicitud: es una línea que especifica el tipo de documento solicitado, el método que debe aplicarse, y se utiliza la versión del protocolo. La línea se compone de tres elementos que deben estar separados por un espacio: El método La URL La versión del protocolo usado por el cliente (habitualmente HTTP/1.1) Los campos de la cabecera (encabezado) de la solicitud: es un conjunto de líneas opcionales que permiten obtener información adicional acerca de la solicitud y/o el cliente que la realiza (navegador, sistema operativo, etc). Cada una de estas líneas esta formada por un nombre que describe el tipo de cabecera, seguido de dos puntos (:) y el valor correspondiente de la cabecera. 23

25 El cuerpo de la petición: es una colección de lineas opcionales que deben separarse de las lineas precedentes por una linea vacía y que por ejemplo permiten enviar datos a través del comando POST durante el envío de información al servidor utilizando un formulario. Figura 9: Formato de una petición HTTP Imagen extraída de RESPUESTA HTTP El servidor de ejemplo responderá con un mensaje en cual indicará el tipo de respuesta, la fecha, información sobre el servidor, cuando fueron modificados por última vez los datos, su longitud, el estado de la conexión y el tipo de formato de los datos: HTTP/ OK Date: Mon, 23 May :39:21 GMT Server: Apache/ (Unix) (Red-Hat/Linux) Last-Modified: Wed, 08 Jan :11:55 GMT Content-length: 438 Connection: close Content-type: text/html; charset = UTF-8 24

26 Los tipos de respuesta están cifrados según el siguiente código: Código 1xx 2xx 3xx 4xx 5xx Descripción Informativa. Indican una respuesta provisional, la petición aun se está procesando. Éxito. La petición se recibió, se entendió y se aceptó. Redirección. El cliente tiene que realizar una acción adicional para completar la petición. Error en el lado del cliente. Error en el lado del servidor. Para obtener más información sobre los tipos de respuesta HTTP, consulta la URL: El protocolo HTTP define 8 métodos para realizar determinadas acciones, siendo los tres más empleados: HEAD: Solicita una representación del recurso solicitado, pero sin el cuerpo del mensaje. GET: Solicita una representación del recurso solicitado con el cuerpo del mensaje incluido. POST: Envía información para que sea procesada en el recurso identificado. La información se incluye en el cuerpo de la petición. Puntos fuertes de HTTP HTTP es un protocolo sin estado, con lo cual, los hosts no tienen la necesidad de retener información entre peticiones. Permite conexiones seguras. Permite conexiones persistentes, mediante las cuales se reduce el tiempo de espera evitando al cliente la re-negociación de la conexión TCP después de la primera petición enviada. 25

27 Puntos débiles de HTTP El hecho de tratarse de un protocolo sin estado, es un inconveniente para los desarrolladores web que deben ingeniar maneras alternativas de mantener el estado de las sesiones. Una de los procedimientos más utilizados es el uso de cookies aunque dicho método también deja al descubierto determinados agujeros de seguridad como la persistencia indefinida de ellas. Las conexiones seguras son eficaces contra fisgones pero no con ataques del estilo man-in-the-middle. HTTP sólo protege los datos durante el tránsito, una vez en la máquina de destino, dependerá de la máquina su seguridad XML Qué es XML? XML (siglas en inglés de extensible Markup Language (lenguaje de marcas ampliable), es un metalenguaje extensible de etiquetas desarrollado por el World Wide Web Consortium (W3C). Es una simplificación y adaptación del SGML (Standard Generalized Markup Language o Estándar de Lenguaje de Marcado Generalizado) y permite definir la gramática de lenguajes específicos (de la misma manera que HTML es a su vez un lenguaje definido por SGML). Por lo tanto XML no es realmente un lenguaje en particular, sino una manera de definir lenguajes para diferentes necesidades. Algunos de estos lenguajes que usan XML para su definición son: XHTML, SVG, MathML. XML 1.0 se convirtió en una recomendación del W3C el 10 de febrero de XML no ha nacido sólo para su aplicación en la WWW, sino que se propone como un estándar para el intercambio de información estructurada entre diferentes plataformas. Se puede utilizar en bases de datos, editores de texto, hojas de cálculo y casi cualquier cosa imaginable. Tiene un importante papel en la actualidad ya que permite la compatibilidad entre sistemas para compartir la información de una manera segura, fiable y fácil. Puntos fuertes de XML Se trata de un formato al mismo tiempo legible tanto por los humanos como por las máquinas. Se pueden representar la mayoría de las estructuras de datos generales en el ámbito de la computación científica como los registros, las listas y los árboles. Se permite la validación utilizando lenguajes de esquema (schema) como XSD y Schematron, lo cual permite pruebas unitarias eficientes, pruebas de aceptación en firewalls relativamente sencillas etc.. 26

28 Se trata de archivos de texto sin formato, que son menos restrictivos que otros formatos de documentos con carácter propietario. Permite separar el contenido de la presentación. Es extensible mediante la adición de nuevas etiquetas. El analizador es un componente estándar, no es necesario crear un analizador específico para cada lenguaje. Esto posibilita el empleo de uno de los tantos disponibles. De esta manera se evitan bugs y se acelera el desarrollo de la aplicación. Si un tercero decide usar un documento creado en XML, es sencillo entender su estructura y procesarlo, mejorando la compatibilidad entre aplicaciones. Puntos débiles de XML La sintaxis de XML es redundante o grande en relación a las representaciones binarias de datos similares. La redundancia puede afectar la eficiencia de aplicación aumentando los costes de almacenamiento, transporte y procesamiento. No hay un soporte para tipos de datos intrínsecos: XML no proporciona ninguna noción específica de "entero", "cadena", "booleano", "fecha" etc.. El modelo de representación jerárquico es limitado en comparación con el modelo relacional o un grafo orientado a objetos. Expresar relaciones entre nodos no jerárquicas requiere un esfuerzo adicional. Los espacios de nombres XML pueden ser problemáticos, puede resultar muy difícil implementar correctamente un XML parser. XML es habitualmente taxonomizado como "auto-documentado", pero esta categorización no tiene en cuenta la posibilidad de ambigüedades críticas. 27

29 4. Conceptos sobre Android 4.1 Qué es una plataforma de software? Una plataforma software incluye algún tipo de arquitectura de hardware y un framework (marco/entorno de trabajo) de software (incluidos los frameworks de aplicación). Su combinación permite la ejecución del software. Las plataformas típicas incluyen una arquitectura de computadores, un sistema operativo y unos lenguajes de programación con sus interfaces de usuario asociadas (librerías del sistema en tiempo de ejecución o interfaz gráfica de usuario) [14]. El proveedor de la plataforma ofrece a los desarrolladores de software, una garantía de que el código lógico va a poder ejecutarse de manera consistente, siempre y cuando la plataforma se está ejecutando por encima de otras plataformas. El termino código lógico incluye código de bytes, código fuente y código máquina. Significa que la ejecución del programa no está limitado por el tipo de sistema operativo. Ha reemplazado de manera mayoritaria a los lenguajes independientes de la máquina. Algunas plataformas de software son capaces de emular plataformas hardware completas como en la virtualización. Figura 10: Estructura estratificada de una plataforma software 28

30 Las plataformas son habitualmente referidas a través de las API (funciones y/o métodos que ofrece una biblioteca para ser utilizada por otro software como una capa de abstracción). Un conjunto completo de API constituye una plataforma software. Estas plataformas pueden o no ser dependientes del sistema operativo. Java es un ejemplo de plataforma no dependiente del sistema operativo; puesto que Java es tanto el lenguaje como la plataforma de desarrollo, la cual incluye la Java Virtual Machine (JVM) cuya función es interpretar el código bytecode resultante de la compilación del código fuente del programa en Java. 4.2 Qué es Android? Android es una plataforma (pila) de software y un sistema operativo para dispositivos móviles basada en un kernel (núcleo) Linux, desarrollada por Google y más tarde por la Open Handset Alliance. Permite a los desarrolladores escribir código en lenguaje Java para ser ejecutado en dispositivos móviles mediante las librerías Java desarrolladas por Google. Asimismo es posible escribir aplicaciones en otros lenguajes, como por ejemplo C, para posteriormente ser compiladas en código nativo ARM y ejecutarlas, aunque este proceso de desarrollo no está soportado oficialmente por Google. La mayor parte de la plataforma Android está disponible bajo licencia de software libre de Apache y otras licencias de código abierto Breve historia En Julio del año 2005, Google adquirió Android Inc., una pequeña startup (término utilizado para definir negocios emprendedores con una historia de funcionamiento limitada pero con grandes posibilidades de crecimiento) de California. Durante aquel período, la compañía se dedicaba a la creación de software para teléfonos móviles. Una vez fagocitada por Google, el equipo desarrolló un sistema operativo basado en Linux para dispositivos móviles. Más adelante, Google adaptó su buscador y sus aplicaciones para su uso en smartphones. En septiembre del año 2007, Google atesoraba varias patentes de aplicaciones sobre el área de la telefonía móvil. El 5 de noviembre del mismo año, se anunció la fundación de la Open Handset Alliance al mismo tiempo que la creación de la plataforma Android. La Open Handset Alliance se trata de un consorcio de 34 compañías de hardware, software y telecomunicaciones en las cuales se incluyen Google, HTC, Intel y Motorola entre otras, dedicadas a investigar estándares abiertos para dispositivos móviles. El primer teléfono en el mercado que dispone del sistema operativo Android es el T-Mobile G1 (también conocido como Dream), lanzado el día 22 de octubre de 2008 que viene con la versión Android 1.0 preinstalada. 29

31 Este móvil es el resultado conjunto de T-Mobile, HTC y Google. Por último, desde el 21 de octubre de 2008, Android está disponible como código abierto. Gracias a esto, cualquiera con los conocimientos necesarios puede añadir extensiones, nuevas aplicaciones o reemplazar las existentes por otras dentro del dispositivo móvil Características de Android Diversidad de diseños (VGA, librerías de gráficos 2D y 3D basada en OpenGL, etc). Almacenamiento de tipo estructural en bases de datos SQLite. Conectividad (GSM, EDGE, 3G, Bluetooth y Wi-Fi). Mensajería (SMS y MMS). Navegador integrado basado en el motor open-source WebKit. Máquina virtual de Java. Las aplicaciones escritas en lenguaje Java pueden ser compiladas y ejecutadas en la maquina virtual Dalvik, la cual es una máquina virtual optimizada para emplearla en dispositivos móviles. Soporte de formatos multimedia para audio, video e imágenes (MPEG-4, H.264, MP3, AAC, OGG, AMR, JPEG, PNG, GIF). Soporte para hardware adicional (cámaras de vídeo, pantallas táctiles, GPS, acelerómetros..) Entorno de desarrollo (emulador, herramientas de depuración, perfiles de memoria y funcionamiento, plugin para el IDE Eclipse). 30

32 4.2.3 Arquitectura de Android Figura 11: Arquitectura del sistema operativo Android Imagen extraída de: Los componentes/ingredientes principales de la arquitectura Android son: Aplicaciones Incluye un conjunto de aplicaciones básicas como cliente de correo electrónico, posibilidad de envío de SMS, calendarios, mapas, navegador (browser), gestión de contactos etc.. Todas las aplicaciones están escritas utilizando el lenguaje de programación Java. Framework de aplicaciones Los desarrolladores tienen acceso completo a las API(interfaz de programación de aplicaciones) del framework manejado por las aplicaciones básicas citadas en el párrafo anterior. La arquitectura de aplicación está diseñada para simplificar la reutilización de componentes; cualquier aplicación puede hacer pública sus capacidades y cualquier otra aplicación puede hacer uso de esas capacidades(sujeta a pautas de seguridad del framework como declarar a los tipos de recursos que accede la aplicación). Este mismo mecanismo permite que el usuario pueda reemplazar los 31

33 componentes. Subyacente a cada aplicación hay un conjunto de servicios y sistemas que incluyen: Un extenso conjunto de Views (vistas) que pueden utilizarse para construir una aplicación tales como listas, botones, text boxes, grids e incluso un navegador web integrado. Content Providers (proveedores de contenido) que permiten a las aplicaciones acceder a información de otras aplicaciones (como por ejemplo la aplicación Contacts que gestiona los contactos) o compartir su propia información. Un Resource Manager (gestor de recursos) que proporciona acceso a recursos no programados como gráficos, cadenas de texto (strings) en un idioma específico ó archivos layout (de interacción con el usuario). Un Notification Manager (gestor de notificaciones) que permite a las aplicaciones mostrar mensajes de alerta personalizados en la barra de estado. Un Activity Manager (gestor de actividades) que gestiona el ciclo de vida de las aplicaciones y proporciona una navegación backstack (posibilidad de volver atrás). Libraries El sistema operativo dispone de un catálogo de librerías C/C++ utilizadas por varios componentes del sistema Android. Estas prestaciones se ponen a disposición de los desarrolladores a través del framework de aplicaciones de Android. Algunas de estas librerías son: System C library Media Libraries Surface Manager LibWebCore SGL 3D Libraries FreeType SQLite Android Runtime Incluye un conjunto de librerías básicas que suministran la mayor parte de las funcionalidades disponibles en las librerías core (básicas) del lenguaje de programación Java. Cada aplicación Android se ejecuta en su propio proceso, con su propia instancia de la máquina virtual Dalvik. Dalvik ha sido programada de manera que un dispositivo puede correr múltiples máquinas virtuales (VM) de manera eficiente. La máquina virtual Dalvik ejecuta archivos en el formato Dalvik Executable (.dex), el cual está optimizado para hacer uso de la mínima cantidad de 32

34 memoria posible. Núcleo Linux Android se basa en la versión 2.6 del kernel de Linux para servicios básicos del sistema tales como seguridad, gestión de memoria, gestión de procesos, pila de red y modelo/paradigma de controladores (driver model). El kernel también actúa como una capa de abstracción entre el hardware y el resto de la pila software. 4.3 Android SDK El kit de desarrollo de software (en inglés SDK o Software Development Kit) incluye un conjunto de herramientas de desarrollo: un depurador (debugger), librerías, un emulador (basado en QEMU), documentación, códigos de ejemplo y tutoriales. Está soportado en sistemas operativos Windows, Linux y Mac. El entorno de desarrollo (Integrated Development Environment o IDE) oficialmente soportado es Eclipse conjuntamente con el plugin ADT (Android Development Tools) proporcionado por Google. Desde noviembre del 2007 a junio del 2011 han ido surgiendo nuevas actualizaciones del SDK siendo la última la 3.1, cada una de las cuales soluciona errores de las anteriores o facilita algunos procedimientos y añade funcionalidades a la API. 4.4 Anatomía de una aplicación Android Dentro de una aplicación de Android hay cuatro componentes principales: Activity Listeners Services Content Providers Todas las aplicaciones de Android están formadas por algunos de estos elementos o combinaciones de ellos Activity Las Activities (o actividades) son el componente más común en Android. Para implementarlas se extiende la funcionalidad de una clase base llamada Activity. Cada clase mostrará una interfaz de usuario compuesta por Views (vistas). Cuando se cambie de View, se cambiará de Actividad, como en una aplicación de mensajería instantánea que 33

35 dispone de una View para mostrar la lista de contactos y otra View para escribir los mensajes. Cuando cambiamos de View, la anterior queda pausada y puesta dentro de una pila de historial para poder retornar a ella en caso necesario (concepto de backstack). También se pueden eliminar las Views del historial en caso de no requerirlas más. Para moverse entre Views Android utiliza una clase especial llamada Intent Intents Un Intent es un objeto mensaje que, a grandes rasgos, describe qué quiere hacer una aplicación. 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, la cual se expresa en formato URI (siglas del inglés Uniform Resource Identifier). Un ejemplo puede ser consultar la información de contacto de una persona, la cual mediante un Intent con la acción ver y la URI que representa a esa persona se podría obtener la información deseada. Vinculado a los Intents hay una clase llamada IntentFilter que es una descripción de qué Intents puede una Activity gestionar. Mediante los IntentFilters, el sistema puede resolver Intents, buscando cuales posee cada Activity 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 Activities pueden reutilizar funcionalidades de otros componentes simplemente haciendo peticiones mediante un Intent y pueden ser remplazadas por nuevas Activities con IntentFilters equivalentes Listeners Los Listeners se utilizan para reaccionar a eventos externos (e.g una llamada). Los Listeners no tienen interfaz de usuario pero pueden utilizar el servicio NotificationManager para informar al usuario. Para lanzar un aviso no hace falta que la aplicación se esté ejecutando, en caso necesario, Android la iniciará si se activa el Listeners por algún evento Services Un Service es código que se ejecuta durante largo tiempo y sin necesidad de intervención del usuario. (e.g un gestor de descarga en el cual se indican los contenidos a descargar y después el usuario puede acceder a una nueva View sin que el gestor se interrumpa). En caso de que haya múltiples services simultáneos, es posible indicar diferentes prioridades según las necesidades. 34

36 4.4.4 Content providers Los Content Providers almacenan y recuperan datos (implementando un conjunto estándar de métodos) haciéndolos accesibles a todas las aplicaciones (en ficheros, bases de datos SQLite etc). Son la única manera de intercambiar data entre aplicaciones; no hay un área común de almacenamiento a la cual todos los paquetes (packages) de Android puedan acceder. Android soporta Content Providers para o tipos de dato comunes (audio, vídeo, imágenes, información personal de contacto..) Algunos de ellos están listados en el paquete android.package. En algunos casos para consultar los datos contenidos en los providers se requieren los permisos adecuados Android manifest En todas las aplicaciones Android se encuentra un archivo XML nombrado como AndroidManifest.xml que, pese a no formar parte del código principal de la aplicación, es necesario para su correcto funcionamiento. Este archivo se trata de un fichero de control que declara al sistema qué debe hacer con todos los componentes anteriormente mencionados pertenecientes a una aplicación en concreto. 4.5 Tipos de aplicación Android Un Android Package (.apk) es un fichero que contiene el código de la aplicación y los recursos utilizados; posteriormente se instala en el dispositivo para poder ejecutarse Tareas Una tarea en Android, es aquello que el usuario ve como una aplicación y el desarrollador contempla como una o más Actividades donde el usuario final interacciona y transita entre Views. Dentro de las tareas, una actividad representa el punto de entrada (será la primera en mostrarse cuando se ejecute la aplicación) y las restantes, si las hay, formarán parte de la misma tarea, a la espera de ser instanciadas/solicitadas. 35

37 4.5.2 Procesos Cuando un componente perteneciente a la aplicación se inicia, y la aplicación no tiene ningún otro componente ejecutándose el sistema Android pone en marcha un nuevo proceso Linux para la aplicación con un único hilo de ejecución. Por defecto, todos los componentes de la misma aplicación funcionan en el mismo proceso e hilo (llamado hilo principal/main). Si un componente de la aplicación se pone en marcha y ya existe un proceso para esa aplicación (porque otro componente de la aplicación existe), el componente es iniciado dentro de ese proceso y utiliza el mismo hilo de ejecución. En Android, los procesos se ejecutan a nivel del kernel y el usuario habitualmente no tiene constancia de ellos. Todo el código de la aplicación se suele ejecutar en un proceso dedicado, pero también se puede especificar si sólo se desea ejecutar en el proceso una determinada clase o componente de la aplicación. Los procesos suelen emplearse para: Mejorar la estabilidad y/o seguridad de las aplicaciones. Reducir la sobrecarga de proceso ejecutando el código de múltiples aplicaciones en el mismo proceso. Ayudar al sistema a gestionar los recursos separando partes de código pesado en un proceso separado que puede ser eliminado independientemente de otras partes de la aplicación Threads Android evita la creación de threads adicionales por parte de un proceso, manteniendo la aplicación en un único thread al menos que no los cree la propia aplicación. Esto influye en las llamadas a instancias de Actividades, Listeners y Servicios, ya que sólo pueden ser hechas por el thread principal del proceso en el que están corriendo. Por otro lado, al no crearse un thread por cada instancia, dichas instancias no deben realizar operaciones largas o bloqueantes cuando son llamadas, de lo contrario, bloquearían todos los demás componentes del proceso. 4.6 Ciclo de vida de una aplicación en Android Cada aplicación Android corre en su propio proceso, el cual es creado por la aplicación cuando se ejecuta y permanece hasta que la aplicación deja de trabajar o el sistema requiere memoria para otras aplicaciones. Una característica fundamental de Android es que el ciclo de vida de una aplicación no está controlado por la misma aplicación sino que lo determina el sistema a partir de una combinación de estados como pueden ser qué aplicaciones están funcionando, qué prioridad tienen para el usuario y la cantidad de memoria disponible en el sistema. De esta manera, 36

38 Android sitúa cada proceso en una jerarquía de importancia basada en estados. Proceso en primer plano Un proceso en primer plano es aquel requerido para lo que el usuario está actualmente haciendo. Se considera en primer plano si: Esta ejecutándose una Activity perteneciente a la pantalla con la que el usuario está interactuando. Está ejecutándose un BroadcastReceiver. Esta ejecutándose un Service. Por lo general, sólo unos pocos procesos en primer plano existen en un momento dado. Son eliminados sólo como último recurso si la cantidad de memoria es tan baja que no pueden seguir funcionando todos. Habitualmente llegados a ese punto, la memoria ha alcanzado un estado de paginación por lo que suprimir algunos procesos en primer plano es necesario para mantener la interfaz de usuario con capacidad de respuesta. Proceso visible Un proceso que no tiene ningún componente en primer plano (está pausado), pero puede afectar a aquello que el usuario ve en pantalla mediante una Activity. Este proceso (considerado importante) solo se eliminará para mantener todos procesos ejecutándose en primer plano. Proceso de servicio Es un proceso que está ejecutando un servicio iniciado mediante el método startservice(). Pese a no estar vinculados directamente con aquello que el usuario ve, habitualmente hacen cosas importantes para el usuario (como reproducir música en segundo plano ó descargar datos de la red), así que el sistema los mantiene ejecutándose a menos que no haya suficiente memoria para mantenerlos con todos los procesos visibles y de primer plano. Proceso en segundo plano Un proceso que contiene una Activity que no es visible para el usuario actualmente (se ha llamado al método de la Activity onstop()). Estos procesos no tienen un impacto directo en el usuario final y el sistema puede eliminarlos en cualquier momento para dar memoria a un proceso visible, de servicio, en segundo ó primer plano. 37

39 Proceso vacío Un proceso vacío es aquel que no contiene ningún componente activo de ninguna aplicación. La única razón para mantener dicho proceso es para mejorar sus inicializaciones posteriores a modo de caché. Figura 12: Diagrama de flujo del ciclo de vida de una actividad en Android, mencionando también los métodos que se llaman durante el transcurso del mismo. Imagen extraída de 38

40 4.7 Almacenamiento de datos Android proporciona diversas opciones para almacenar datos de la aplicación. La elección dependerá de necesidades específicas (si los datos deben o no ser accesibles por otras aplicaciones). Los mecanismos de almacenamiento son: Ficheros Pueden guardarse tanto en el propio dispositivo como en dispositivos extraíbles. Shared Preferences Almacenamiento ligero en formato de dupla clave-valor. Útil para guardar preferencias de usuario. Bases de datos Permite crear bases de datos SQLite privadas, accesibles desde el paquete(package) que las creó. Content providers (explicados en párrafos anteriores). Red Uso de la red para almacenar y recuperar datos Imágenes de disco Dentro de la categoría de ficheros, encontramos las imágenes de disco, que Android emplea para poder almacenar datos y diferentes configuraciones, las cuales simulan particiones flash de disco, por ejemplo, una imagen que contenga el kernel del emulador, una imagen para la memoria RAM, datos de usuario y una imagen para simular una tarjeta SD. Por defecto, Android guarda localizaciones predeterminadas para estas imágenes. Durante el arranque, el emulador busca y lee estos ficheros de imágenes. Esta ubicación se puede especificar mediante las opciones de arranque del emulador; si no encuentra ninguna imagen, utiliza las direcciones por defecto. El emulador usa tres tipos de imagen: de sistema, en tiempo de ejecución, y temporales. Las imágenes de sistema contienen datos del sistema y configuraciones por defecto necesarias para que el emulador arranque. Estas imágenes son de sólo lectura, no deben modificarse. Las imágenes en tiempo de ejecución leen y escriben datos. Existen dos tipos: las de datos y las de tarjetas SD emuladas. Cada emulador usa una imagen de datos de usuario para guardar los datos específicos de sesión y usuario, como por ejemplo, las aplicaciones instaladas. Si se usan varias instancias de emuladores al mismo tiempo, solo la primera puede usar datos persistentes si no se especifican ficheros de imagen diferentes en el arranque. Opcionalmente, se pueden crear imágenes de disco que emulen tarjetas SD. 39

41 Solamente se puede cargar una imagen de disco durante la puesta en marcha del emulador. Además una vez cargada una tarjeta SD, no se puede extraer de un emulador en funcionamiento, pero sí navegar por ella y añadir o eliminar archivos. El emulador soporta tarjetas SDHC emuladas por lo que soporta tamaños de hasta 128 gigabytes. Las imágenes temporales se eliminan al apagarse el dispositivo. Estas imágenes son una copia de la imagen de sistema de Android y la imagen de la memoria caché. 4.8 Gráficos Para implementar gráficos 2D y 3D, Android utiliza una librería gráfica personalizada y OpenGL ES (OpenGL for Embedded Systems), una variante simplificada de la API gráfica OpenGL diseñada para dispositivos integrados tales como teléfonos móviles, PDA y consolas de videojuegos. Definida e impulsada por el Grupo Khronos, un consorcio de empresas dedicadas a hardware y software gráfico interesadas en APIs gráficas y multimedia. Existen varias versiones, de entre las cuales la versión 1.0 ha sido seleccionada como la API oficial para gráficos 3D en Android. La API original, OpenGL, es una especificación estándar que define una API multilenguaje y multiplataforma para escribir aplicaciones que produzcan gráficos 2D y 3D. La interfaz se basa en más de 250 funciones diferentes que pueden usarse para dibujar escenas tridimensionales complejas a partir de primitivas geométricas simples, tales como puntos, líneas y triángulos. Fue desarrollada originalmente por Silicon Graphics Inc. (SGI) en 1992 y se usa ampliamente en CAD, realidad virtual, representación científica, visualización de información y simulación de vuelo. También se usa en desarrollo de videojuegos, donde compite con Direct3D en plataformas Microsoft Windows. Los propósitos fundamentales de OpenGL son: Ocultar la complejidad de la interfaz con las diferentes tarjetas gráficas, presentando al programador una API única y uniforme. Ocultar las diferentes capacidades de las diversas plataformas hardware, requiriendo que todas las implementaciones soporten la funcionalidad completa de OpenGL (utilizando emulación software si fuese necesario). 4.9 Direccionamiento en Android Cada instancia del emulador se ejecuta detrás de un router virtual que aísla el emulador de las interfaces de red del PC. Un dispositivo emulado no puede ver el PC u otro emulador de la red. En su lugar, solo ve que está conectado a través de una Ethernet a un router. En todos los emuladores que se están ejecutando son usadas las mismas direcciones, reforzando el aislamiento. Para consultar el espacio de direcciones Android. Este direccionamiento es específico al emulador y que probablemente sea muy diferente en dispositivos reales. 40

42 4.10 Recursos Los recursos en Android son ficheros externos sin código alguno empleados y compilados dentro de la aplicación. Android soporta diferentes tipos de recursos, incluido archivos XML, PNG y JPEG. Los ficheros XML tienen distinto formato dependiendo de qué especifiquen. Los recursos son exteriorizados respecto al código. 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. En general, hay recursos de tres tipos: Ficheros XML, mapas de bits y ficheros raw (e.g, ficheros de sonido). Recursos posibles en Android: Anim Ficheros.xml compilados en objectos de animaciones Drawable Archivos con formato.png.9png y.jpg compilados en un fichero bitmap. Layout Ficheros.xml que se compilan en Views de pantalla. Values Ficheros.xml compilados en varios tipos de recursos, utilizados para definir por ejemplo strings y colores. XML Ficheros.xml arbitrarios que pueden ser compilados y llamados en tiempo de ejecución. Raw Ficheros arbitrarios copiados directamente al dispositivo Herramientas de desarrollo Para poder desarrollar sobre Android hay una serie de herramientas necesarias y unos requisitos que hay que tener en cuenta. Respecto a las herramientas del SDK se dispone de: Android Eclipse Views: El plugin de Android para Eclipse añade un número de vistas para poder depurar la aplicación. Una de las más recomendables y útiles es el LogCat, un visor de logs del dispositivo que puede ser categorizado en cinco clases: 41

43 V: Verbose (Prioridad más baja) D: Debug I: Info W: Warning E: Error F: Fatal S: Silent (Alta prioridad) Consola de emulación: Algunas funciones en tiempo real del emulador, como el envío de SMS, pueden ser simuladas conectando la consola del emulador mediante telnet a localhost y al puerto Android Debug Bridge (ADB): Proporciona acceso a funciones del emulador, incluido el redireccionamiento de puertos y la posibilidad de instalar aplicaciones tanto en el dispositivo como en el emulador con el comando adb install. 42

44 5. Programación con las APIs de Flickr y Youtube en dispositivos Android 5.1 Introducción El propósito fundamental de la aplicación es mostrar al usuario final tanto una colección de fotografías que tenga almacenadas en el portal web Flickr, como una recopilación de videos almacenados en un canal de YouTube o en una tarjeta de memoria SD Card a través de una intuitiva interfaz de usuario. Para llevar a cabo tal tarea se hace uso fundamentalmente del servicio de conexión a la www, con el fin de poder intercambiar información acerca de las fotografías digitales y los videos entre el usuario del dispositivo móvil y el servicio web. Emplearemos tanto la API de datos proporcionada por Flickr como la proporcionada por YouTube para consultar y procesar la información solicitada. Concretamente haremos uso de el formato de petición/respuesta REST para el servicio web Flickr y el formato JSON para el servicio web YouTube Acceso a la API Flickr [13] La API de Flickr está compuesta por un grupo de métodos a los que se puede llamar y algunos endpoints API ( y Para realizar una acción usando la API de Flickr, debe seleccionarse una convención de llamada, enviar una solicitud a su extremo y especificar un método y algunos argumentos. Tras esto se recibirá una respuesta con un formato determinado. Todos los formatos de solicitud (REST, XML-RPC, SOAP) toman una lista de parámetros con nombre. El parámetro obligatorio method se usa para especificar el método de llamada. El parámetro obligatorio api_key se usa para especificar la clave API. El parámetro opcional format se usa para especificar un formato de respuesta. Nota: La API de Flickr expone los identificadores para usuarios, fotos, álbumes de fotos y otros objetos con identificación única. Estos ID siempre deben tratarse como cadenas opacas, en vez de enteros de un tipo específico. Además, el formato de los ID puede cambiar con el tiempo. 43

45 Codificación La API de Flickr espera que todos los datos tengan una codificación UTF-8. Se realizan controles para verificar que las secuencias UTF-8 sean válidas. Si se detecta una secuencia no válida, se supone que los datos son ISO y se convierten a UTF-8. Si se envían datos en cualquier otra codificación, se generará basura en Flickr. No será basura peligrosa (siempre se guardarán datos UTF-8 válidos), pero seguirá siendo basura. Autenticación de usuarios Para muchos métodos es necesario que el usuario haya iniciado sesión. Actualmente, sólo hay una forma para hacerlo. Los usuarios deben ser autenticados usando la API de autenticación. Los parámetros auth_token y api_sig deben pasarse con cada solicitud. Configuración de la clave API obtenida Una vez que te hayan emitido una clave, ésta aparecerá en una dirección URL de la forma A continuación es necesario hacer clic en el enlace denominado 'No configurada' de tu clave para iniciar el proceso de configuración. Los campos Título y Descripción son obligatorios para todas las aplicaciones; el Logotipo es opcional. La URL de la aplicación debe dirigir a una página en tu sitio Web que describa tu aplicación, pero también es opcional. Estos cuatro campos se usan al preguntar a un usuario si desea permitir que la aplicación desarrollada los autentique. A continuación seleccionar Aplicación móvil para Tipo de autenticación en este caso. Luego hay que elegir un nivel de permiso para la aplicación. Las opciones son las siguientes: read: permiso para leer información privada. write: permiso para agregar, editar y eliminar metadatos de fotos(incluye 'read'). delete: permiso para eliminar fotos (incluye 'write' y 'read'). Es preciso tomar nota de tu dirección URL de autenticación (debe aparecer debajo de la configuración de permisos). Debería tener un aspecto similar a éste: Fechas de las fotos Cada foto en Flickr tiene dos fechas: la fecha en que se tomó y la fecha en que se publicó. 44

46 Fechas en que se tomaron La fecha en que se tomó representa el momento en que se obtuvo la foto. Ésta se extrae de los datos EXIF si están disponibles, si no se configura con la fecha de carga. La fecha en que se tomó siempre se pasa en formato MySQL de 'fecha y hora' (tanto para obtener fechas de y establecer fechas a través de la API), que tiene el siguiente aspecto, por ejemplo: :01:26 Especifica 29 de noviembre de 2004 a las 4:01:26 p.m. Es posible excluir la información que desees de la fecha y se completará según sea necesario, e.g: = :00:00 La fecha en que se tomó siempre deberá aparecer en la zona horaria del dueño de la foto, que es lo mismo que decir que no se debe realizar ningún tipo de conversión. Las fechas en que se tomaron también tienen un 'nivel de detalle': la precisión con la conocemos la fecha. Actualmente, se usan los siguientes niveles de detalle: 0 Y-m-d H:i:s 4 Y-m 6 Y 8 Cerca de.. Por lo tanto, una foto que se tomó en algún momento en junio de 1980, tendría una fecha en que se tomó de :00:00 y un nivel de detalle de 4. En el futuro, podrán agregarse niveles de detalle adicionales, por lo que, para mantener la compatibilidad, se puede crear una aplicación para que acepte niveles de detalle entre 0 y 10. Fechas en que se publicaron Este será uno de los dos parámetros mostrados en la sección de la aplicación relacionada con las fotografías. La fecha en que se publicó representa el momento en que se cargó la foto en Flickr. Ésta se establece en el momento de la carga. La fecha en que se publicó siempre se pasa como una marca de fecha y hora de Unix (timestamp), que es un entero no firmado que especifica la cantidad de segundos desde el 1 de enero de 1970 GMT. Todas las fechas en que se tomaron se pasan en GMT y el proveedor de la aplicación debe darles formato usando la zona horaria del usuario correspondiente. 45

47 Etiquetas de fotos Una foto puede tener cero etiquetas o más. Cada etiqueta tiene un conjunto de campos que puedes usar: <tag id = "1234" author = " @N01" raw = "woo yay">wooyay</tag> id author raw tag-body El ID. único para esta etiqueta en esta foto. Puede usarse al eliminar una sola etiqueta usando el método flickr.photos.removetag El NSID (identificador de servicios de nombres) del usuario que agregó la etiqueta. Puede no ser el mismo NSID que el del dueño de la foto. La versión 'sin procesar' de la etiqueta, como la ingresó el usuario. Esta versión puede incluir espacios y puntuación. La versión 'limpia' de la etiqueta, como la procesó Flickr. Esta versión se usa para crear direcciones URL. Direcciones URL de origen de fotos Se puede crear la URL de origen a una foto una vez que se sepa su ID, el ID del servidor, el ID del conjunto de servidores y el secreto, según lo indicado por muchos métodos API. La URL toma el siguiente formato: gif png) Sufijos de tamaño Los sufijos de letras son los siguientes: s t m z cuadrado pequeño 75x75 imagen en miniatura, 100 en el lado más largo pequeño, 240 en el lado más largo - mediano, 500 en el lado más largo b o mediano, 640 en el lado más largo grande, 1024 en el lado más largo* imagen original, ya sea jpg, gif o png, según el formato de origen * Antes del 25 de mayo de 2010, las fotos grandes sólo existían para imágenes originales muy grandes. 46

48 Nota: Las fotos originales se comportan de una manera un poco diferente. Tienen su propio secreto (llamado originalsecret en las respuestas) y una extensión de archivo variable (llamada originalformat en las respuestas). Estos valores se obtienen a través de la API sólo cuando el que llama tiene permiso para ver el tamaño original (según la preferencia de un usuario y varios otros criterios). Estos valores se obtienen a través del método flickr.photos.getinfo y mediante cualquier método que devuelva una lista de fotos y dé un parámetro extras (con un valor de original_format), como flickr.photos.search. Como siempre, el método flickr.photosgetsizes devolverá la URL original completa cuando se tengan los permisos necesarios. Ejemplo: Direcciones URL de páginas Web farm-id 1 server-id 2 photo-id secret size 1e Las direcciones URL a páginas de fotos y perfiles usan el NSID del usuario (el número con el símbolo '@') o su URL personalizada (si es que eligieron una). Se puede encontrar tu URL personalizada invocando a flickr.people.getinfo. La versión de NSID de la URL funcionará siempre, independientemente de si se configuró una URL 'limpia', de modo que pueda evitarse la llamada API simplemente al usar el ID de usuario que devuelven la mayoría de las llamadas API de fotos. Luego, es posible crear fácilmente direcciones URL a perfiles, galería, fotos individuales o álbumes de fotos. - profile - photostream - individual photo - all photosets - single photoset Se pueden crear otras direcciones URL de manera similar. Al dirigir a un usuario a: o se reemplazará el 'me' con el propio ID de usuario, si se ha iniciado sesión (de lo contrario, lo redirigirá a la última página de foto). m 47

49 Ejemplos: URL cortas Flickr proporciona un servicio que permite acortar las URL para cargar fotos (y videos). Las URL cortas pueden ser útiles en una gran diversidad de contextos, entre ellos: correos electrónicos, tarjetas comerciales, mensajes instantáneos, mensajes de texto o actualizaciones de estado cortas. Cada foto en Flickr tiene una URL corta calculada matemáticamente de la forma: Base58 se usa para comprimir los ID de foto mediante una mezcla de letras y números. Iconos Todos los usuarios de Flickr tienen un icono de 48x48 píxeles que usan para representarse a sí mismos. Hay que arrastrar y colocar tus fotos en un mapa (usando el Organizr) para mostrar dónde fueron tomadas, o explorar el mapa del mundo para ver dónde han estado los demás y qué han visto. Si el servidor de iconos tiene un valor mayor que cero, la URL toma el siguiente formato: en caso contrario, debe usarse la siguiente URL: Carga de fotos Ésta es la especificación para crear aplicaciones de carga de fotos. Funciona fuera del marco normal de la API de Flickr ya que implica enviar archivos binarios. Las aplicaciones de carga pueden llamar al método flickr.people.getuploadstatus en la API normal, a fin de obtener límites de archivos y ancho de banda para el usuario. 48

50 Carga Las fotos deben publicarse mediante POST en la siguiente URL: Autenticación Este método requiere autenticación con permiso 'write' (de escritura). Hay que tener en cuenta que el parámetro 'photo' (foto) no debe estar incluido en la firma. Todos los otros parámetros POST deberán incluirse al generar la firma. Argumentos photo title (opcional) description (opcional) tags (opcional) is_public, is_friend, is_family (opcionales) El archivo que se va a cargar El título de la foto Una descripción de la foto. Puede incluir código HTML pero con ciertas limitaciones Una lista de etiquetas separadas por espacios para aplicar a la foto Configurado en 0 para no, 1 para sí. Especifica quiénes pueden ver la foto safety_level (opcional) Configura 1 para seguro, 2 para moderado o 3 para restringido. content_type (opcional) Configura 1 para foto, 2 para pantallazo o 3 para otros hidden (opcional) Configura a 1 para mantener la foto dentro de los resultados globales de búsqueda, 2 para ocultarla de búsquedas públicas Respuesta de ejemplo Cuando una carga se realiza correctamente, se obtiene el siguiente.xml: <photoid>1234</photoid> photoid es el ID de la foto nueva. Esta respuesta tiene un formato al estilo de una respuesta API REST. 49

51 Códigos de error Si la carga no se realiza correctamente, se obtiene una respuesta de error API REST. Los posibles códigos de error son los siguientes: No photo specified Falta el argumento requerido photo General upload failure El fichero no se subió correctamente Filesize was zero El tamaño del fichero es cero Filetype was not recognised El fichero tiene un formato de imagen desconocido User exceeded upload limit El usuario ha excedido su limite mensual de uso de ancho de banda Invalid signature La firma enviada no es válida Missing signature La llamada requiere una firma pero ésta no fue enviada Login failed / Invalid auth token Los detalles de login o el parámetro auth_token pasados no son válidos User not logged in / Insufficient permissions El método requiere autenticación de usuario pero el usuario no se logueó o la llamada al método autenticado no tenía los permisos requeridos Invalid API Key La clave API pasada no es válida o ha expirado Service currently unavailable El servicio solicitado no está disponible temporalmente Bad URL found Uno o más argumentos contenidos en la URL se han utilizado de manera inadecuada en Flickr Redireccionamiento Cuando se haya cargado un album de fotos, dirige al usuario a esta URL: donde 1,2,3 es una lista separada por comas de los ID de las cargas realizadas anteriormente. 50

52 Reemplazo de fotos Ésta es la especificación para reemplazar fotografías que ya se han cargado en Flickr. Al igual que la API de carga funciona fuera del marco normal de la API de Flickr, ya que implica enviar archivos binarios. Las aplicaciones de carga pueden llamar al método flickr.people.getuploadstatus en la API normal, a fin de obtener límites de archivos y ancho de banda para el usuario. Carga Las fotos deben publicarse mediante POST en la siguiente URL: Autenticación Este método requiere autenticación con permiso 'write' (de escritura). Argumentos photo photo_id async (opcional) El archivo que se va a cargar El ID de la foto que se va a reemplazar Para las aplicaciones que no desean esperar a que se termine una carga, las fotos pueden reemplazarse en modo asíncrono, al dejar una conexión de socket abierta todo el tiempo. Se recomienda procesar fotos de manera asíncrona. Respuesta de ejemplo Cuando una carga se realiza correctamente, se obtiene el siguiente.xml: <photoid secret = "abcdef" originalsecret = "abcdef">1234</photoid> photoid es el ID de la foto que se está reemplazando. Esta respuesta tiene un formato al estilo de una respuesta API REST. 51

53 Códigos de error Si la carga no se realiza correctamente, se obtiene una respuesta de error API REST. Los posibles códigos de error son los siguientes: Not a pro account El usuario debe poseer una cuenta pro No photo specified Falta el argumento requerido photo General upload failure El fichero no se subió correctamente Filesize was zero El tamaño del fichero es cero Filetype was not recognised El fichero tiene un formato de imagen desconocido User exceeded upload limit El usuario ha excedido su limite mensual de uso de ancho de banda Invalid signature La firma enviada no es válida Missing signature La llamada requiere una firma pero ésta no fue enviada Login failed / Invalid auth token Los detalles de login o el parámetro auth_token pasados no son válidos User not logged in / Insufficient permissions El método requiere autenticación de usuario pero el usuario no se logueó o la llamada al método autenticado no tenía los permisos requeridos Invalid API Key La clave API pasada no es válida o ha expirado Service currently unavailable El servicio solicitado no está disponible temporalmente Bad URL found Uno o más argumentos contenidos en la URL se han utilizado de manera inadecuada en Flickr 52

54 Formato de solicitud REST REST es el formato de solicitud más simple que se puede usar; es una simple acción GET o POST HTTP. La URL de extremo REST es: Para solicitar el servicio flickr.test.echo, haz la siguiente llamada: De manera predeterminada, las solicitudes REST envían una respuesta REST. Este será el formato utilizado por la aplicación. Formato de respuesta REST REST es el formato de respuesta más simple que puedes usar; es un bloque.xml simple. Para obtener la respuesta en formato REST, envía un parámetro "format" (formato) en la solicitud con un valor de "rest". Cuando se usa el método de solicitud REST, la respuesta tiene el valor predeterminado de REST. Una llamada a un método devuelve esto: <?xml version = "1.0" encoding = "utf-8"?> <rsp stat = "ok"> [xml-payload-here] </rsp> Si se produce un error, se obtiene lo siguiente: <?xml version = "1.0" encoding = "utf-8"?> <rsp stat = "fail"> <err code = "[error-code]" msg = "[error-message]" /> </rsp> Formato de solicitud XML-RPC Las solicitudes XML-RPC son datos.xml con formato especial que se publican en una URL. La URL extrema de servidor XML-RPC es: 53

55 Para solicitar el servicio flickr.test.echo, envía una solicitud de la siguiente manera: <methodcall> <methodname>flickr.test.echo</methodname> <params> <param> <value> <struct> <member> <name>name</name> <value><string>value</string></value> </member> <member> <name>name2</name> <value><string>value2</string></value> </member> </struct> </value> </param> </params> </methodcall> Hay que tener en cuenta que el nombre del método se envía aparte de los otros parámetros de solicitud. Si se especifica un parámetro, debe ser un único miembro struct con el formato de arriba. De manera predeterminada, las solicitudes XML-RPC envían una respuesta XML-RPC. Formato de respuesta XML-RPC Para obtener la respuesta en formato XML-RPC, envía un parámetro "format" (formato) en la solicitud con un valor de "xmlrpc". Una llamada simple al servicio de eco devuelve esto: 54

56 <?xml version="1.0" encoding="utf-8"?> <methodresponse> <params> <param> <value> <string> [escaped-xml-payload] </string> </value> </param> </params> </methodresponse> Si se produce un error, se obtiene lo siguiente: <?xml version="1.0" encoding="utf-8"?> <methodresponse> <fault> <value> <struct> <member> <name>faultcode</name> <value><int>[error-code]</int></value> </member> <member> <name>faultstring</name> <value><string>[error-message]</string></value> </member> </struct> </value> </fault> </methodresponse> 55

57 Formato de solicitud SOAP Las solicitudes SOAP son "sobres" de datos.xml con formato especial que se publican en una URL. La URL extrema de servidor SOAP es Para solicitar el servicio flickr.test.echo, envía un sobre de la siguiente manera: <s:envelope xmlns:s = " xmlns:xsi = " xmlns:xsd = " <s:body> <x:flickrrequest xmlns:x = "urn:flickr"> <method>flickr.test.echo</method> <name>value</name> </x:flickrrequest> </s:body> </s:envelope> El primer elemento dentro del cuerpo debe ser un elemento FlickrRequest. Cada parámetro de solicitud debe ser un único elemento secundario del elemento FlickrRequest. El nombre del elemento es el nombre del parámetro y su contenido es el valor. De manera predeterminada, las solicitudes SOAP envían una respuesta SOAP. Formato de respuesta SOAP Para obtener la respuesta en formato SOAP, envía un parámetro "format" (formato) en la solicitud con un valor de "soap". Una llamada simple al servicio de eco devuelve esto: <?xml version = "1.0" encoding = "utf-8"?> <s:envelope xmlns:s = " xmlns:xsi = " xmlns:xsd = " <s:body> <x:flickrresponse xmlns:x = "urn:flickr"> [escaped-xml-payload] </x:flickrresponse> </s:body> </s:envelope> 56

58 Si se produce un error, se obtiene lo siguiente: <?xml version = "1.0" encoding = "utf-8"?> <s:envelope xmlns:s = " <s:body> <s:fault> <faultcode>flickr.error.[error-code]</faultcode> <faultstring>[error-message]</faultstring> <faultactor> </faultactor> <details> Please see for more details </details> </s:fault> </s:body> </s:envelope> Formato de respuesta SOAP alternativo Al especificar un valor de formato de "soap2", Flickr puede devolver respuestas APIs como.xml sin escape, con lo que se coloca la respuesta directamente dentro del sobre al establecer el espacio de nombres de la respuesta. La respuesta de error es idéntica, pero la respuesta correcta es la siguiente: <?xml version="1.0" encoding="utf-8"?> <s:envelope xmlns:s = " <s:body> <FlickrResponse xmlns = " [xml-payload] </FlickrResponse> </s:body> </s:envelope> Este tipo de respuesta es nuevo y está en etapa de experimentación y puede no estar admitido en versiones futuras. 57

59 Formato de respuesta JSON JSON, o JavaScript Object Notation (notación de objetos de JavaScript), es un formato simple de intercambio de datos legibles por las máquinas, que facilita la creación de aplicaciones API en JavaScript (aunque también puede usarse con otros lenguajes). Para obtener una respuesta API en formato JSON, envía un parámetro "format" en la solicitud con un valor de "json". Representación de objetos Para convertir XML REST de Flickr en objetos JSON se usan algunas reglas simples. Algunos ejemplos lo muestran mejor. Se convertirá una sola etiqueta a JSON de la siguiente manera: <foo bar="baz" /> { } "foo": { "bar": "baz" } Cada elemento está representado por un objeto JSON. Los atributos de los elementos están representados por un miembro del objeto con un valor de cadena. Los elementos secundarios están representados por un miembro del objeto con un valor del objeto. <foo bar="baz"> <woo yay="hoopla" /> </foo> { } "foo": { "bar": "baz", "woo": { "yay": "hoopla" } } Los nodos de texto de los elementos están representados como si fueran un atributo, con el nombre especial "_content": 58

60 <foo> texto aquí!</foo> { "foo": { "_content": " texto aquí!" } } Para los elementos repetidos (como el elemento <photo> cuando se busca una lista de fotos), se usa una matriz como el valor del miembro del objeto (la clave del miembro representa el nombre del elemento). Cada valor en la matriz es un objeto que representa a un elemento secundario. <outer> <photo id = "1" /> <photo id = "2" /> </outer> { } "outer": { "photo": [ { } ] }, { } "id": "1" "id": "2" Respuestas correctas Cuando una solicitud se realiza correctamente, se obtiene el siguiente JSON: jsonflickrapi({...}); El simple objeto aprobado en la demanda de la función representa el elemento REST externo <rsp>. El elemento de raíz de la respuesta REST será el miembro de este objeto (también lo es el parámetro de estadística - revísalo para ver si la demanda es exitosa). Por ejemplo, flickr.blogs.getlist tiene una respuesta documentada como se muestra a continuación: 59

61 <blogs> <blog id = "73" name = "Bloxus test" needspassword = "0" url = " /> <blog id = "74" name = "Manila Test" needspassword = "1" url = " /> </blogs> Y el equivalente en JSON de Flickr sería: jsonflickrapi({ }) "stat": "ok", "blogs": { "blog": [ { "id" : "73", "name" : "Bloxus test", "needspassword" : "0", } ] "url" : " }, { "id" : "74", "name" : "Manila Test", "needspassword" : "1", "url" :" } En JavaScript, la visualización de una lista de los blogs de un usuario es directa: 60

62 function jsonflickrapi(rsp) { if (rsp.stat!= "ok") { // algo fue mal! return; } for (var i=0; i<rsp.blogs.blog.length; i++) { var blog = rsp.blogs.blog[i]; var div = document.createelement('div'); var txt = document.createtextnode(blog.name); div.appendchild(txt); document.body.appendchild(div); } } Respuestas incorrectas Las respuestas incorrectas también llaman al método jsonflickrapi(), pero con un objeto JSON diferente. El objeto no está estructurado como las respuestas incorrectas REST; en cambio, para JSON está simplificado. Por ejemplo: jsonflickrapi({ }) "stat" : "fail", "code" : "97", "message" : "Missing signature" En JavaScript, puedes comprobar el error de rsp.stat y luego leerlo en rsp.code y rsp.message. Función de devolución de llamada Si sólo quieres el JSON sin procesar, sin las funciones, agrega el parámetro nojsoncallback con un valor de 1 a tu solicitud. Para definir tu propio nombre de función de devolución de llamada, agrega el parámetro jsoncallback con el nombre que desees como el valor. Nojsoncallback = 1 { } jsoncallback = wooyay wooyay({...}); 61

63 Representación de los contactos en memoria Para cada contacto, la aplicación necesita conocer los siguientes datos: nombre de usuario, nombre real, NSID, buddy icon, y fecha de su última actualización. Toda esta información se obtiene desde dos fuentes diferentes: el servidor o la base de datos SQLite Acceso a la API de datos de YouTube [14] Parámetros de consulta En esta sección se explica cómo utilizar el API para recuperar una lista de vídeos que coincida con un término de búsqueda especificado por el usuario. Para buscar vídeos, se requiere envíar una solicitud GET HTTP a la siguiente URL, en la que se incluyan los parámetros de consulta apropiados para tu solicitud: Esta página contiene los parámetros estándar del API de datos de Google y los parámetros personalizados que admite el API de YouTube. Por ejemplo, una solicitud enviada a la siguiente URL buscará el segundo conjunto de 10 vídeos subidos recientemente que coincidan con el término de consulta "football", pero no con "soccer": q=football+-soccer &orderby=published &start-index=11 &max-results=10 &v=2 Parámetros de consulta estándar del API de datos de Google El API de datos de YouTube admite los siguientes parámetros de consulta estándar de Google Data. alt El parámetro alt permite especificar el formato del feed que va a devolver. Los valores válidos de este parámetro son atom, rss, json y json-in-script. El valor predeterminado es atom. Si estableces el valor de este parámetro en json-in-script, también deberás establecer el valor del parámetro callback para identificar la función de devolución de llamada a la que se enviará la respuesta de API. 62

64 author En una solicitud de búsqueda, el parámetro author restringe la búsqueda a vídeos subidos por un usuario de YouTube determinado. Ten en cuenta que si utilizas este parámetro al solicitar un feed estándar, YouTube recuperará el feed estándar y, a continuación, filtrará la respuesta para incluir únicamente vídeos subidos por el autor especificado. Por ejemplo, si solicitas el feed "Top Rated" del usuario GoogleDevelopers, el API recuperará el feed de vídeos más valorados y devolverá una respuesta con los vídeos del feed que haya subido el usuario GoogleDevelopers. El API no devolverá una lista de los vídeos del usuario ordenados por puntuación. En una solicitud de un feed de actividad del usuario, el parámetro author contiene una lista de hasta 20 nombres de usuario de YouTube separados por una coma. La respuesta del API contiene las actividades realizadas por cualquiera de los usuarios de la lista. callback El parámetro callback, que se utiliza únicamente si el valor del parámetro alt es json-in-script, identifica la función de devolución de llamada a la que se enviará la respuesta del API. max-results El parámetro max-results especifica el número máximo de resultados que se deben incluir en el conjunto de resultados. Este parámetro funciona junto con el parámetro start-index para determinar qué resultados se deben devolver. Por ejemplo, para solicitar el segundo conjunto de 10 resultados (es decir, los resultados del 11 al 20) establece el parámetro max-results en 10 y el parámetro start-index en 11. El valor predeterminado de este parámetro es 25 y el valor máximo es 50. Sin embargo, para mostrar listas de vídeos, te recomendamos que establezcas el parámetro max-results en 10. prettyprint El parámetro prettyprint permite solicitar una respuesta XML con formato que incluya sangrías y saltos de línea. Para que la respuesta tenga ese formato, establece el valor del parámetro en true. El valor predeterminado del parámetro es false. start-index El parámetro start-index permite especificar el índice del primer resultado relevante que se deberá incluir en el conjunto de resultados. Este parámetro utiliza un índice de base uno, lo que significa que el primer resultado es 1, el segundo es 2 y así sucesivamente. Este parámetro funciona junto con el parámetro max-results para determinar qué resultados se deben devolver. Por ejemplo, para solicitar el segundo conjunto de 10 resultados (es decir, los resultados del 11 al 20), establece el parámetro start-index en 11 y el parámetro max-results en

65 strict Se puede utilizar el parámetro strict para ordenar a YouTube que rechace una solicitud del API en caso de que dicha solicitud incluya parámetros de solicitud no válidos. El API ignora de manera predeterminada los parámetros de solicitud no válidos. Si quieres que YouTube rechace las solicitudes del API que incluyen parámetros no válidos, establece el parámetro strict con el valor true. Por ejemplo, YouTube rechazaría la siguiente solicitud porque "foo" no es un parámetro de solicitud válido. v El parámetro v especifica la versión del API que YouTube debe utilizar para procesar la solicitud del API. Para especificar la versión del API deseada, tu solicitud puede utilizar el parámetro v o el encabezado de solicitud HTTP GData- Version. Las bibliotecas cliente proporcionadas por Google siempre seleccionan una versión superior del API. Si tu solicitud no especifica la versión del API, YouTube procesará la solicitud con la versión 1 del API. Parámetros de consulta personalizados del API de datos de YouTube Además de los parámetros de consulta de Google Data, el API de datos de YouTube define los siguientes parámetros de consulta específicos del API: Parámetros para todas las solicitudes del API: client key Parámetros de búsqueda: caption category format location location-radius lr orderby q safesearch time uploader Parámetros adicionales para todos los feeds de vídeo: restriction 64

66 En general, los parámetros que se utilizan para filtrar y para ordenar resultados solamente son compatibles con las solicitudes de búsqueda. No obstante, el API también es compatible con el parámetro time para muchos feeds estándar, con el parámetro author para los feeds de actividad del usuario y con el parámetro restriction para los feeds de vídeo. Para obtener información sobre cómo filtrar los feeds de respuesta del API que no son compatibles con estos parámetros. A continuación se define cada uno de estos parámetros: caption El parámetro caption, que se especifica sin ningún valor, restringe la búsqueda a los vídeos que tienen pistas de subtítulos. El ejemplo que aparece a continuación muestra cómo solicitar vídeos que tienen subtítulos y que coinciden con el término de búsqueda "surfing": Si se incluye un valor en el parámetro, el API devolverá una respuesta HTTP 400. category El parámetro category te permite recuperar vídeos que están en una categoría en concreto o que están etiquetados con una palabra clave o con una etiqueta de desarrollador determinada. También puedes insertar nombres de categorías, palabras clave y etiquetas de desarrollador en la solicitud URL, tal y como se describe la secciónnavegación con categorías y con palabras clave. Esta sección proporciona instrucciones sobre cómo formatear el valor del parámetro category para diferentes tipos de consultas. client El parámetro client es una cadena alfanumérica que identifica tu aplicación. El parámetro client constituye una forma alternativa de especificar tu ID de cliente. También puedes usar el encabezado de solicitud X-GData-Client para especificar tu ID de cliente. Tu aplicación no necesita especificar tu ID de cliente dos veces al utilizar a la vez el parámetro client y el encabezado de solicitud X-GData-Client, pero deberá proporcionar tu ID de cliente mediante al menos uno de estos dos métodos. format El parámetro format permite especificar en qué formato en concreto deben estar disponibles los vídeos. Tu solicitud podrá especificar cualquiera de los formatos siguientes: 65

67 Valor Formato de video URL de streaming RTSP para la reproducción de vídeos en dispositivos móviles. Vídeo H.263 (hasta 176x144) y audio AMR. URL HTTP en el reproductor insertable (SWF) de este vídeo. Este formato no está disponible para los vídeos que no se pueden insertar. Los desarrolladores suelen agregar &format=5 a sus consultas para restringir los resultados a los vídeos que se pueden insertar en sus sitios. URL de streaming RTSP para la reproducción de vídeos en dispositivos móviles. Vídeo MPEG-4 SP (hasta 176x144) y audio AAC. YouTube admite este parámetro para las solicitudes de búsqueda de vídeos. key El parámetro key especifica la clave del desarrollador, una cadena alfanumérica que identifica al desarrollador o a la compañía que realiza la solicitud del API. También se puede utilizar el encabezado de solicitud X-GData-Key para especificar la clave de desarrollador. La aplicación no necesita especificar la clave de desarrollador dos veces al utilizar a la vez el parámetro key y el encabezado de solicitud X-GData-Key, pero deberá proporcionarla mediante al menos uno de estos dos métodos. location El parámetro location limita la búsqueda a vídeos que tengan una ubicación geográfica especificada en sus metadatos. Se puede usar este parámetro en cualquiera de los siguientes contextos: El valor del parámetro puede especificar coordenadas geográficas (latitud,longitud) que identifiquen una ubicación en concreto. En este contexto, el parámetro location funciona junto con el parámetro location-radius para definir un área geográfica. La respuesta del API contendrá los vídeos que estén asociados a una ubicación geográfica incluida en esta área. Hay que tener en cuenta que, cuando un usuario sube un vídeo a YouTube, puede asociarle una ubicación mediante coordenadas geográficas ( , ) o mediante una dirección descriptiva (Múnich, Alemania). Algunos vídeos se pueden asociar a una ubicación incluida en una zona especificada en una consulta de búsqueda aunque no estén asociados a unas coordenadas específicas que se puedan 66

68 señalar en un mapa. Para excluir vídeos de la respuesta del API, en el caso de que dichos vídeos estén asociados a una dirección descriptiva y no tengan unas coordenadas geográficas específicas, añadir un punto de exclamación ("!") al final del valor del parámetro. Este método garantiza de forma eficaz que la ubicación de todos los vídeos de la respuesta del API puedan marcarse en un mapa. Los siguientes ejemplos muestran posibles usos de este parámetro: location= , &location-radius=100km location= , !&location-radius=100km En una respuesta del API, las entradas de los feeds que estén asociadas a unas coordenadas específicas contendrán la etiqueta <georss:where> y también podrán contener la etiqueta <yt:location>. Las entradas de los feeds que estén asociadas a una dirección descriptiva, no a unas coordenadas geográficas, especificarán la dirección con la etiqueta <yt:location>. El valor del parámetro puede estar vacío o incluir solamente un signo de exclamación. En este contexto, el parámetro no necesita ningún valor. Su presencia sirve para limitar los resultados de búsqueda a los vídeos que tengan una ubicación geográfica, pero no te permite encontrar vídeos con una ubicación geográfica específica. Se puede utilizar este parámetro con todos los feeds de vídeo. Un vídeo con ubicación geográfica contendrá la etiqueta <georss:where> en sus metadatos. YouTube admite este parámetro para las solicitudes de búsqueda de vídeos. location-radius El parámetro location-radius en combinación con el parámetro location define un área geográfica. Si las coordenadas geográficas asociadas a un vídeo aparecen dentro de esta área, el vídeo podrá aparecer en los resultados de búsqueda. El valor del parámetro location-radius debe ser un número de punto flotante seguido de una unidad de medida. Las unidades de medidas válidas son m, km, ft y mi. Por ejemplo, para este parámetro son válidos los valores "1500m", "5km", "10000ft" y "0.75mi". Si el radio es superior a kilómetros, el API devolverá un error. YouTube admite este parámetro para las solicitudes de búsqueda de vídeos. lr En una solicitud de búsqueda de vídeos, el parámetro lr limita la búsqueda a vídeos que contengan título, descripción o palabras clave en un idioma específico. Se puede utilizar este parámetro cuando se solicite cualquier feed de vídeo que no sea un feed estándar. En una solicitud para recuperar una lista de pistas de subtítulos disponibles para un vídeo, el parámetro lr filtra la lista de pistas de subtítulos para que solamente incluya el idioma determinado. 67

69 Los valores válidos del parámetro lr son los códigos de idioma de dos letras ISO También se puede utilizar los valores zh-hans para chino simplificado y zh-hant para chino tradicional. orderby El parámetro orderby, que solamente se admite en los feeds de vídeo, especifica el valor que se utilizará para clasificar los vídeos en los resultados de búsqueda. Los valores válidos de este parámetro son relevance (relevancia), published (publicados), viewcount (volumen de reproducciones) y rating (valoración). Además, se pueden solicitar los resultados más relevantes para un idioma en particular al establecer el valor del parámetro como relevance_lang_languagecode, donde languagecode es un código de idioma de dos letras ISO (Utiliza los valores zh-hans para chino simplificado y zh-hant para chino tradicional). Hay que tener en cuenta que se seguirán devolviendo resultados en otros idiomas si estos presentan un alto nivel de relevancia con respecto al término de consulta de la búsqueda. El valor predeterminado de este parámetro es relevance para un feed de resultados de búsqueda. Nota: en el caso de un feed de lista de reproducción, el orden predeterminado se basa en la posición de cada vídeo en la lista de reproducción. En el caso de un feed de listas de reproducción o de suscripciones de un usuario, el orden predeterminado es arbitrario. YouTube admite este parámetro para las solicitudes de búsqueda de vídeos. q El parámetro q especifica un término de consulta de búsqueda. YouTube buscará todos los metadatos de los vídeos que coincidan con el término. Los metadatos de los vídeos incluyen títulos, palabras clave, descripciones, nombres de usuario de los autores y categorías. Hay que tener en consideración que a todos los espacios, a las comillas y a otros signos de puntuación del valor del parámetro se les debe aplicar un formato de escape URL. Para buscar una frase exacta, escribe la frase entre comillas dobles. Por ejemplo, para buscar vídeos que coincidan con la frase "avión espía", establece el parámetro q como %22avión+espía%22. 68

70 La solicitud también puede utilizar los operadores booleanos NOT (-) y OR ( ) para excluir vídeos o para buscar vídeos asociados a uno de los términos de búsqueda. Por ejemplo, para buscar vídeos que coincidan con "náutica" o con "navegación", establecer el parámetro q como náutica%7cnavegación. (Tener en cuenta que al carácter de barra vertical se le debe aplicar un formato de escape URL). De forma similar, para buscar vídeos que coincidan con "náutica" o "navegación" pero no con "pesca", establecer el parámetro q como "náutica&7cnavegación+-pesca". restriction El parámetro restriction identifica la dirección IP que se debe utilizar para filtrar vídeos que solamente se pueden reproducir en países específicos. Te recomendamos que utilices siempre este parámetro para especificar la dirección IP del usuario final. (De forma predeterminada, el API excluye los vídeos que no se pueden reproducir en el país desde el que se envían las solicitudes del API. Esta restricción se basa en la dirección IP de tu aplicación). Para solicitar vídeos que se puedan reproducir desde un equipo específico, incluye el parámetro "restriction" en tu solicitud y establece como valor del parámetro la dirección IP del equipo en el que se reproducirán los vídeos. Por ejemplo restriction = Para solicitar vídeos que se puedan reproducir desde un país específico, incluye el parámetro "restriction" en tu solicitud y establece como valor del parámetro el código de dos letras ISO 3166 del país en el que se reproducirán los vídeos. Por ejemplo restriction = DE. Debes incluir este parámetro en todas las solicitudes para recuperar una lista de vídeos, incluidos los resultados de búsqueda, las listas de reproducción, los vídeos favoritos, las respuestas en vídeo, etcétera. Si un vídeo de la respuesta del API no se puede reproducir en la ubicación que estás utilizando para restringir la disponibilidad del contenido, la entrada (<entry>) de esa etiqueta no contendrá una etiqueta <media:content>. Sin embargo, contendrá una etiqueta <yt:state> que indicará que el vídeo está restringido. safesearch El parámetro safesearch indica si los resultados de la búsqueda deben incluir contenido restringido además de contenido estándar. YouTube determinará si el contenido está restringido a través de la dirección IP o de la ubicación del usuario, que se indica en la solicitud del API mediante el parámetro restriction. Si solicitas contenido restringido, las entradas de los feeds de vídeos con contenido restringido incluirán el elemento <media:rating>. Los siguientes valores son válidos para este parámetro: 69

71 Valor none Moderate Strict Descripción YouTube no aplicará ningún filtro a los resultados de búsqueda YouTube filtrará parte del contenido de los resultados de búsqueda y, al menos, filtrará el contenido que está restringido para tu configuración regional. Los resultados de búsqueda se pueden eliminar o rebajar de posición en función de su contenido. Nota: el valor predeterminado del parámetro safesearch es moderate. YouTube intentará excluir todo el contenido de acceso restringido de los resultados de búsqueda. Los resultados de búsqueda se pueden eliminar o rebajar de posición en función de su contenido El filtro safesearch del API de datos de YouTube está diseñado para funcionar de modo similar al filtro safesearch para los resultados de WebSearch de Google. Ten en cuenta que YouTube intenta eliminar el contenido restringido de los resultados de búsqueda de acuerdo con la configuración de safesearch que especifiques. No obstante, los filtros no son 100% eficaces y de forma ocasional pueden aparecer vídeos restringidos en los resultados de búsqueda, incluso si has especificado el filtro estricto SafeSearch. Si esto ocurriera, marca el vídeo mediante el envío de una reclamación, lo que nos ayudará a identificar mejor el contenido restringido. Nota: el parámetro safesearch se introdujo en la versión 2 del API de datos de YouTube y remplazó al parámetro racy, que se utilizaba en la versión 1. YouTube admite este parámetro para las solicitudes de búsqueda de vídeos. time El parámetro time restringe la búsqueda a los vídeos subidos dentro del período de tiempo especificado. Los valores válidos de este parámetro son today (un día), this_week (siete días), this_month (un mes) y all_time (en cualquier momento). El valor predeterminado de este parámetro es all_time. Este parámetro es compatible con los feeds de búsqueda y con los feeds estándar top_rated (más valorados), top_favorites (superfavoritos), most_viewed (más vistos), most_popular (más populares), most_discussed (más comentados) y most_responded (con más respuestas). uploader El parámetro uploader, que solamente se admite en las solicitudes de búsqueda, permite restringir una consulta a los vídeos de partners de YouTube. Un partner de YouTube es una persona u organización que se ha aceptado en el Programa para partners de YouTube y que participa en él. El valor del parámetro uploader debe ser partner. 70

72 En una respuesta del API, una entrada de feed incluirá un vídeo de un partner si la entrada contiene una etiqueta <media:credit> en la que el valor del atributo yt:type es partner. <media:credit role = "uploader" scheme = "urn:youtube yt:type = "partner">partner_name</media:credit> YouTube admite este parámetro para las solicitudes de búsqueda de vídeos. JSON en el protocolo de datos Este será el formato utilizado por la aplicación. Los feeds JSON y XML Un servicio Google Dara crea un feed en formato JSON mediante la conversión del feed XML utilizando las siguientes reglas: El feed se representa como un objeto JSON, cada elemento o atributo anidado se representa como una propiedad del tipo nombre/valor del objeto. Los atributos se convierten en propiedades String. Los elementos hijo (secundarios) se convierten en propiedades Object. Los elementos que pueden aparecer más de una vez se convierten en propiedades Array. Los valores de texto de las etiquetas(tags) se convierten en propiedades $t. Si un elemento tiene un alias del espacio de nombres(namespace), el alias y el elemento se concatenan con "$". Por ejemplo, ns:element se convierte en ns$element. Los atributos de versión y codificación del XML se convierten en atributos de versión y codificación del elemento raíz, respectivamente. El siguiente ejemplo muestra una versión JSON de un feed tabulado para facilitar su lectura. { "version" : "1.0", "encoding": "UTF-8", "feed": { "xmlns" : " "xmlns$opensearch" : " "xmlns$gd" : " "xmlns$gcal" : " "id" : {"$t": "..."}, 71

73 "updated" : {"$t": " T21:25:30.000Z"}, "title": { "type": "text", "$t" : "Google Developer Events" }, "subtitle": { "type": "text", "$t": "The calendar contains information about upcoming developer conferences at which Google will be speaking, along with other developer-related events." }, "link": [{ "rel" : "...", "type" : "application/atom+xml", "href" : "..." },{ "rel" : "self", "type" : "application/atom+xml", "href" : "..." }], "author": [{ "name": {"$t": "Google Developer Calendar"}, " ": {"$t": "developer-calendar@google.com"} }], "generator":{ "version" : "1.0", "uri" : " "$t" : "Google Calendar" }, "opensearch$startindex" : {"$t": "1"}, "opensearch$itemsperpage" : {"$t": "25"}, "gcal$timezone" : {"value": "America/Los_Angeles"}, "entry": [{ "id" : {"$t": "..."}, "published": {"$t": " T21:25:30.000Z"}, "updated" : {"$t": " T21:25:30.000Z"}, "category": [{ "scheme": "...", "term" : "..." }], "title":{ "type": "text", "$t" : "WebmasterWorld PubCon 2006: Google Developer Tools in General" }, "content": { 72

74 "type": "text", "$t": "Google is sponsoring at <a href= > WebMasterWorld PubCon 2006</a>. \ncome and visit us at the booth or join us for an evening demo reception where we will be talking "5 ways to enhance your website with Google Code".\nAfter all,\nit is Vegas, baby! See you soon." }, "link": [{ "rel" : "alternate", "type" : "text/html", "href" : "...", "title" : "alternate" },{ "rel" : "self", "type": "application/atom+xml", "href": "..." }], "author": [{ "name": {"$t": "Google Developer Calendar"}, " ": {"$t": "developer-calendar@google.com"} }], "gd$transparency": {"value": " "gd$eventstatus": {"value": " "gd$comments": {"gd$feedlink": {"href": "..."}}, "gcal$sendeventnotifications": {"value": "true"}, "gd$when": [{ "starttime": " ", "endtime": " ", "gd$reminder": [{"minutes": "10"}] }], "gd$where": [{"valuestring": "3150 Paradise Road,Las Vegas,NV 89109"}]}, }] } } Petición y uso de los FEEDS JSON Atom es el formato por defecto de Google Data. Si no se especifica un parámetro alt en la solicitud, se recibirá un feed Atom. Salida JSON Para solicitar una respuesta en formato JSON, utilice el parámetro alt = json. Por ejemplo, para solicitar el feed del calendario de desarroladores Google en formato JSON, envía la siguiente consulta: 73

75 alt=json 74

76 6. Desarrollo del proyecto En esta sección se explica paso a paso el desarrollo de una aplicación cuyos objetivos principales son localizar y mostrar fotografías digitales almacenadas en un conocido portal web como Flickr y acceder a una lista de reproducción de un canal de YouTube previamente especificado por el usuario final en una barra de búsqueda o a los videos almacenados en una tarjeta SD. Mediante esta explicación se busca ilustrar de una manera más práctica las características principales que ofrece Android y pretende además servir como ejemplo para la creación de otras aplicaciones. 6.1 Análisis de la aplicación Durante esta fase se pretende conocer y comprender la problemática que va a ser solucionada por el nuevo sistema informático. El análisis se realiza en este caso a través de juntas con el tutor del proyecto. A lo largo del proyecto se ha hecho uso de un modelo cíclico para las distintas fases que lo componen. El modelo cíclico se fundamenta en tratar de evitar los problemas cuanto antes dentro del ciclo de vida del proyecto. Debido a lo sofisticado en los sistemas actuales es virtualmente imposible definir el problema en su totalidad, diseñar la solución completa, desarrollar el software y después probar el producto final en secuencia, en cambio el proceso cíclico refina el entendimiento del problema, una solución efectiva y un plan efectivo a través de varios ciclos del proceso. Los riesgos mayores y los cuellos de botella deben de ser atacados en las etapas iniciales del proceso 75

77 Figura 13: Esquema del modelo cíclico Imagen extraída de: Durante la elaboración del proyecto se ha considerado y analizado: Las APIs de los portales web YouTube y Flickr para conocer cómo comunicar tales servicios web con un dispositivo móvil con el sistema operativo Android a través del estudio de los métodos y parámetros que los componen. Las principales propiedades que debería poseer la aplicación, y las tecnologías requeridas para desarrollarla en función de éstas. Los aspectos significativos de la memoria del proyecto Análisis de los requerimientos de la aplicación Los requisitos preponderantes a tener el cuenta serán: La aplicación debe mostrar en un número reducido de pasos y con cierta facilidad para el usuario final fotografías (almacenadas en su página de Flickr) y videos (almacenados tanto en una tarjeta SD como en YouTube) haciendo uso de las APIs. La cuenta de un usuario de Flickr estará almacenada en una base de datos SQLite en el propio dispositivo. 76

78 Las fotografías almacenadas en Flickr aparecerán en grupos de seis pudiendo seleccionar cada una de ellas con un simple click. Una vez seleccionada una fotografía del conjunto de seis, se mostrará una previsualización de ésta en el centro de la pantalla con un marco blanco, y debajo, el título y la fecha en que fue subida al servidor. El usuario podrá realizar un ampliación de la fotografía previsualizada si lo deseea a través de un botón situado en la parte inferior derecha de la pantalla. Si el usuario selecciona la visualización de un video almacenado en la SD Card (mostrando el título de cada uno de ellos en una lista vertical) a través de un simple click se reproducirá el video utilizando como reproductor de video un objeto de las librerías que constituyen el sistema operativo Android que permite pausar, detener o reiniciar el video. Si el usuario selecciona la opción de visualizar un video almacenado en YouTube podrá realizar una búsqueda en el portal web a través de una barra situada en la parte superior de la pantalla. 6.2 Diseño de la aplicación Una vez establecidos los requerimientos del proyecto se inicia el diseño del sistema incluyendo estructura de base de datos, pantallas, etc. Hasta este punto el diseño se hace en papel. En el siguientes apartado se exponen las consideraciones tenidas en cuenta en el diseño del entorno de usuario (interfaz de éste con la aplicación) y de la estructura interna de la aplicación Diseño de la interfaz En esta sección se distingue como está diseñada la interfaz de usuario de la aplicación desarrollada, las diferentes paginas que la componen y las partes de cada una de ellas. La primera página a la que accede el usuario tiene la siguiente estructura: 77

79 Bosquejo inicial Resultado final El usuario puede interactuar con la pantalla de la siguiente manera: Mediante dos botones coloreados en gris a través de los cuales puede seleccionar la visualización de fotografías o de videos. Pulsando el botón denominado Menu del dispositivo móvil en el cual puede establecer parámetros de configuración a la hora de recibir notificaciones de actualización de los usuarios de la base de datos. Tales parámetros son: Des/activación del servicio de notificación de actualizaciones. Seleccionar el tono de llamada con el que ser avisado de las modificaciones de los álbumes de fotos albergados en Flickr. Agregar la posibilidad de vibración del dispositivo para notificar actualizaciones en caso de encontrarse en entornos silenciosos. En caso de pulsar el botón marcado como Photos (la opción de visualizar las fotografías almacenadas en Flickr) se muestra la siguiente pantalla. Los usuarios registrados en la base de datos SQLite interna aparecerán en una lista vertical mostrando su icono y su nombre de usuario. 78

80 Bosquejo inicial Resultado final En ella se nos permite: Agregar un nuevo usuario a la base de datos interna (previamente registrado en el servicio web Flickr) introduciendo su nombre (más concretamente, el alias que el usuario seleccionó durante el proceso de registro para ser identificado en el portal web) en la parte superior derecha de la pantalla, adyacente al término Username. Realizar una pulsación larga sobre cada uno de los iconos situados a la izquierda de cada uno de los alias de los usuarios de Flickr emergerá una ventana con dos opciones en la que podremos: Eliminar el usuario de la base de datos de la aplicación. Visualizar sus fotografías. En caso de seleccionar la visualización de las fotografías se mostrará una pequeña animación (de derecha a izquierda) en la que surgirán las fotografías almacenadas en el servidor Flickr en grupos de seis. 79

81 En esta pantalla podremos: Navegar a través de las previsualizaciones de las fotografías a través de los botones situados en la parte inferior derecha de la pantalla (Etiquetados como Next y Back). Nota: En la captura de pantalla anterior no aparece la opción Back al tratarse del primer grupos de seis fotografías. Pulsar en cualquiera de las fotografías para visualizarla de manera aislada junto con su título y fecha de publicación. 80

82 En la pantalla anterior, podemos volver a la previsualización de fotografías en grupos de seis o realizar una ampliación de la fotografía (A través de los botones Back y Zoom respectivamente). 81

83 En caso de haber pulsado el botón etiquetado como Videos (ver la primera captura de pantalla de este apartado) el usuario podrá seleccionar: Visualizar los videos almacenados en una tarjeta de tipo SD Card. Visualizar los videos albergados en el servidor YouTube (en caso de tener instalada la aplicación YouTube en el dispositivo móvil). 82

84 83