Posts Tagged Google
El Nexus One no da primero pero da dos veces (o más)
Posted by Xavi in Móviles y Internet móvil on 25/05/2010
Cuando se presentó el Nexus One parecía que no cumplia con las expectativas que había levantado el esperado “GPhone”. En ese momento, el estado en el que se encontraba el sistema operativo no estaba a la altura de las posibilidades del aparato, y otros dispositivos personalizados por otras compañías aportaban un plus a sus productos sobre el N1 (por ejemplo HTC con la interfaz Sense).
Estos últimos días se ha dado la vuelta a la tortilla demostrando que el Nexus One es una de las mejores opciones en el universio Android. La reciente presentación de la versión 2.2 (Froyo) de Android en la Google I/O y su disponibilidad prácticamente inmediata para el N1 ha puesto en el primer lugar de las preferencias de muchos el móvil de Google.
La mayoría de fabricantes esta tardando mucho en portar las últimas versiones de Android a sus terminales, y las operadoras (empecinadas en meter extras que no hacen más que molestar) aun retrasan más la llegada de actualizaciones que los usuarios hace tiempo que ven en los nuevos dispositivos. Meterse en las tripas del móvil, conseguir ser root y utilizar versiones cocinadas es una alternativa que si bien no es demasiado compleja sí que es molesta cuando entendemos que es algo a lo que los usuarios tenemos derecho (si no no nos hubiésemos comprado un móvil con Android!!!).
No hace falta que las operadoras nos proporcionen una actualización OTA (Over-The-Air) y que aparezcan imágenes e inforgrafías de como va todo el proceso; los usuarios que queremos disfrutar de lo último nos conformamos con descargarla desde un ordenador y aplicarla con una combinación que quede bien explicada. Nada más! No pueden haber excusas logísticas para no realizar una actualización. ¿Qué es eso de que hay una versión de Android que no llega? ¿Por qué un fabricante que presuntamente “apoya” el desarrollo de Android lo maltrata de esta forma? ¿Se merece un terminal de puta madre como el HTC Hero seguir en la versión 1.5? Vamos por la 2.2 y se han presentado las características que tendrà la siguiente señores!!
Como propietario de un HTC Magic estoy muy contento con el terminal. Se trata de un móvil resistente y (en mi opinión) con un diseño bonito. Lo único que le añadiría sería una entrada para auriculares estándar pero entiendo que en el momento en que salió tampoco se podían pedir peras al olmo. Pero quiero YA las ventajas de las versiones 2.X. Un detalle tonto pero que me parece un ejemplo clarísimo de lo que estoy diciendo: Twitter hace poco liberó su cliente oficial para Android para terminales con 2.0 o superior. Tengo un móvil Android (etiquetado como “with Google”!!) con un año de vida y no puedo utilizar el cliente oficial de Twitter… debe ser por los altos requerimientos de hardware que impone esta red social… increíble
Si siguen por este camino, el único representante de Android que va a valer la pena se llamará Nexus One. No por mérito de Google, sino por demérito de los demás.

