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

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

Seo Master present to you:

Jeetendra

Nick

By Jeetendra Soneja and Nick Mihailovski,
Google Analytics API Team

Many developers save time by using the Google Analytics API to automate Analytics reporting tasks. For example, you can use the API to create a dashboard to report data across multiple profiles. The Google Analytics Apps Gallery includes many 3rd party solutions that do this.

What if you want to build something quickly that’s custom-tailored to your business? You would typically have to spend time learning the API, figuring out how to handle authorization, then deciding how to integrate this data with a visualization library. You could build a custom solution, but it would take a lot of effort – until now, thanks to the Google Analytics Easy Dashboard Library.

Four months ago we started a project with a team of University of California Irvine students to simplify all of these steps. As part of this project, together we built the Google Analytics Easy Dashboard Library. This library makes it easy to use the Google Analytics API by distilling the process into three easy steps:

1. Register with Google APIs Console.
2. Copy and paste the JavaScript code.
3. Configure this code to query your data and choose a chart type to visualize it.

So now you can create custom Google Analytics dashboards very quickly, with minimal code.

Here’s a quick example. Say you want to create a line chart plotting visitors and visits for the last 30 days. Besides including the library, the only code required is:

<div id="chart1"></div>
<script>
var chart1 = new gadash.Chart({
      'type': 'LineChart',
      'divContainer': 'chart1',
      'last-n-days':30,
      'query': {
        'ids': TABLE_ID,
        'metrics': 'ga:visitors,ga:visits,ga:pageviews',
        'dimensions': 'ga:date',
  'sort': 'ga:date'
      },
      'chartOptions': {
        hAxis: {title:'Date'},
        vAxis: {title:'Visits'},
      }
    }).render();
</script>

Using the code above will create the following chart.

It’s that easy! To find out more about using the Easy Dashboard Library, read our Getting Started guide.

While the current library is very useful, we think we can add more features and make it even easier to use. To reach this goal, we’ve started working with another group of UC Irvine students, this time for three academic quarters. This new project's main goal will be to further simplify the library. We want the students we're working with to engage with you and implement your feature requests, if possible. If you use this library, we'd love to hear how you think it can be improved. Feel free to send any feedback to through our new GA-easy-dash-feedback Google Group.

We hope this library saves you time and helps you get more out of Google Analytics.


Jeetendra Soneja is the Technical Engineering Lead on the Google Analytics API team. He's a big fan of cricket – the game, that is. :)

Nick Mihailovski is a Senior Developer Programs Engineer working on the Google Analytics API. In his spare time he likes to travel around the world.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you:
By Dominic Szablewski, creator of the Impact Game Engine

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.


Impact is a JavaScript game engine that uses the HTML5 Canvas and Audio elements for graphics and sound, instead of relying on any browser plugins. Impact's main focus is on classic 2D games. Examples include the Biolab Disaster Jump'n'Run game and the Z-Type Space Shooter. These games, like many other 2D games, draw sprites in front of multiple background layers.


Each background layer is drawn from a tileset, an image containing all the individual building blocks, and a tilemap, a 2D array that tells the renderer where to draw each of these tiles. Similarly, sprites are drawn from an animation sheet, an image with all the animation's frames.

This technique has proven so efficient and flexible that it was enforced in hardware on early game consoles: the Super Nintendo could not do anything other than draw tiled background maps and sprites. There was no way to directly access single pixels on the screen.

The HTML5 Canvas element is perfectly equipped for these kinds of games. Most importantly, the Canvas API's drawImage() method allows us to draw only a certain part of a tileset or animation sheet to the screen. In Impact, however, you don't have to deal with any of the Canvas API methods directly. Instead, you specify your tilemaps and animation sheets and let the engine handle the details.

This is how you'd create an animation from an animation sheet:

// Each animation frame is 16x16 pixels
var sheet = new ig.AnimationSheet( 'player.png', 16, 16 );

// This creates the "run" animation: it has 6 frames (the 2nd row 
// in the image), with each one being shown for 0.07 seconds
var run = new ig.Animation( sheet, 0.07, [6,7,8,9,10,11] );

Similarly, here's the code needed to create and draw a background layer:

// Create a 2D tilemap
var map = [
 [5, 3, 4],
 [2, 7, 1],
 [6, 0, 3]
];

// Specify a layer with a tilesize of 16px and our tilemap
var layer = new ig.BackgroundMap( 16, map, 'tileset.png' );
layer.draw();

You don't have to create these tilemaps by hand. Impact comes with a powerful level editor called Weltmeister, which makes it easy to draw background layers and position your entities (non-static objects in the game world) in your levels.


When drawing on a Canvas, the performance is mostly bounded by the number of draw calls. It is far more efficient to draw one or two very large images than to draw several hundred small ones. This means that drawing background layers tile by tile can be quite slow, especially on mobile devices.

The Impact engine therefore has a special "pre-render" mode that you can enable on background layers. This mode will first draw the tilemap into large chunks of 512x512 pixels when loading a level, and then use these chunks to fill the screen instead of drawing the layer tile by tile. With this technique, you can get good frame rates even for fast-paced games on Android and iOS devices.

Impact also handles sound, input, timing, and much more for you. It's by no means a game engine that can do everything – and it doesn't try to be one – but it's very good at the things it can do.


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

Dominic Szablewski is the creator of the Impact Game Engine. He recently finished his Bachelor Thesis about HTML5 Gaming and now lives the dream by selling Impact and making games.

Posted by Scott Knaster, Editor

2013, By: Seo Master