MatrixAdapt | Logiciel de gestion d'Entreprise, Création et référencement des sites web

Seo Master present to you:
By John Taylor, Lead Game Designer, Travel Game

This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.


Travel Game is the first online social game powered by Google Earth, and the first game of its kind to provide players with real, free travel rewards. Currently in beta testing, Travel Game is being unveiled for the first time at Google I/O 2011. Travel Game was conceived by Jeff Katz, a technology and travel industry veteran, and founding CEO of Orbitz, Inc.

Touristo and Skydiver, our first two titles, provide players with the experience of sky diving over the Earth and navigating a Touristo vehicle through exotic locales via Google Earth’s virtual 3D globe. To take advantage of the awesome imagery, terrain, and 3D models available in Google Earth, we built a custom framework that ties into several Google APIs, including Google Earth, Google Maps, and even Google’s currency converter API.


We wanted to give users the best possible experience – with high-quality game play, animations, and sound – so we based our framework on a blend of Javascript, Flash, and a custom back-end, all tied into the Google Earth APIs. We designed an XML structure that lets our game designers add new game packs easily and – some day – we may give users tools to do the same.

For example, part of our framework lets game designers add “targets” inside Google Earth using XML like this:

<target action="addTarget">
    <itemPath>assets/images/blank.png</itemPath>
    <longitude>-157.8459651634087</longitude>
    <latitude>21.31249095467307</latitude>
    <imageRadius>.0000018</imageRadius>
    <targetRadius>20</targetRadius>
</target>

We created a Javascript architecture to interpret the XML and make several calls to the Google Earth API to set up the scene and add 3D models as markers for the target. We then track the user’s position relative to the target using Google Earth’s ground overlays. This involves a lot of background processing, but we were surprised at how well it performs.

Based on the social trends we know are emerging in real travel, we’re also tying features into Facebook, like posting places visited in Travel Game to your wall, sending gifts to friends, and eventually inviting friends to play along for group prizes. We’re even injecting the user’s Facebook photos into Google Earth.


The current beta version of Travel Game has been developed and nurtured by a team of travel and gaming industry experts. We’re extremely excited about creating online exploration that translates into real-world experiences. At this point, we’re just scratching the surface and see great potential for creating more great games and social communities as an overlay to Google Earth.


Come see Travel Game in the Developer Sandbox at Google I/O on May 10-11.

John Taylor has been designing and developing software for 20 years for companies like Electronic Arts, Lucas Learning, and the Disney Channel. Before that, he circled the globe a few times and worked as a writer and film editor.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you: By Mark Scott, Product Manager, Chrome

Cross-posted from the Chromium Blog

Event pages keep apps and extensions efficient by allowing them to respond to a variety of events such as timers or navigation to a particular site, without having to remain running persistently. But what if you need to respond to something that occurs outside of Chrome, such as a news alert, a message sent to a user or a stock hitting a price threshold? Until now, you had to do this by repeatedly polling a server. This process consumed bandwidth and reduced the battery life of your users’ machines. For a more efficient solution, starting today you can use Google Cloud Messaging for Chrome (GCM) - across all channels of Chrome.

GCM will be familiar to developers who have used Google Cloud Messaging for Android. To send a message, all you need to do is:

1. Request a token (channel ID) via chrome.pushMessaging.getChannelId(). 
2. Pass the returned token to your server. 
3. Whenever you need to send a message to your app or extension, post the message along with the token to the GCM server-side API. 

Your message is then delivered in near real time to Chrome. This makes your event page wake up (if it’s not already running), and the message is delivered to your chrome.pushMessaging.onMessage listener.



To use GCM, your users must be signed into Chrome, as the service relies on an efficient push channel that’s only established for signed-in users. Messages are automatically delivered to all the devices where the user has signed in and installed your app/extension.

To add GCM to your app/extension, take a look at the overview of the service or start with some of the sample apps—and start pushing!


Mark Scott is a Product Manager on the Google Chrome team. He works with a team in Kirkland on features that make Chrome a great platform for building apps.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you:
By Cameron Henneke, Founder and Principal Engineer of GQueues

This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.


With the proliferation of mobile app stores, the intensity of the native app vs. web app debate in the mobile space continues to increase. While native apps offer tighter phone integration and more features, developers must maintain multiple apps and codebases. Web apps can serve a variety of devices from only one source, but they are limited by current browser technology.

In the Google IO session HTML5 versus Android: Apps or Web for Mobile Development?, Google Developer Advocates Reto Meier and Michael Mahemoff explore the advantages of both strategies. In this post I describe my own experience as an argument that an HTML5 app is a viable and sensible option for online products with limited resources.

Back in 2009 I started developing GQueues, a simple yet powerful task manager that helps people get things done. Built on Google App Engine, GQueues allows users to log in with Gmail and Google Apps accounts, and provides a full set of features including two-way Google Calendar syncing, shared lists, assignments, subtasks, repeating tasks, tagging, and reminders.


While I initially created an “optimized” version of the site for phone browsers, users have been clamoring for a native app ever since its launch two years ago. As the product’s sole developer, with every new feature I add, I consider quite carefully how it will affect maintenance and future development. Creating native apps for iOS, Android, Palm, and Blackberry would not only require a huge initial investment of time, but also dramatically slow down every new subsequent feature added, since each app would need updating. If GQueues were a large company with teams of developers this wouldn’t be as big an issue, although multiple apps still increase complexity and add overhead.

After engaging with users on our discussion forum, I learned that when they asked for a “native app,” what they really wanted was the ability to manage their tasks offline. My challenge was clear: if I could create a fast, intuitive web app with offline support, then I could satisfy users on a wide variety of phones while having only one mobile codebase to maintain as I enhanced the product.

Three months ago I set out to essentially rewrite the entire GQueues product as a mobile web app that utilized a Web SQL database for offline storage and an Application Cache for static resources. The journey was filled with many challenges, to say the least. With current mobile JavaScript libraries still growing to maturity, I found it necessary to create my own custom framework to run the app. Since GQueues data is stored in App Engine’s datastore, which is a schema-less, “noSQL” database, syncing to the mobile SQL database proved quite challenging as well. Essentially this required creating an object relational mapping layer in JavaScript to sit on top of the mobile database and interface with data on App Engine as well as input from the user. As a bonus challenge, current implementations of Web SQL only support asynchronous calls, so architecting the front-end JavaScript code required a high use of callbacks and careful planning around data availability.

During development, my test devices included a Nexus S, iPhone, and iPad. A day before launch I was delighted to find the mobile app worked great on Motorola Xoom and Samsung Galaxy Android tablets, as well as the Blackberry Playbook. This fortuitous discovery reaffirmed my decision to have one codebase serving many devices. Last week I launched the new GQueues Mobile, which so far has been met with very positive reactions from users – even the steadfast “native app” proponents! With a team of developers I surely could have created native apps for several devices, but with my existing constraints I know the HTML5 strategy was the right decision for GQueues. Check out our video and determine for yourself if GQueues Mobile stacks up to a native app.


Come see GQueues in the Developer Sandbox at Google I/O on May 10-11.

Cameron Henneke is an entrepreneur based in Chicago who loves Python and JavaScript equally. While not coding or answering support emails, he enjoys playing the piano, backpacking, and cheering on the Bulls.

Posted by Scott Knaster, Editor

2013, By: Seo Master