Os dejo un enlace a un post de El Androide Libre con información sobre la actualización en los diferentes terminales de Android aquí.
Google Storage for developers planta cara a Amazon S3
Posted by Xavi in Programación Web on 20/05/2010
Corrían rumores de que Google podía presentar una alternativa al servicio de almaceniamiento de Amazon, pero eran muy pocos los que creían que esto realmente podía pasar (me incluyo en el grupo de los incrédulos). Y Google anunció ayer en el Google I/O la disponibilidad de Google Storage for developers, un servicio de almacenamiento on-line con unas características muy parecidas a Amazon S3. Vamos a ver algunas de sus características:
- Almacenamiento por buckets/objetos: Exactamente igual que su vecino de Amazon.
- Nombre único del bucket en todo el servicio: Igual.
- Ausencia de carpetas o jerarquía pero capacidad de introducir el caracter “/” en el nombre del archivo para simular un árbol de directorios: Igual.
- Privacidad de los objetos 100% y inmutabilidad de los objetos: No recuerdo que Amazon detallara el punto de la privacidad (no estoy seguro), pero en cuanto a la inmutabilidad siguen siendo servicios equivalentes (hace falta reescribir el objeto para modificarlo).
A estas características básicas vamos a añadir un listado de las operaciones básicas. Veremos que siguen cortadas por el mismo patron que S3:
- Crear y eliminar buckets
- Listar buckets y objetos
- Subir y descargar objetos
- Eliminar objetos
- Definir listas de control de acceso (ACL) para los objetos
- Definir metadatos de los objetos
Y una serie de características adicionales, algunas de las cuales sí que marcan alguna diferencia con Amazon:
- Autenticación basada en cookies (no recuerdo que esto este disponible en S3 pero no estoy seguro de ello).
- Soporte a las cuentas de Google para establecer el nivel de seguridad de los objetos.
- Es necesaria una Developer Key (un par de clave de acceso y clave secreta).
- API REST (no existe una API SOAP y no parece que entre en los planes de Google).
- Soporte para SSL.
- Herramientas por linea de comandos y librería basadas en Python (Boto).
- Aplicación web para gestionar buckets y objetos (!!!).
La lista de precios también sigue el mismo patrón que Amazon pero se ofrece una cuota inicial gratuita (“solo” 100 GB de almacenamiento y 300 GB de transferencia al mes). Los precios son los siguientes:
- Almacenamiento: 0’17 US$/GB al mes
- Transferencia (subida): 0’10 US$/GB
- Transferencia (descarga): 0’15 US$/GB en América y EMEA y 0’30 US$/GB en APAC
- Peticiones (PUT,POST,LIST): 0’10 US$/1.000 peticiones
- Peticiones (GET,HEAD): 0’10 US$/10.000 peticiones
¿La mala noticia? Disponible para desarrolladores en los U.S. y con cola de admisión… espero que no tarden lo mismo que Amazon en traer los servicios a Europa!!
Subir vídeos a YouTube con Zend Gdata
Posted by Xavi in Programación Web, Redes sociales on 24/08/2009
Aunque no sea difícil seguir los tres artículos relacionados con la subida de vídeos a You Tube (se encuentran todos a continuación) os dejo la referencia a los tres apuntes:
Y algunos enlaces de interés:
Subir vídeos a YouTube con Zend Gdata – Identificación del usuario
Posted by Xavi in Programación Web, Redes sociales on 21/08/2009
Siguiendo el post anterior, dónde podíamos ver que recursos nos hacían falta para empezar la odisea de compartir un vídeo en YouTube directamente, vamos a explicar el procedimiento para identificar un usuario en YouTube desde nuestra aplicación web.
Existen tres alternativas para identificar los usuarios en sus cuentas de YouTube desde aplicaciones externas:
- La primera se basa en el protocolo OAuth, pero aunque sea muy interesante, el soporte que tiene el módulo Zend_Gdata para este tipo de identificación es bastante limitado (recordamos que estamos trabajando sobre la versión 1.8.4).
- La segunda se llama ClientLogin y aunque su utilización parezca mucho más sencilla que las otras dos alternativas Google/YouTube sólo aconseja implementar este proceso de autenticación en aplicaciones de escritorio (y nunca implementarlo en aplicaciones web).
- La tercera, y como habréis podido adivinar leyendo la descripción de las dos anteriores la que vamos a implementar aquí, recibe el nombre de AuthSub y se basa en que el usuario se identifica en la página original de YouTube y YouTube manda al servidor de nuestra aplicación de forma segura los datos de conexión de dicho usuario.
Después de esta pequeña introducción vamos a explicar los pasos para identificar un usuario en YouTube mediante el protocolo AuthSub con el módulo Zend_Gdata.
Identificar un usuario en YouTube con AuthSub
Para identificar un usuario mediante este protocolo el primer paso de todos es direccionar al usuario a una página de YouTube para que este se identifique y de permiso para que nuestra aplicación acceda a su cuenta de usuario. Para saber a que URL debemos direccionar al usuario debemos correr el siguiente codigo PHP:
<?php
$nextUrl = 'http://nombredominio.com/path/a/pagina/de/subida';
$scope = 'http://gdata.youtube.com';
$secure = true;
$session = true;
$authSubUrl = Zend_Gdata_AuthSub::getAuthSubTokenUri($nextUrl, $scope, $secure, $session);
?>
El contenido final de $authSubUrl es la URL de YouTube dónde tenemos que redireccionar al usuario (siempre que tengamos en regal todos los requisitos previos que comentamos en el post anterior). Aun así vamos a explicar para que se utilizan las cuatro variables que hemos definido antes de generar esta dirección.
- $nextUrl:
$nextUrl nos indica a que página de nuestra aplicación queremos que YouTube redireccione al usuario después de haber finalizado la identificación en su aplicación. Este parámetro acepta variables en la URL por GET, así ‘http://nombredominio.com/path/a/pagina/de/subida’ podría ser perfectamente ‘http://nombredominio.com/path/a/pagina/de/subida?video=idedelvideo’.
- $scope:
$scope es la variable que indica al método getAuthSubTokenUri en que servicio queremos identificar el usuario (del mismo modo que identificamos en YouTube podemos identificar usuarios en Picasa, Calendar u otros servicios de Google cambiando el $scope).
- $secure:
$secure indica si el tipo de identificación que estamos pidiendo a YouTube es para acceder sólo a datos públicos (requerimientos de seguridad menores) o también para modificar los contenidos del usuario (requerimientos de seguridad mayores).
- $session:
$session define si la identificación que nos proveerá YouTube podrá ‘upgradearse’ para utilizarse durante una sesión (navegador) o sólo para una operación. Para hacer un upload de un vídeo es posible que no fuese necesario hacer este upgrade pero igualmente lo vamos a explicar en el siguiente post.
Para que el direccionamiento del usuario a YouTube sea exitoso es necesario añadir la clave de desarrollador (ver post anterior) ya sea en la URL por GET o en el header de la petición (dependiendo de como vayas a llevar al usuario a esa dirección). Veamos como añadiríamos la clave de desarrollador de las dos formas:
Añadir la clave de desarrollador en la petición a YouTube
- Por GET en la URL:
Para añadir la clave del desarrollador en la URL como parámetro GET debemos concatenar su valor a continuación de $authSubUrl:
$authSubUrl = $authSubUrl.'&key=VALOR_DE_TU_CLAVE_DE_DESARROLLADOR'; - Añadiendo la clave en el header:
Podemos añadir la clave de desarrollador en el header de la petición para que quede de la siguiente forma:
X-GData-Key: key=VALOR_DE_TU_CLAVE_DE_DESARROLLADORPara realizar esto desde de PHP podemos executar la siguiente operación:
header("X-GData-Key: key=".YOUTUBE_API_KEY);
Si todo ha funcionado como es debido el usuario ya debe haber accedido a su cuenta en YouTube y debe haber dado permiso para que nuestra aplicación web realice las operaciones pertinentes en sus contenidos. En este caso nos debe haber llegado una petición a nuestro servidor, más concretamente una petición a la página ‘http://nombredominio.com/path/a/pagina/de/subida’.
En la petición “de vuelta” de YouTube nos vamos a encontrar que por GET vamos a recibir el valor de una variable llamada token. Token es el nombre de la variable que YouTube utiliza para certificar la identificación de un usuario concreto. Esta variable nos será imprescindible para poder firmar las peticiones que de aquí en adelante vamos a enviar a YouTube.
En el próximo y último post sobre Subir vídeos a YouTube con Zend Gdata vamos a describir que operaciones debemos llevar a cabo cuando YouTube nos garantiza el acceso a la cuenta de un usuario mediante el token. Hasta pronto!
Subir vídeos a YouTube con Zend Gdata – Requisitos previos
Posted by Xavi in Programación Web, Redes sociales on 19/08/2009
Hace unas semanas que el equipo de Iceberg se centró en la integración de YouTube y otros servicios de Google en los proyectos en los que trabajamos. Integrar los servicios de Google dentro de las aplicaciones que podamos ofrecer en un futuro cercano representa un salto cualitativo que queríamos dar pero que no sabíamos si tendríamos los recursos necesarios para hacer realidad.
El proceso para realizar una integración de este tipo no es sencillo pero tampoco es tan complicado como puede parecer cuando los errores se multiplican y no se avanza. El mayor ‘handicap’ con el que nos hemos encontrado es la falta de cohesión de la documentación que ofrece Google y el Zend Framework (la integración de estos servicios se ha realizado en aplicaciones web PHP que utilizan Zend Framework como motor principal de la aplicación, más concretamente la versión 1.8.4). Por culpa de esta falta de cohesión, la dedicación a esta tarea ha aumentado más de lo que seria deseable.
Este post pretende ser el primero de una serie de apuntes que detallen paso a paso cual es el camino a seguir para llegar a subir vídeos a YouTube desde nuestra propia aplicación (gracias a mi compañera Laura por meter presión para publicarlos!). El primero de la serie viene dedicado a que requisitos debemos cumplir para poder empezar a pensar en una integración similar.
Requisitos previos
- Debemos tener un servidor de desarrollo accesible desde Internet (con un dominio o sub-dominio propio):
La identificación de usuarios de nuestra aplicación web en los servicios de Google es el punto más crítico en el proceso de compartir un vídeo en YouTube. Para aplicaciones web, Google/YouTube utiliza un protocolo que incluye redirecciones a páginas que deben ser accesibles desde su sistema. Por este motivo debemos tener un servidor ‘visible’ a nuestra disposición.
- Utilizar Zend Framework como motor de la aplicación o tener funcionando el módulo Zend_Gdata:
El Zend Framework tiene integrado el módulo Zend_Gdata pero este último se puede descargar por separado si no estamos trabajando con dicho framework para desarrollar nuestra aplicación (¿Te has preguntado porqué no lo estás utilizando
?). La documentación sobre como poner en marcha una aplicación con este framework es muy extensa así que si estáis interesados podéis visitar la guía de referencia o la QuickStart en la página oficial.Si sólo estáis interesados en poner en funcionamiento el módulo Zend_Gdata os aconsejo que visitéis la página de la API de YouTube destinada a eso. Con este recurso y la documentación que hay dentro de la descarga de módulo Zend_Gdata no deberíais tener más problema.
- Conseguir una clave de desarrollador:
Para conseguir una clave de desarrollador en Google sólo hace falta tener una cuenta de Google (si utilizas cualquiera de sus servicios ya tienes una) y acceder al “dashboard” de la API de YouTube.
Piensa que esta clave de desarrollador después también te servirá como clave para otros servicios como Picasa Albums o Calendar.
- Registrar el dominio dónde vas a ejecutar la aplicación en Google:
Google necesita que registres el dominio en su sistema para permitir que realices operaciones que modifiquen los contenidos que los usuarios tienen en sus cuentas (por ejemplo subir un vídeo a su cuenta de YouTube). En este proceso se tiene que registrar el dominio en la página de gestión de dominiosde Google (con una cuenta de usuario de Google, puede ser la misma que la que hemos utilizado en el paso anterior).
El registro de un dominio como seguro para Google cuenta con varios pasos. Primero debemos introducir el dominio y paso seguido nos pedirá que verifiquemos que somos los propietarios o administradores de ese dominio. Para verificar un dominio tenemos que entrar en el enlace que pone ‘Manage nombredominio.com’ y escoger uno de los métodos que se nos ofrece.
NOTA: Aunque se recomiende el método de añadir un meta-tag yo he seguido el método de subir un archivo html y no he tenido ningún problema, la verificación ha sido inmediata.
Una vez verificado el archivo aceptamos los términos del servicio (si estamos de acuerdo con ellos) y nos encontraremos un formulario con los campos siguientes:
- Target URL path prefix:
Aquí debes poner “http://nombredominio.com” si quieres que tu aplicación pueda hacer peticiones de identificación desde diferentes páginas (de momento nosotros lo hemos definido así y gestionamos la identificación de los usuarios en diferentes servicios desde diferentes páginas, pero esto es casi cuestión de gustos y cada uno tendrá el suyo)
- Domain description:
Este campo es opcional, se trata de una breve descripción sobre el dominio.
- Upload X.509 cert:
Este paso es un poco más complicado que el resto. Se trata de subir un certificado de seguridad que Google utilizará para asegurarse que las peticiones que mandamos son seguras. Como no soy un experto en estos temas sólo señalar que lo que tenemos que subir es el certificado y no la clave privada. Para generar una clave privada y un certificado auto-firmado podéis entrar en el siguiente enlace de AOL sobre como generar certificado auto-firmados
Una vez tengamos completado el formulario en la cabecera del formulario deberá aparecer la palabra “Active” en verde al lado del nombre del dominio. En este momento estamos listos para empezar a programar.
- Target URL path prefix:
La primera operación que deberemos realizar después de preparar nuestro entorno con los pasos descritos anteriormente es la de identificar al usuario, pero eso vendrá en el siguiente post… Hasta que lo cuelgue espero que os sea de utilidad!
Actualización de Android
Posted by Xavi in Móviles y Internet móvil on 27/05/2009
Hoy mi HTC Magic se ha levantado con una pequeña actualización de software. Con el poco uso que le he podido dar hasta ahora parece que ha solucionado algunos cuelgues de aplicaciones y ha mejorado el rendimiento general del sistema.
¿Sabeis más de la actualización? Adelante, comenta que nos morimos de ganas de saber más!
jQuery en Zend Framework sin la API Google
Posted by Xavi in Programación Web on 27/03/2009
El Framework de Zend ofrece la possibilidad de ampliar sus funcionalidades con las del framework de JavaScript jQuery (empezó con http://www.dojotoolkit.org/, pero la integración con jQuery ya está bastante avanzada).
El principal problema que podemos tener al empezar a utilizar estas nuevas características es que por defecto el framework carga los archivos .js de la API de Google. Esto puede ser beneficioso en algunos casos, pero si estamos acostumbrados a una versión determinada de jQuery (o de sus plugins para la interfaz de usuario como es jQuery-UI) quizás queremos cargarla nosotros mismos de nuestro servidor.
El método para determinar desde que ruta local queremos cargar los .js es el setLocalPath() (setUiLocalPath() para jQuery-UI) pero si no queremos realizar esta tarea para todas las acciones que programemos tenemos la siguiente alternativa.
ATENCIÓN: Esea método puede no ser el más correcto, puede que haya un sistema mucho más óptimo de realizar estos cambios, pero en nuestro caso no hemos encontrado un buen sistema centralizado para cambiar el origen de los archivos .js de la API de Google al servidor local.
Para garantizar que los archivos que se van a cargar de jQuery son los de nuestro servidor debemos tenerlos bien localizados. En nuestro caso estarán en la carpeta /js dentro de la carpeta /public (que es donde apunta el document root de nuestro servidor, original eh!?).
Una vez localizados sólo debemos encontrar el archivo Container.php dentro de la carpeta /library/ZendX/JQuery/View/Helper/JQuery i editarlo. Dónde nos encontremos esta línea:
protected $_jqueryLibraryPath = null;Debemos poner la ruta a nuestro archivo .js de jQuery:
protected $_jqueryLibraryPath = '/js/jquery-1.3.2.min.js';Si también vamos a utilizar la extensión UI debermos hacer lo mismo con la línea siguiente:
protected $_uiPath = null;La debemos cambiar por la de nuestro archivo .js de la UI:
protected $_uiPath = '/js/jquery-ui-1.7.1.custom.min.js';
Si sabeis un método mejor, adelante!


Comentarios recientes