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

Seo Master present to you:
By Scott Knaster, Google Code Blog Editor

This is the last Fridaygram of 2011, and like most everybody else, we’re in a reflective mood. It’s also the 208th post on Google Code Blog this year, which means we’ve averaged more than one post every two days, so that’s plenty of stuff for you to read. What did we write about?

At Google, we love to launch. Many of our posts were about new APIs and client libraries. We also posted a bunch of times about HTML5 and Chrome and about making the web faster. And we posted about Android, Google+, and Google Apps developer news.

Many of our 2011 posts were about the steady progress of App Engine, Cloud Storage, and other cloud topics for developers. We also published several times about commerce and in-app payments.

2011 was a stellar year for Google I/O and other developer events around the world. Some of our most popular posts provided announcements, details, and recaps of these events. And we welcomed a couple dozen guest posts during Google I/O from developers with cool stories to tell.

The two most popular Code Blog posts of the year were both launches: the Dart preview in October, and the Swiffy launch in June.

Last, and surely least, I posted 26 Fridaygrams in an attempt to amuse and enlighten you. Thank you for reading those, and thanks for dropping by and reading all the posts we’ve thrown your way this year. See you in 2012!

And finally, please enjoy one more Easter egg.

2013, By: Seo Master

Seo Master present to you:
By Becky Chappell, Developer Marketing Team

Every year at Google I/O, companies arrive excited to demo their coolest new products in the Developer Sandbox. In the past, these demos were only accessible to I/O attendees. This year, we wanted to help spread the love and knowledge from these innovative companies to developers who were unable to attend the conference and to attendees who want to relive the excitement or check out companies they missed.

In addition to the "Who’s at Google I/O" guest posts you may have seen from some of our developers on this blog, we’ve created video case studies from 19 of the companies that demoed their products in this year’s I/O Sandbox. These videos highlight innovations that span the entire range of Google product areas, from Android to Google Apps and Google Web Toolkit to Google TV.

Did you know:

• that CardinalCommerce is working with Google to enable alternative payments on the web and mobile devices?
• that you can see what your town looked like in the 1800’s using HistoryPin’s photo layer on Google Maps?
• that you can now play Angry Birds in Chrome? (OK, you probably knew that!)

Here are a few videos to get you started:







Watch the full playlist of videos here. As always, you can visit Google Code to learn about Google technologies you can use to build your own amazing new product.

Becky Chappell is an Associate Product Marketing Manager on the YouTube Product Marketing team, but she’s been spending 20% of her time with the super awesome Developer Marketing team. When she isn’t at work, Becky likes to test out new restaurants in San Francisco and attempt to replicate tasty recipes in her own kitchen.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you:
By Jeremy Glassenberg, Platform Manager, Box

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


During the day 2 keynote of Google I/O, I was excited to see Box's integration with the Chromebook's file browser handler getting demoed on the big stage. The integration makes local files and files you encounter on the web easily accessible to cloud services inside Chrome OS.

Chrome's file browser handler utilizes the new HTML5 file system API, designed to enable web applications to interact with local files. This API lets web applications read files, edit files, and create new files within a designated local space on a user's machine. This includes creating binary files for application data, and in Box's case, accessing user-created files to let people easily move their content to the cloud.

As mentioned during the Google I/O keynote, the integration between Box and the Chrome OS file browser handler only took our team a weekend to build. We were able to build the integration quickly because of the simplicity of both Chrome's file browser platform and Box's API, both of which were designed to make content integrations like this easy for developers to implement.

In this case, the Quick Importer tool from the Box API made the entire development process just a few steps:

1. We created a Chrome extension manifest to work with Box.

