programa-con-google: April 2015

TinyBytes: El desarrollo de videojuegos paso a paso de la mano de Launchpad

Tuesday, April 28, 2015

TinyBytes, una de las startups integrantes de Launchpad nos cuenta su experiencia día a día en el desarrollo de videojuegos:
Nuestra interacción con Google empieza con el comienzo de cada nuevo juego. Desarrollamos en Unity para Android, que es la plataforma más sencilla y práctica para desarrollar, con lo que la mayoría de las veces prototipamos juegos que primero corren en Android.
Una vez que esos juegos están medianamente avanzados, los subimos al Google Beta Testing y pedimos feedback de los jugadores. Seguimos iterando y puliendo el juego hasta lanzar una versión más avanzada (algo parecido a un Producto Mínimo Viable) en Google Play para unos pocos países, donde medimos el comportamiento de los usuarios.
Si vemos que los usuarios vuelven al juego después de varios días, seguimos incorporando features y contenido al juego, haciéndolo cada vez mejor. Por otro lado, Google Docs nos permite guardar muchas listas de ideas y prioridades que compartimos con el equipo para su seguimiento en el tiempo.
Una vez que el juego esta listo con los features y el contenido planeado y pasa los controles de calidad, trabajamos en los assets de marketing, y lo lanzamos en Google Play mundialmente.
Nuestros juegos están integrados con Google Game Services, permitiendo a los usuarios registrarse con su cuenta de Google+ para así tener acceso a leaderboards y achievements de Google y competir contra amigos y otros usuarios.
Uno de los aspectos más satisfactorios de trabajar en Android es que en pocas horas (o minutos!) el juego esta publicado y disponible para su descarga en Google Play. El backend de Google Play para la carga de textos y assets es sencillo e intuitivo.

En desarrollo de juegos para móvil, los tiempos son claves. Como desarrolladores, queremos saber cuanto antes qué piensan nuestros usuarios sobre el juego para poder mejorarlo, o alternativamente trabajar en ofrecerles otro juego aún mejor. Es por eso que Android y Google Play son de gran ayuda en game development, y lo recomendamos ampliamente.
Si tu también quieres formar parte del programa Launchpad y disfrutar de sus beneficios accede aquí.
Este post ha sido escrito por TiniBytes, startup chilena parte del programa #Launchpad. Editor by +Nicolas Bortolotti

El poder de Polymer y YouTube desde la comunidad, una nueva entrega experiencia

Thursday, April 23, 2015

YouTube permite personalizar su reproductor de video e integrarlo en nuestras páginas y aplicaciones para crear experiencias con videos interactivos.Es un gran desafío personalizar el reproductor de modo de lograr una experiencia consistente a través de diferentes dispositivos, con distintos tamaños de pantalla, como móviles, TV, laptops y tablets. ¿Como podemos hacerlo?El componente Web del reproductor de YoutubeGracias a Polymer y los componentes de YouTube podemos utilizar y personalizar el reproductor. Podemos configurar sus parámetros, gestionar su estado y sus eventos!
Los parámetros más importantes son el videoid, con el que especificamos el video que queremos ver, la altura y ancho (parámetros height y width), y finalmente un parámetro que permite simular el modo Chromeless (el reproductor sin controles y branding..), de modo de crear nuestros propios controles para reproducir el video.Recreando caso de éxito "Videos interactivos, Knorr Mexico"

Recreemos la experiencia con videos interactivos de Knorr México, utilizando Polymer, Fig.1:

Fig.1

En esta experiencia se logra ocultado los controles estándar del reproductor (utilizando el modo Chromeless), y mostrando en cambio controles personalizados. Además se comienza en forma automática la reproducción de video.

Como lo podemos hacer con el componente web de YouTube? Simple:

Vamos a configurar el componente de YouTube con reproducción automática y sin controles (Chromeless):

<google-youtube

videoid="3T87lMYzqf4"

height="100%"

width="100%"

rel="0"

autoplay="1"

chromeless>

</google-youtube>
Veamos el ejemplo:http://matiasmolinas.github.io/google-youtube/components/google-youtube/demo.html
Puedes hacer un fork del proyecto en Github:https://github.com/matiasmolinas/google-youtube

En el ejemplo solo falta utilizar paper elements para crear nuevos controles de reproducción, algo que es muy recomendado cuando utilizas el modo Chromeless!

En el próximo artículo veremos cómo incorporar este tipo de controles (paper elements), junto con el API de Datos de YouTube, al hacer uso del componente:
google-youtube-video-wall
https://github.com/GoogleWebComponents/google-youtube-video-wall

Hasta la próxima!

Este post ha sido escrito por +Matias Molinas, Google Developer Expert para YouTube API. Editor by +Nicolas Bortolotti

Se han desactivado los protocolos ClientLogin, OAuth 1.0 (3LO), AuthSub y OpenID 2.0

Monday, April 20, 2015

Originalmente publicado por William Denniss, gerente de producto de Identidad y Autenticación
Se ha finalizado el soporte para ClientLogin, OAuth 1.0 (3LO1), AuthSub y OpenID 2.0, según lo planificado en nuestro cronograma. Los clientes que usen estos servicios no volverán a funcionar correctamente y deberán migrar inmediatamente a OAuth 2.0 u OpenID Connect.
La forma más fácil de migrar un sistema de autenticación es usar Google Sign-in SDKs (consulte la documentación de migración). Google Sign-in está construido sobre nuestra infraestructura basada en los estándares OAuth 2.0 y OpenID Connect, que proporcionan una interfaz única para el flujo de autenticación y autorización en iOS, Android y Web. Para migrar el uso de la API del servidor, recomendamos utilizar una de nuestras bibliotecas cliente de OAuth 2.0.
Estamos dejando de utilizar los protocolos de autenticación heredados y centramos nuestro soporte en OpenID Connect y OAuth 2.0. Estos modernos estándares abiertos mejoran la seguridad de las cuentas de Google, y por lo general los desarrolladores se integran más fácilmente con ellos.
13LO significa 3legged OAuth, que significa que el usuario final presta consentimiento. Por el contrario, 2legged (2LO) corresponde a situaciones de autorización empresariales, tales como control de acceso mediante políticas organizacionales. Los flujos de OAuth1 3LO y 2LO están en desuso, sin embargo, este anuncio se refiere específicamente a OAuth1 3LO.