The SWF exports of presentations in the Google Documents

Google announcing the deprecation of SWF export functionality for presentations from the Google Documents List API. They are taking this action due to the limited demand for this feature, and in order to focus engineering efforts on other aspects of the API.

Clients currently making the following request to the API are affected by this change.

https://docs.google.com/feeds/download/presentations/Export?docID=1234&exportFormat=swf

We recommend clients currently using SWF exports switch to PDF exports, using the appropriate exportFormat value.

https://docs.google.com/feeds/download/presentations/Export?docID=1234&exportFormat=pdf

They are disabling SWF exports in the coming weeks. Clients attempting to export presentations as SWF after the exports are disabled will receive an HTTP 400 response.

For more information on exporting presentations, see the Google Documents List API documentation. If you have any questions, feel free to reach out in the forums.

Documents List API

 

There are a number of ways to add resources to your Google Documents List using the API. Most commonly, clients need to upload an existing resource, rather than create a new, empty one. Legacy clients may be doing this in an inefficient way. In this post, we’ll walk through why using resumable uploads makes your client more efficient.

The resumable upload process allows your client to send small segments of an upload over time, and confirm that each segment arrived intact. This has a number of advantages.

Resumable uploads have a customizable memory footprint on client systems

Since only one small segment of data is sent to the API at a time, clients can store less data in memory as they send data to the API. For example, consider a client uploading a PDF via a regular, non-resumable upload in a single request. The client might follow these steps:

  1. Open file pointer to PDF
  2. Pass file pointer and PDF to client library
  3. Client library starts request
  4. Client library reads 100,000 bytes and immediately sends 100,000 bytes
  5. Client library repeats until all bytes sent
  6. Client library returns response

But that 100,000 bytes isn’t a customizable value in most client libraries. In some environments, with limited memory, applications need to choose a custom chunk size that is either smaller or larger.

The resumable upload mechanism allows for a custom chunk size. That means that if your application only has 500KB of memory available, you can safely choose a chunk size of 256KB.

Resumable uploads are reliable even though a connection may not be

In the previous example, if any of the bytes fail to transmit, this non-resumable upload fails entirely. This often happens in mobile environments with unreliable connections. Uploading 99% of a file, failing, and restarting the entire upload creates a bad user experience. A better user experience is to resume and upload only the remaining 1%.

Resumable uploads support larger files

Traditional non-resumable uploads via HTTP have size limits depending on both the client and server systems. These limits are not applicable to resumable uploads with reasonable chunk sizes, as individual HTTP requests are sent for each chunk of a file. Since the Documents List API now supports file sizes up to 10GB, this is very important.

Resumable upload support is already in the client libraries for Google Data APIs

The Java, Python, Objective-C, and .NET Google Data API client libraries all include a mechanism by which you can initiate a resumable upload session. Examples of uploading a document with resumable upload using the client libraries is detailed in the documentation. Additionally, the new Documents List API Python client library now uses only the resumable upload mechanism. To use that version, make sure to follow these directions.

Google Custom Maps

Do you love to explore the outdoors with Google Maps but sometimes wish it had the details of a trail map or a tourist attractions map of a foreign city? Do you sometimes wish you could take one of those “You are here” maps with you to help you find places in an unfamiliar environment? Do you prefer maps on your phone rather than on paper?

If you answered “yes” to even some of these questions, you may want to take a closer look at a new Android app called Custom Maps — recently released as open source at code.google.com.

Custom Maps showing a birdwatcher’s location overlaid on a photo of a posted park map.
The Custom Maps app allows for easy creation of digital maps from any map image. The image can be a photo of a paper map, a photo of a brochure map, or a picture of the map posted at a trailhead or at the entrance to an amusement park. It could also be a .jpeg or .png image hosted on the internet or a screenshot of a PDF map. All you have to do is choose two (or more) matching points that are common to both the map image and Google Maps, and Custom Maps can show your GPS location on the map. This makes it an excellent mapping option in situations where data signal is not available like in state parks or abroad, or when alternate map images show details that are not included in Google Maps.

Custom Maps showing a hiker’s location on Mist Trail in Yosemite National Park.
Custom Maps stores the geo aligned map images into KMZ files, which are simply ZIP files containing the geo location information in KML format, and the map image file. This makes it possible to take the map image out of the KMZ file, add some personal markup in the map using an image editor, and put the image back into the KMZ file. As long as the image is not resized in the process, the marked up map image can now display the user’s GPS location.
Custom Maps users can share created geo aligned map images as email attachments or by using QR codes. When a Custom Maps compatible QR code is scanned by a barcode scanner application, users can open the link directly in the Custom Maps app instead of a web browser.
Google has published the source code for Custom Maps under Apache License 2.0 at http://code.google.com/p/custom-maps/. The source code can be studied for examples of how to deal with the following topics on Android mobile apps:
  • dealing with large images in constrained memory environment of mobile devices
  • parsing XML (KML) documents using XML Pull API
  • using the Google Maps Android API and displaying translucent overlays on MapView widget
  • declaring an app as able to handle special URLs and file types so it can be launched by QR codes and so mail applications can direct attachments to it
  • triggering file sharing intents from an app
But Custom Maps is not finished yet. Several new features are planned including distance measurement, marking map locations with icons, making it possible to geolocate map images without Google Maps or data connection, working around the app memory limit to load larger map images, and automatically switching between stored maps based on user’s location and zoom level. Join the open source project to add these and more features to Custom Maps.