{
 "name”: "Box Uploader",
 ...
 "file_browser_handlers": [
     {
      "id”: "upload",
      "default_title": "Save to Gallery", // What the button will display
      "file_filters": [
       ]
     }
   ],

2. In the Chrome manifest, we specified the relevant file types to which the service applies. In our case, that's most file types, as seen below. Specialized services may just want certain types, such as images for Picasa.

"file_browser_handlers": [
     {
      "id": "upload",
      "default_title": "Save to Box",
      "file_filters": [
       "filesystem:*.*"
       ]
     }
   ],

3. With some JavaScript code connecting to the file browser handler, we set up a way to upload files through Box’s Quick Importer.

var fm = new FileManager();
fm.uploadServer = 'https://www.box.net/<...>';

if (bgPage && bgPage.filesToUpload.length) {
 var entry;
 while(entry = bgPage.filesToUpload.pop()) {
   entry.file(function(file) {
     fm.uploadFile(file);
   });
 }
}

That's actually all there was to the integration.

Once the file is uploaded to the Box API's Quick Import URL, our page is displayed to authenticate the user, to let the user select a Box folder to save the file, and then to upload the file.


While such an integration can be customized through our API, our Quick Import provided an easy and fast means to connect the platforms. Developers can customize the integration by using direct calls to our API, and take advantage of additional features such as automatic sharing, if they prefer.

Thanks to the simplicity of Chrome's file browser handler and some extra tools in the Box API, our development time was very short (just a weekend), but it could have actually been even quicker. We had a couple of unusual complications that weekend:

1. The Google Chrome team was still experimenting with the file browser, so development from both sides was happening in parallel, which can be a bit tricky. Now that the file browser has been thoroughly tested, you should have an even easier time.

2. I took my girlfriend out a couple times, since her final exams were coming up soon afterward. I love you, Hayley!

Once the content has been uploaded to Box, it’s accessible to many Google services, including Gmail, Google Docs, and Google Calendar, through additional integrations on our site with Google Apps. Ah, the wonders of open platforms.


Jeremy Glassenberg is the Platform Manager at Box, where he oversees partner integrations, API and platform product management, and Box’s community of several thousand developers. In addition to managing Box's developer platform, Jeremy is a part-time blogger at ProgrammableWeb, and a contributor to several open-source projects.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you:
By by Gerardo Capiel, VP of Engineering, Benetech

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.


Benetech is a different kind of technology company, where we measure our success not on ROI, but Return to Humanity. Benetech is a non-profit organization that builds software solutions to address large scale and global social needs in literacy, human rights and the environment. Many of our software solutions are delivered via an open source model.

One of our latest literacy projects has been to develop an Android-based book e-reader for people with print disabilities. Print disabilities, such as blindness, paralysis, or dyslexia, effectively prevent a person from reading traditional print books. Many of those people qualify to have free or inexpensive access to books thanks to an exemption in U.S. copyright law called the Chafee Exemption. Bookshare, one of Benetech’s largest solutions, provides over 100,000 e-books in the accessible DAISY format (similar to ePub) to over 130,000 Chafee-qualified people in the U.S. Once downloaded from Bookshare, DAISY books can be consumed using Assistive Technology (AT), which employs Text to Speech technology (TTS), electronic refreshable braille, or large fonts for low vision users. Bookshare was originally built 10 years ago on a PHP architecture, was migrated to a Java/Hibernate/MyBatis framework and we recently migrated the content repository to S3.

Bookshare has a public REST-based API, which enables AT developers to directly integrate their applications with our API. Through the API, an AT application can enable a user to directly search for books, browse books based on category or recently added books and download a book packaged up as either a DAISY file or a BRF file commonly used by an electronic refreshable Braille display, such as HumanWare’s BrailleNote. Being able to directly download from the AT application simplifies the potentially frustrating experience of having to manually transfer the books from a PC to the AT software or device. The API supports anonymous use, which provides access to freely available books and open educational resources that have no copyright restrictions. Only qualified Bookshare members can access the copyrighted books and periodicals. To learn more about the Bookshare API and obtain a developer key, visit http://developer.bookshare.org/.

Recently Benetech challenged a group of volunteers to build a free, open source, mobile and accessible e-reader which leverages the Bookshare API. The volunteers chose to extend FBReaderJ, a popular open source e-reader for Android which leverages Android’s TTS API (android.speech.tts.TextToSpeech). The project is a work in progress, but so far the volunteers have added DAISY format support and Bookshare API integration. They are now working on improving the accessibility of the application and are evaluating different user interaction experiences to making it easy for print disabled users to access books. To learn more about Android accessibility, check out http://eyes-free.googlecode.com/ and to check or contribute to the project visit http://github.com/amahule/fbreaderj.

Ultimately, we believe this Android e-reader could also benefit people who don’t qualify under Chafee, but who have other disabilities, such as Attention Deficit and Hyperactivity Disorder (ADHD), which makes it hard for them to enjoy printed or even traditional e-books. Furthermore, TTS technology and the Google Translate API may help us use inexpensive Android devices to distribute valuable knowledge locked up in print to illiterate populations in developing countries. Accessing knowledge for illiterate populations will be critical to the success of emerging democracies.

We welcome ideas you may have about our app or Benetech in general. We particularly welcome anyone interested in contributing product development skills to our Android e-reader project or any other open source projects Benetech is working on regarding literacy, human rights or the environment. To learn more about how you can volunteer your skills and time, please go to http://benetech.org/join_us/volunteer_opportunities.shtml.


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

Gerardo Capiel is a two-time Internet entrepreneur turned social entrepreneur. When he's not geeking out for humanity, he's looking for inside tips on the best food in San Francisco.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you:
By Jason LeBrun, Senior Android Engineer at doubleTwist

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.

One of the most exciting aspects of Google's Android platform is the rapid release pace, so support for cutting-edge technologies can be included in the platform early on. As engineers, we're excited about such features, because we like to tinker and test the limits of new technologies. But the real challenge is using these new capabilities to integrate easy-to-use features for end-users, so that everyone can be excited. The introduction of the Near-Field Communication (NFC) API in Android 2.3, accompanying the release of an NFC hardware feature in Google's Nexus S, gave us the opportunity to do just that.

NFC is meant to send and receive small amounts of data. This data can be read from passive (non-powered) devices (e.g. credit cards or interactive posters), or active devices (e.g. payment kiosks). NFC can also be used to communicate between two NFC-equipped devices thanks to a protocol introduced by Google which defines a way for two active devices to exchange NFC messages that follow the NFC Data Exchange Format (NDEF) specification. This protocol (NDEF Push Protocol (NPP)) is implemented in Android 2.3.3 and beyond.

The NPP is very simple: it allows us to send an NDEF message to another device, which will then process the message as if it had been read from a passive tag. Thus, to understand how to use NPP, we need only to understand the NDEF message. An NDEF message is a collection of NDEF records. An NDEF record is a short header describing the contents of the record’s data payload, and then the data payload.

This new NFC/NPP capability enables the exchange of a few hundred bytes of information in a well-defined format between devices, using proximity as a method for instigation and authentication. In other words, we can now share a small amount of data between two devices without going through the normal steps of pairing or association that are required by more conventional (and higher-bandwidth) avenues like Bluetooth or WiFi—the fact that the two phones are in close proximity is enough evidence to convince the NFC software that the devices are eligible to receive information from each other.

The NFC API for Android handles all of the details of receiving and parsing NFC messages. It then decides what to do with the message by investigating the intent filters registered for applications on the device. In some cases the messages may have characteristics that can lead to finer-grained dispatching. In the case of an NDEF message, you can register for NFC messages at varying levels of detail: from as vague as any NDEF message to as detailed as an NDEF message containing a URI matching a given pattern. A pleasant result of this approach is that the operating system can have "catch-all" applications for messages that have unknown details.

Let’s consider a possible application of the NFC technology in the context of the doubleTwist app. If you’re listening to a song and you want to share the details of the song with your friend, how can NFC help with this? Well, we can use NFC to bundle up a small bit of information about the song in a well-defined format, which the other phone can then parse and use to display information about the song. We will pass the metadata in a single NDEF Record containing a JSON object.

To ensure that our message is routed to doubleTwist on the receiving phone, we rely on Android's ability to dispatch messages based on the data type of the payload, signaled by setting the the type name field to TNF_MIME_MEDIA. This indicates that the type field of the NDEF record should be a MIME type as specified by RFC2046. To take advantage of this capability, we create our own custom MIME type to use in the type field. Since the NDEF message must be composed of bytes, we’ll also need to convert the strings into byte arrays. The code for all of this looks like this:

//Assume that musicService is an interface to our music
  //playback service
  JSONObject songMetadata = new JSONObject();
  String title = musicService.getCurrentTrackTitle();
  String artist = musicService.getCurrentTrackArtist();
  String album = musicService.getCurrentTrackAlbum();
  songMetadata.put(“title”, title);
  songMetadata.put(“artist”, artist);
  songMetadata.put(“album”, album);

  String mimeType = "application/x-doubletwist-taptoshare";
  byte[] mimeBytes = mimeType.getBytes(Charset.forName("UTF-8"));
  String data = songMetadata.toString();
  byte[] dataBytes = data.getBytes(Charset.forName("UTF-8"));
  byte[] id = new byte[0]; //We don’t use the id field
  r = NdefRecord(NdefRecord.TNF_MIME_MEDIA, mimeBytes, id, dataBytes);
  NdefMessage m = new NdefMessage(new NdefRecord[]{r});

Similarly, our application registers an Intent filter to define the Activity that will handle NFC messages that match this mime type. So, when another phone running doubleTwist receives our message, doubleTwist will have priority in processing the message. To do this, we add an <intent-filter> element to AndroidManifest.xml's entry for the activity that should launch to handle this NDEF message:

<activity name="SongInfoShare">
    <intent-filter>
        <action android:name="android.nfc.action.NDEF_DISCOVERED" />
        <data android:mimeType="application/x-doubletwist-taptoshare" />
        <category android:name="android.intent.category.DEFAULT"/>
    </intent-filter>
</activity>

The SongInfoShare activity will be started whenever the NFC radio receives our special message from another NFC-capable phone. In the onCreate method for this activity, we can check the action for the intent that started to activity to verify that it’s the NDEF_DISCOVERED action, and then use the normal intent helper methods to get the NFC message data from the Intent. Here’s what the code will look like for our info-sharing example:

public class SongInfoShare extends Activity {
  …
  public void onCreate(Bundle b) {
     if(android.nfc.ACTION_NDEF_DISCOVERED.equals(getIntent().getAction()) {      
        Parcelable[] msgs = 
            b.getParcelableArray(NfcAdapter.EXTRA_NDEF_MESSAGES);
   if(msgs != null && msgs.length > 0) {
               NdefMessage m = (NdefMessage)msgs[0];
               NdefRecord[] r = m.getRecords();
               JSONObject sharedInfo = null;
               if(r != null && r.length > 0) {
               try {
                   String payload = new String(r[0].getPayload());
                   sharedInfo = new JSONObject(payload);
               } catch (JSONException e) {
                   Log.d(TAG, "Couldn't get JSON: ",e);
               }
          }

   //At this point, we can use the contents of 
   //sharedInfo to set up the contents of the activity.

So, now we’re able to easily pass along song information to a friend by simply bringing the NFC radios close together. No cutting, pasting, tapping, or searching for options in menus!

So, what happens if our friend isn’t running doubleTwist? Well, the stock Android NFC handler app can help us. It will display any text or link records contained in the NDEF message it receives. So, for example, we can also share a pre-formatted link that will do a Google search for the song information. To achieve this, we can modify the end of our first code example as follows:

r1 = NdefRecord(NdefRecord.TNF_MIME_MEDIA, mimeBytes, id, dataBytes);
String query = UrlEncoder.encode("\""+artist+"/" /""+title"\"", "UTF-8");
String searchLink = "http://www.google.com/?q="+query;
byte[] searchBytes = data.getBytes(Charset.forName("UTF-8"));
NdefRecord r2 = new NdefRecord(
      NdefRecord.TNF_ABSOLUTE_URL, searchBytes, id, searchBytes);
NdefMessage m = new NdefMessage(new NdefRecord[]{r1, r2});

Now, in the case where the receiving user doesn’t have doubleTwist installed, they will at least be presented with a link that they can click on to begin a Google search for more information about the song.

The first version of Google’s NDEF Push Protocol API has allowed us to bring some novel enhancements to our app using one of the newest available handset technologies. We are looking forward to further development of device-to-device NFC APIs that will allow even richer inter-device communication using just a tap!

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

Jason LeBrun is Senior Android Engineer at doubleTwist, a digital media startup based in San Francisco. doubleTwist was co-founded by Jon Lech Johansen and Monique Farantzos in 2007 with the mission to create a unifying media platform that enables users to enjoy and organize their media across all their home devices. Android, which launched later that year, has enabled doubleTwist to deliver on this promise.

2013, By: Seo Master

Seo Master present to you:
By Xavier Damman, co-founder of Storify

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.


Storify is part of the Google I/O Sandbox. Please come say hi to find out more about how you can leverage our APIs so your users can remix your content to create stories to share on social networks.

Storify provides a super simple drag and drop user experience to create stories using elements from the web: tweets, YouTube videos, Facebook updates, SlideShare presentations, audioboo files, and so on (see Storify in action here). This post explains how we incorporate videos in Storify using YouTube Data API and Player API. All the code snippets are in JavaScript. In fact, our full stack is in JavaScript: we use NodeJS and MongoDB which we think is an über cool mix.


The source of the source

To create a Storify source, we need to be able to get a feed of results using JSONp (basically JSON with a callback function so that you can do cross domain calls; from the YouTube API perspective this is the JSON-C format). For YouTube, the main search API endpoint looks like this:

request: function(formdata) {
   return {
      'url' : 'http://gdata.youtube.com/feeds/api/videos',
      'params': {
         'v'  : 2,
         'max-results' : 20,
         'alt'  : 'jsonc',
         'q'  : formdata.keywords
       }
    };
  }

This function is called when the user clicks Submit in the search tab of the YouTube source in the Storify Editor. The main controller executes the request and sends the JSON result to the results method, which returns an array of normalized results:

results: function(json) {
 
   if (json.data && json.data.totalItems && json.data.totalItems == 0) {
      throw "No results found";
      }
  
      var videos = json.data.items;
      var results_array = [];

      for (var i = 0; i < videos.length; i++) {
            var normalizedResult = {
               permalink   : 'http://www.youtube.com/watch?v='+videos[i].id,
               source  : 'youtube',
               elementClass : 'video',
               metadata  : videos[i],
               thumbnail   : videos[i].thumbnail.sqDefault,
               title: videos[i].title,
               description  : videos[i].description.substr(0,140),
               author: {username: videos[i].uploader },
               created_at  : videos[i].uploaded,
    oembed: {html: '<iframe id="youtube-'+videos[i].id+'" type="text/html" width="360" height="294" src="http://www.youtube.com/embed/'+videos[i].id+'?enablejsapi=1&origin=storify.com" frameborder="0">'
               }};
         
               results_array.push(normalizedResult);
      }
  return results_array;
   }

Thanks to this normalized representation of a story element – in this case, it’s a video object – we can build an object-oriented story as the user drags and drops any of these elements. This technique has multiple benefits: we maintain attribution to the original content creator, and we can track the content as it spreads across the web (how many times it has been seen and from where).

The story element also provides the oEmbed HTML code. This is used to render the video embed when the video is added to the story. For that purpose we use the YouTube Player API with their new iframe embed.

Story.json

We have a very simple way to get any data out of our platform: just append .json to any storify.com URL and you get the JSON representation of the content of that page.

For example:

• http://storify.com/latest.json?topic=googleio returns the latest stories with the tag #googleio
.
• http://storify.com/xdamman.json returns the user object and the user’s latest stories.
• http://storify.com/xdamman/googleio.json returns the story object of the story “GoogleIO” of xdamman. You can use this to easily filter the elements of the story to retrieve only the YouTube videos of a given story and create a fancy HTML5 visualization (see the slideshow or this version). You can see some open source examples at http://github.com/storify/templates.

Add the Storify Editor to your site

The Storify Editor can be called in an iframe. You just need to provide a callback parameter, like this: http://storify.com/story/new?callback=yoursiteurlcallback. The user will be asked to authenticate with Twitter and then will be able to create a new story. Once the user is done and hits “Publish”, we call you back, passing you the permalink of the new story created:
yoursiteurlcallback?permalink=storyPermalink.

You can then either fetch the JSON of the story by appending “.json” to the storyPermalink or you can embed the story by loading <script src=”storyPermalink.js”></script>. This is a great way to provide your community with a way to create stories right from your site.



This is only the start. We plan to open a Sources API so that any developer can build a source for any service. Please come see us at our booth at the Google I/O Sandbox if you’re interested in joining our developer community. And check out this article in the New York Times to learn more.


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

Xavier Damman is the co-founder of Storify. He is also the founder of HackDemocracy, a community of hackers who want to improve our democracies using technology.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you:
By Austin Shoemaker, CTO, Cooliris

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.

At Cooliris, we develop media applications targeting two broad categories – web applications that run in any standards-compliant web browser, and native applications that target specific platforms with tailored user experiences (e.g. iOS, Android, Windows, Mac OS X).

When we developed the Cooliris Extension for Google Chrome, we set out to create an efficient and visually stunning media browsing experience for the web. To deliver on this promise, we developed a native runtime specialized for multiple operating systems and browsers. While we were delighted with the result, the cost of developing native code for multiple platforms was significant. Ideally we could target a single cross-platform API that provided the performance, flexibility, and native feel of platform-specific code.

The new generation of high-performance graphics APIs supported by Google Chrome enables developers to create cross-platform web applications with a presentation layer that looks and feels more like a native application. Our latest Chrome extension, Image Search by Cooliris, leverages these APIs to provide an immersive visual search experience. The following technologies were key to making this product possible:

1. WebGL: The ability to render our user interface with OpenGL ES enabled us to recreate our original 3D Wall experience without the use of plug-ins. Because it is a web standard, our extension is already available on both Windows and Mac versions of Google Chrome with no additional effort on our part. The new requestAnimationFrame API enables the app to render frames only when the display refreshes, significantly improving performance and power usage.
   
2. Google Image Search API: The AJAX search API brings a rich source of relevant content into the wall. Users begin typing in the search box and instantly see results appear on the wall, allowing for effortless discovery and navigation.

Now that we have built the Image Search by Cooliris extension, we are using next-generation web APIs to push the envelope even further. LiveShare, our next-generation communication platform, is built to take advantage of these capabilities from the beginning – for example, the demo of our upcoming product built on WebGL already uses Chrome's file drag-and-drop API to optimize upload performance.

We have never been more excited about the potential of the web platform to deliver great applications – with HTML5, WebGL, and other emerging standards, it has become possible to create products that rival the performance and user experience of native software.


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

Austin Shoemaker is CTO and co-founder of Cooliris. Austin studied Computer Science at Stanford and leads product development for the Cooliris platform. Previously, Austin worked at Apple developing consumer applications.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you:
By Steve Jacobs, President, IDEAL Group, Inc., and CEO, Apps4Android, Inc

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.


IDEAL Group's Android Development Team has developed and released several apps in the Android Market. In this post, we'll highlight three of our apps which capture some of the best aspects of developing on Android.

IDEAL Magnifier


Android smartphones can have amazing hardware, and the platform gives developers the ability to tap into that power. Traditionally, handheld video magnifiers have been standalone, dedicated, hardware devices that can cost hundreds of dollars. Thanks to Android's Camera APIs, we're able to offer similar functionality in the form of a free, open source app.

In addition to using Android's zoom and flash features to make things easier for our users to see, we also enable our users to apply color effects such as converting everything to monochrome and even inverting the colors to improve contrast. Despite the wide variety of Android devices available, we found it relatively easy to support multiple devices since Android enables developers to check what the maximum zoom level is and what color effects are supported. Here's a YouTube video demonstrating IDEAL Magnifier in action.

IDEAL Item Identifier including Talking Barcode Maker


Thanks to Android's Intents system and its MediaRecorder and Text-To-Speech (TTS) APIs, we were able to produce an open source app which turns a user's phone into a talking barcode reader. Talking barcode readers enable blind and visually impaired users to scan the barcode of a product and hear what that item is. In addition, many of the higher end models offer the ability to let users create their own barcodes which they can stick onto items. Unfortunately, like video magnifiers, these devices have traditionally been quite expensive.

We solved the problem of detecting and reading barcodes without spending any development time by simply delegating this task to the ZXing Barcode Scanner. Once we get the UPC code of a product, we do a lookup of that UPC and speak the name of that product.

For custom labels, we record what the user is saying and save it to a file locally. We then use the Send Intent to enable users to email themselves a QR code which contains the automatically generated filename of that recording so that we play back that file when users scan this code. Users can print out the QR code on any sticky label, and voila, their very own custom label. Here's a video demonstrating IDEAL Item ID in action.

Vista Center

The Vista Center is a Palo Alto, California-based organization that helps the blind and visually impaired. We volunteered to create an Android app for them to help users access their educational materials which include topics such as how to use ticket machines and how to set up Android phones for accessibility.

This turned out to be a much easier project than expected, thanks to Android's accessibility features and the strong open source culture that is part of the Android platform's DNA. Specifically, we were able to take advantage of the Google Accessibility Team's I/O challenge which encouraged contestants to open source their submissions. We modified the ccTube app so that it always does a search on startup for videos from the Vista Center, and since Android has accessibility built right into the platform, we didn't need to do anything special to make it work with the TalkBack screen reader.

(Hat tip to Google's Charles L. Chen for helping us connect with the Vista Center and pointing us to Google I/O's Accessibility Challenge, and to Casey Burkhardt, who wrote ccTube and open sourced his code.)

Android is a tremendous platform for building tools that empower people. We're very excited by the fast pace of Android evolution and can't wait to see what the next iteration of this wonderful platform will have to offer.


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

Steve Jacobs’ greatest passion is to enhance the independence, quality of life, education and mobile communications experiences for tens of millions of consumers with disabilities, senior citizens (like Steve), people who never learned to read, and everyone else.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you:
By Ron Zalkind, CTO and Co-Founder, CloudLock

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.


At CloudLock, we're all about cloud data protection. When we decided to build CloudLock for Google Apps, we had three main challenges to solve:

1. Security of data - No matter which system you use for governance, compliance, and access controls, you want that data to be safe.
2. Enterprise scalability - By nature, many of the companies facing data governance and regulatory compliance requirements are larger organizations. Because of that, we needed to build CloudLock with the largest Google Apps customers in mind from day one.
3. Low administrative overhead - We wanted to be able to make the most effective use of our development resources. With App Engine, we spend time building apps rather than managing infrastructure.

Why App Engine?

After researching all the choices available to us, we concluded that Google App Engine was the right choice for us.

1. Data stays within the Google infrastructure - Since CloudLock classifies document sharing permissions to help companies control who has access to what and what is accessible to whom, the location of this highly sensitive data is paramount. Using Google App Engine lets us scan, analyze and present information to our customers natively within the Google infrastructure without any of the data leaving to a third party.

Google's datastore had the attributes we were looking for in a persistent storage solution. It offers a high replication option for high reliability, and since it is implemented on top of BigTable and Google's distributed file system, it runs on the same core infrastructure that powers other Google services like Gmail and Google Apps.

CloudLock customer Brian Bolt from Boise State University put it best, saying "Our security team appreciates the fact that the CloudLock solution is developed and hosted on the Google App Engine platform; and since CloudLock is powered by Google’s App Engine, our data never leaves Google’s Cloud Infrastructure."

2. Scaling with App Engine is easy - While being able to handle the largest Google Apps customers was a top concern, being able to do so on an ongoing basis was another issue we had to solve. Using the Google App Engine Task Queue service, CloudLock is able to analyze massive amounts of data continually. App Engine makes it very easy to start as many background tasks as needed to deal with bursts of load.


The Google Apps Marketplace

The Google Apps Marketplace gives Google Apps customers access to hundreds of applications to extend the capabilities of the core productivity suite. Installing an app from the marketplace is seamless, with a wizard-like interface that makes apps immediately available in a few clicks. The installation securely white-lists the app and grants access to specific domain resources such as Google Docs.


Google’s App Engine Users service allows application developers to easily integrate their app with Google’s account management system (Google account or Google Apps accounts) and OpenID for Single Sign-On. Using the Users service and the marketplace installation we were able to deliver an app that is very easy to install into a domain and gain secure access into the domain's data.

By choosing Google App Engine and the Google Apps Marketplace, we were able to create an application that keeps our customers’ data secure within the Google infrastructure, meets the scaling challenges of the largest Google Apps users, and is immediately and easily available to users.

CloudLock for Google Apps is available directly from the Google Apps Marketplace and runs on Google App Engine.

Update 7:50 AM: This blog post was modified to correctly represent App Engine's certification state. As of May 2011, App Engine is pursuing SAS70-II certification to align it with the other products in the Google Apps suite.

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

Ron Zalkind is the CTO and a Co-Founder of CloudLock, runs the Boston Google App Engine User Group, and has been known to roll up his sleeves and write code while blasting Jay-Z in his headphones.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you:
By Webb Brown, Co-Founder of DayZipping

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.


We launched DayZipping in July 2010 to help people easily find day trip ideas. Before starting the project we conducted an extensive search to find the most suitable web technologies. When evaluating our options we had two priorities that eclipsed all others. First, we wanted to minimize page load times, because we believed our consumer engagement (photo views, rapid spatial searches, etc.) would be strongly impacted by site performance. Part of this requirement was offering a snappy desktop-like experience for certain sections of our site. Secondly, we wanted an environment that didn't hinder our ability to iterate quickly across our entire web platform.

Below are the key factors that lead us to believe that Google Web Toolkit (GWT) is the best tool for the job. Also, we have included evidence of how GWT features have helped us accomplish these goals:

Inherent GWT Efficiencies. The GWT project structure comes chock full of performance benefits that are practically free. Its compilation process significantly reduces code size by renaming variables and inlining method calls when possible. The bootstrapping project structure permits perfect caching of browser-specific implementations by generating deployment files based on the MD5 hash of file contents. The only cost for these performance improvements is the time spent compiling code when deploying production releases, which for us amounts to a marginal five to ten minutes per week.

Resource Bundling. GWT allows you to reduce round trip times by bundling css, image, and text resources into initial page requests. Browser-specific implementations and perfect cacheing mechanisms are all managed behind the scenes. We've used this to bundle many of our static images and in certain cases removed up to 20 fetch requests on a single page.


Code Splitting. The ability to seamlessly split deployed Javascript into logical chunks has greatly improved our user experience. Google released code splitting after we began development of DayZipping, so we were able to analyze results independent of large feature changes. Implementing code splitting reduced our initial fragment download by approximately 100K, which equated to a 40% decrease in size for most browsers. This change in initial download time decreased our bounce rate by approximately 20% on most pages.

Java Tools. The tools available for GWT development have allowed us to stay nimble despite amassing a substantial code base for a two person development team. Eclipse's refactoring tools have arguably played the largest role in our ability to quickly make changes across the project. Being able to make logical adjustments as well as renaming entire functions or classes without having to track down all references has saved us considerable time relative to a Javascript environment. Eclipse syntax recognition and code completion tools make touching dusty sections of our code more palatable. Having the power of a JUnit test suite gives us the confidence to deploy these changes as rapidly as we could imagine. During these rapid iterations, the GWT perfect caching mechanisms relieve the risk of users being stuck with stale content.


Last year our initial hypothesis of a strong negative correlation between page load times and user engagement received compelling support. We made GWT compiler flag changes that gave us an immediate ~10% performance improvement. (You can explore performance gains by experimenting with the various compiler flag options shown here and analyzing the results.) This particular enhancement drove a nearly 1 to 1 increase in user engagement, pushing average pageviews per visit above 11. These engagement improvements have directly impacted conversion rates, which as a consumer startup is arguably our most important operating metric.

GWT has met our initial requirements with high marks. We genuinely believe that we would have been unable to accomplish these tasks as effectively with any other framework. Come visit our exhibit at Google I/O to hear more about the details of our experience.


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

Webb Brown uses his background in investment banking and software development to do a little bit of everything at DayZipping. He spends his free time outdoors and traveling, all while trying to complete as many trips on DayZipping as possible.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you:
By Rik Arends, CTO of Ajax.org / Cloud9 IDE

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.


Cloud9 is an online IDE for JS, Python, PHP and Ruby development. By placing all your code in the cloud, you can access your code anywhere, anytime and on any device. But what if you’re not online?

Working with web applications offline has been a difficult problem to solve. Traditional web applications required all the logic for HTML generation and user interaction to be located on a remote server. The "go offline" feature in some of the earliest browsers was hardly more than caching static content and could not deal with much interactivity.

Since the advent of AJAX, many websites and apps have moved to using JavaScript heavily on the client side, providing a much richer and smoother user experience. Now the ability to run a web application in full offline mode is within reach.

Cloud9 IDE is one such application. Built from the ground up to have the user interface running in the browser, the server application provides Cloud9 with WebDAV for file I/O, and APIs for project provisioning and authentication. For a rich offline experience, we would need to make the WebDAV API somehow available offline.


The first step in Cloud9’s offline experience has been to implement the HTML5 offline manifest, also known as Application Cache, to make sure the application loads smoothly while offline. The next step is to provide offline workspace synchronization using the new API provided in Google Chrome for local file system I/O. The Chrome file system implementation, based on the current W3C working draft, allows web applications to have access to the device (through a sandboxed file system). So even if you are marooned on a distant planet and disconnected from the collective, you can still work on your code.

Getting access to the local file system is very easy. The API method to call is the obviously named webkitRequestFileSystem, which takes options to create either a temporary or permanent file system, and to define the size of the sandbox location. The difference between temporary and permanent is quite clear, with temporary acting only as a cache: the files may disappear when the browser needs to free up disk space. Once the file system has been successfully created, you can do all the operations you expect, such as creating, deleting, copying, and moving files and directories.

More information on the full HTML file system API can be found at HTML5Rocks, which includes a detailed entry on what types of file system operations you can achieve with the API.

We are showcasing this feature at Google I/O, and will release this feature later this month on http://c9.io. We are working on creating a nice integration with Google App Engine too, so you can develop and deploy entirely online.

Update 5/11: Corrected information about temporary files; removed paragraph about having to start the browser with a special flag.

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

Rik Arends has been a developer for 15 years and now manages the development team behind Cloud9 IDE.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you:
By Dan Mesh, Vice President of Engineering at Evite

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.


Evite is one of web's oldest social planning services. Since the launch in 1998, Evite has delivered over a billion party invitations. Although it has served us well, after ten years of operation it became necessary to replace the aging platform, and position Evite for another decade of successful party planning.

The reengineering effort took well over a year. Our development team replaced Java with Python and saw a significant increase in developer productivity. However, dealing with a ten year-old Oracle database remained a challenge. To overcome scalability limitations and inflexibility of a large relational DBMS, we designed and implemented a proprietary data store. We conducted a series of A/B tests and gradually started migrating production traffic to the new system.


Our initial motivation to use Google App Engine was fast provisioning. We introduced App Engine as a temporary solution while we increased scale and optimized our proprietary data store. However, once we imported user profile data and put App Engine backend services in production, we never looked back.

Importing a large data set of user profiles from Oracle RAC into App Engine was challenging at first because we had to perform a bulk import and then keep the data synchronized between the two datastores. As we developed our data synchronization tools we gained better understanding of the API and performance characteristics of the App Engine datastore.

Once we synchronized profile data and enabled production traffic, App Engine really started to impress. We would watch our daily traffic grow and observe App Engine’s automatic scaling in action. Additional server instances would come online to meet increased demand and disappear as traffic lowered, without any sysadmin intervention. Despite our proficiency in the use of cloud computing resources and system automation, it was never this easy to provision new servers. As Grig, Evite’s devops guru, likes to say "It's not in production until it's monitored and graphed." App Engine’s dashboard automatically manages instances and graphs system usage data.


Following our positive experience with Evite profiles, we have continued to use App Engine for other services. Occasional frustrations with elevated error rates on the Master/Slave Datastore disappeared as we switched to the High Replication Datastore. At this point we see no technical obstacles to using App Engine more extensively. Architectural decisions and best practices implemented by the App Engine team are very well aligned with the choices we made in designing Evite’s new platform. This makes it easy to deploy additional services and data sets to App Engine.

The real obstacle to using App Engine exclusively for most Evite services is risk management. As reliable and cost-effective as App Engine has been for us, it is difficult to depend completely on a single vendor/service provider. To ensure availability of our application we use multiple cloud providers. Unfortunately, this strategy prevents us from using certain App Engine features and API's because we do not have adequate replacements for them in other deployment environments.

Evite’s new platform built on Python, NoSQL and App Engine has been a success. Our new web application has been well received by users, and our first iPhone app is receiving positive reviews. (Android version is in the works). We look forward to continued use of App Engine for data warehousing, rapid launches of new services and other projects.


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

Dan Mesh is a Vice President of Engineering at Evite. His extended responsibilities include espresso deliveries and release day food orders.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you:
By Jesper Majland, Endomondo Android Developer

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.


Endomondo is a sports community focused on making exercising more fun, more social and more motivating. Android includes great APIs to support adding a social community to an existing application.

Our Android app, Endomondo Sports Tracker, uses the device’s GPS to measure distance and speed while you are doing your favorite distance-based sport. The result can be shared, commented upon and analysed online within the social Endomondo community.

Until recently, the Endomondo community has only been accessible from a desktop web browser. Now we are bringing this community to your pocket.

So far, we have implemented these three feature areas:

1. Find and connect friends.

We use the ContactsContract API to scan the device for local contacts. We then hash-encode the names and email addresses and send them to our servers to see if they match existing members of the community. The result is a list of possible friends already using Endomondo. The user can then send a friend request by clicking on the relevant person.


2. Sync with a cloud service to get updates.

Once the user has added some friends, we can add some content from our cloud service.
The Sample Sync Adaptor API was exactly what we were looking for. First, we created a new Endomondo account using the AccountManager. Our next step was to write our own synchronization manager by extending AbstractAccountAuthenticator. When the user logs in or signs up, our app automatically creates a new account. The new account can be controlled using Android’s built in “Accounts & sync settings” service.

You can find a very good “how to implement” description here: part 1, part 2.

3. Extend the app to access Contact info.

Our in-app friend list now shows a list of all friends in the community, with a short description of the latest activity and a nice profile picture for each.

We use QuickContactBadges to show friends' profile pictures and to quickly pivot to other ways to contact them; perfect for planning a run together!

When our users and their friends add new accounts, the Android ContactsContract framework will automatically merge contacts, adding a very handy feature to our app without us having to do anything!

For implementation inspirations, take a look here: QuickContactsDemo.

We’re just getting started with adding social dimensions to Endomondo. There are plenty more exciting developments in the works. One of them is the ability to send pep talk messages to friends out exercising, directly from the app. You can download our app from the Android Market and try it out for yourself.

Any input or good ideas are more than welcome. Please post your feedback in the comments.


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

Jesper Majland is involved with all parts of app developing from idea, design and implementation to test/release and bug fixing. In his spare time, he tries to get outside to bike, ski or go for a short run.

Posted by Scott Knaster, Editor

2013, By: Seo Master

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 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:
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