Google Maps: The power of Fusion Tables with Dynamic Styling

The Fusion Tables Layer has been one of the most successful new features launched in the Maps API in the last year. We have seen a wealth of fascinating data visualizations that rely on Fusion Tables, such as the Bay Citizen Bike Accident Tracker and the WNYC Police Precinct map.

At Google I/O this week, Simon Rogers of the Guardian joined me and Kathryn Hurley of the Geo Developer Relations team to present some examples of how the Guardian uses Fusion Tables to visualise data for their readers, and introduce some great new features:

Fusion Tables allows you to share large tables of spatial data and render them on a map in a way that performs consistently well across all browsers, on desktop and mobile. The way in which the data is styled on the map, the markers used for points, the colours and stroke widths used for polylines and polygons, can be defined by the owner of the table in the Fusion Tables application, or using the new Fusion Tables Styling and InfoWindows API. However only the owner of the table can define the styling in this way, and styling for any single table is fixed.
 


 

At Google I/O we introduced Dynamic Styling of Fusion Tables layers. This allows the styling rules used for displaying a table in a Maps API application to be defined from JavaScript, and changed dynamically. For example you can use this to switch between rendering different data sets in the same table, or giving users control over which subset of the data is highlighted, as in the below example based on a public table of Chicago Homicides data:

 

In order to ensure the continued reliability of the Fusion Tables layer, we are also introducing some limits on the number of layers that can be used, and the complexity of styling. The Maps API now permits up to five Fusion Tables layers to be added to a map, one of which can be styled with up to five styling rules.

For information and code samples of how to apply dynamic styling to Fusion Tables, see our documentation, and for further assistance I recommend the Google Maps JavaScript API V3 forum. It’s great to see the creative ways in which Fusion Tables Layer is being used, and we hope this new flexibility will drive even more inspiring and informative Maps API applications.

All file types to any Google Account

Over the next few days we will be rolling out an expansion to the feature set of the Google Documents List API. Third-party applications may now upload files of any type to any Google Account. Previously, this was only possible for Google Apps for Business users.

This feature allows developers to roll out their solutions to all Google Docs users. For instance, it’s now possible for developers to build applications that allow all users to back up files from their local hard drive to the cloud. There are a variety of other possible uses for this feature, and some examples include revision control and file distribution. Third-party applications (such as those on the Google Apps Marketplace) can also now use Google Docs as the primary place to store their data without the hassle of creating different solutions for customers of Google Apps for Business versus the free edition of Google Apps.

After they are uploaded, files are available in the Google Docs interface:

To enable uploads for all file types, developers must use the resumable upload feature of the API, and also pass in the ?convert=false URL parameter.

We have also added checksums to all files that are not converted to a native Google Docs format. This means that if you upload a file type we can’t convert, or if you choose not to convert a file to a native format, a checksum is now available to help guarantee the integrity of the file between storage and retrieval.

We are also in the process of adding checksums to all previously uploaded unconverted files. Due to the popularity of uploading unconverted files, processing this backlog will take some time to complete.

We’ve recently made a lot of improvements to the documentation that should make implementing all of this easier. For further help, please have a look in the forum.

Best Practices for Honeycomb and Tablets

The first tablets running Android 3.0 (“Honeycomb”) will be hitting the streets on Thursday Feb. 24th, and we’ve just posted the full SDK release. We encourage you to test your applications on the new platform, using a tablet-size AVD.

Developers who’ve followed the Android Framework’s guidelines and best practices will find their apps work well on Android 3.0. This purpose of this post is to provide reminders of and links to those best practices.

Moving Toward Honeycomb

There’s a comprehensive discussion of how to work with the new release in Optimizing Apps for Android 3.0. The discussion includes the use of the emulator; most developers, who don’t have an Android tablet yet, should use it to test and update their apps for Honeycomb.

While your existing apps should work well, developers also have the option to improve their apps’ look and feel on Android 3.0 by using Honeycomb features; for example, see The Android 3.0 Fragments API. We’ll have more on that in this space, but in the meantime we recommend reading Strategies for Honeycomb and Backwards Compatibility for advice on adding Honeycomb polish to existing apps.

Specifying Features

There have been reports of apps not showing up in Android Market on tablets. Usually, this is because your application manifest has something like this:

Many of the tablet devices aren’t phones, and thus Android Market assumes the app is not compatible. See the documentation of . However, such an app’s use of the telephony APIs might well be optional, in which case it should be available on tablets. There’s a discussion of how to accomplish this in Future-Proofing Your App and The Five Steps to Future Hardware Happiness.

Rotation

The new environment is different from what we’re used to in two respects. First, you can hold the devices with any of the four sides up and Honeycomb manages the rotation properly. In previous versions, often only two of the four orientations were supported, and there are apps out there that relied on this in ways that will break them on Honeycomb. If you want to stay out of rotation trouble, One Screen Turn Deserves Another covers the issues.

The second big difference doesn’t have anything to do with software; it’s that a lot of people are going to hold these things horizontal (in “landscape mode”) nearly all the time. We’ve seen a few apps that have a buggy assumption that they’re starting out in portrait mode, and others that lock certain screens into portrait or landscape but really shouldn’t.

A Note for Game Developers

A tablet can probably provide a better game experience for your users than any handset can. Bigger is better. It’s going to cost you a little more work than developers of business apps, because quite likely you’ll want to rework your graphical assets for the big screen.

There’s another issue that’s important to game developers: Texture Formats. Read about this in Game Development for Android: A Quick Primer, in the section labeled “Step Three: Carefully Design the Best Game Ever”.

We’ve also added a convenient way to filter applications in Android Market based on the texture formats they support; see the documentation of for more details.

Happy Coding

Once you’ve held one of the new tablets in your hands, you’ll want to have your app not just running on it (which it probably already does), but expanding minds on the expanded screen. Have fun!