IT Lesson

Three months ago, we launched Google Drive along with the Google Drive SDK. The SDK allows applications to manage files that users have uploaded to Drive and to integrate deeply in the Google Drive UI. Today, we’ve just extended the SDK to allow developers to interact with native Google Docs types such as Google Spreadsheets, Presentations, Documents, and Drawings.

We now provide an easy way to export native Google documents through the Google Drive API. We also allow native Google documents to be opened directly from within the Google Drive UI using third-party applications.

If your application is already a Drive-installable app, you can enable this feature by checking the Allow users to open files that can be converted to a format that this app can open option in the Google APIs Console under Drive SDK > Import:

When this feature is enabled, your application will show up under the “Open with” menu in the Google Drive Web UI for the file formats you support. Here’s how it works: if your application supports opening one of the possible export formats for the Google document, users will be able to open that Google document with your application. So for instance, if your application is configured to open PDF files, then because Google Documents are exportable to PDF, users will be able to use your application to open those documents as shown below.

When opening a native Google Document with your application from the Google Drive UI, we will pass the following JSON Object in the state URL parameter of the OAuth 2.0 redirect request that is forwarding the user to your website.

 
{
  "exportIds": ["file_id"],
  "action":"open"
}
 

Then you can use the file ID contained in the JSON object to query the Google Drive API and fetch the file’s metadata. Note that the state URL parameter is different when opening regular files as we use the JSON attribute exportIds instead of ids.

Unlike the metadata of regular files which contain a downloadUrl attribute which you can use to download the file’s content, the metadata for native Google documents contains a collection of export URLs. These URLs - one for each supported export format - are listed under the attribute exportLinks, as shown in the HTTP request/response below.

Request:

 
GET /drive/v2/files/<file_id> HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer <access_token>
 

Response:

 
HTTP/1.1 200 OK
Status: 200
...

{
 "kind": "drive#file",
 "id": "<file_id>",
 ...
 "exportLinks": {
  "application/vnd.oasis.opendocument.text": "https://docs.google.com/...",
  "application/msword": "https://docs.google.com/...",
  "text/html": "https://docs.google.com/...",
  "application/rtf": "https://docs.google.com/...",
  "text/plain": "https://docs.google.com/...",
  "application/pdf": "https://docs.google.com/..."
 },
 ...
}
 

You can query any of these export URLs using an authorized request to download the Google document in your prefered export format.

Below is the full list of supported export formats -- and their associated MIME types -- for the different types of native Google documents:

Google Documents:

• Text File (TXT) - text/plain
• Portable Document Format (PDF) - application/pdf
• OpenDocument Text Document (ODT) - application/vnd.oasis.opendocument.text
• Microsoft Word (DOC) - application/msword
• Hypertext Markup Language (HTML) - text/html
• Rich Text Format File (RTF) - application/rtf

Google Spreadsheets:

• Portable Document Format (PDF) - application/pdf
• Microsoft Excel Spreadsheet (XLS) - application/vnd.ms-excel
• OpenDocument Spreadsheet (ODS) - application/x-vnd.oasis.opendocument.spreadsheet

Google Presentations:

• Text File (TXT) - text/plain
• Portable Document Format (PDF) - application/pdf
• Microsoft Office Open XML Format Presentation (PPTX) - application/vnd.openxmlformats-officedocument.presentationml.presentation

Google Drawings:

• Scalable Vector Graphics (SVG) - image/svg+xml
• JPEG Images (JPEG) - image/jpeg
• Portable Network Graphics (PNG) - image/png
• Portable Document Format (PDF) - application/pdf

Please check out the Google Drive SDK documentation if you’d like to learn more, and feel free to ask any questions you may have on Stack Overflow.

Nicolas Garnier profile | twitter | events Nicolas Garnier joined Google’s Developer Relations in 2008 and lives in Zurich. He is a Developer Advocate focusing on Google Apps and Web APIs. Before joining Google, Nicolas worked at Airbus and at the French Space Agency where he built web applications for scientific researchers.

The most challenging part of learning anything new is often simply getting started. Unfortunately, when it comes to programming, the first few minutes (or more!) are often occupied with cumbersome details such as setting up an environment, which results in very little time spent actually writing code. We were certain there must be a better way.

Code School has been doing exciting things with learning to program online. This is why we decided to team up with them to create a way for developers to learn to use the Google Drive API, with no setup required. In the Discover Drive course, you can learn at your own pace from your web browser. You’ll spend less time fussing with coding environments and more time writing code.

To find out what the course is all about, go check it out at Code School. Happy coding!



Cross-posted on the Google Developers Blog.

Greg Knoke Google+ Greg Knoke is a technical writer in the Google Drive Developer Relations Team. Prior to joining Google, he worked as a scientist developing image and signal processing algorithms. His current interests include new technologies, content management, information architecture, cooking, music, and photography.

Editors note: This is a guest post by Thomas Gerber. Thomas is the CTO of Altirnao, the developer of the AODocs document management app on the Google Apps Marketplace. Thomas tells the story of his application and provides some tips for developers considering integrating with Google Apps and launching on the Marketplace. — Arun Nagarajan


Google Drive is increasingly popular in the enterprise, and many organizations would like to leverage it as a replacement for their existing on-premises file servers. Moving physical file servers to Drive provides many benefits, such as reliability, cost-effectiveness and the ability to access the files from anywhere and any device. However, the storage structure of Google Drive, where files are owned by many different users, is significantly different from the centralized organization of a file server, where everything is under the control of a small number of system administrators.

To address this problem, AODocs uses the Google Drive API to automatically transfer the ownership of files to a system account, and thus create a sort of “managed area” within Google Drive. With the Google Drive API, AODocs has complete control over the folder structure and the permissions of files owned by this system account. AODocs can be deployed in one click from the Google Apps Marketplace, which makes our application visible (and easy to try out!) for every Google Apps administrator in the world.



Companies who want to store their files on Google Drive may be concerned about losing control of their data (e.g. access to files being lost when an employee leaves the company) and controlling sharing permissions.

AODocs uses a single system account (i.e. a Google Apps account belonging to the customer’s domain, but not used by any human person) as a “proxy” to control the files. When a Google Drive files is added to an AODocs library, the ownership of the file is transferred to the AODocs system account and the file’s writersCanShare attribute is set to false, so that only AODocs is able to modify the file’s permissions afterwards.

To change the ownership of the file, we check if the system account can already access the file, and then either insert a new “owner” permission on it or use the Permissions.update method with the transferOwnership flag:

public void changeOwner(String user, String fileId, String newOwner) {
   // Find what is the current permission of the new owner on the file
   Permission newOwnerPermission = null;
   PermissionList permissionList = RetriableTask.execute(new DrivePermissionListTask(drive.permissions().list(fileId)));
   newOwnerPermission = findPermission(permissionList, newOwner);

   if (newOwnerPermission == null) {
      // New owner is not in the list, we need to insert it
      newOwnerPermission = new Permission();
      newOwnerPermission.setValue(newOwner);
      newOwnerPermission.setType("user");
      newOwnerPermission.setRole("owner");
      Drive.Permissions.Insert insert = drive.permissions().insert(fileId, newOwnerPermission);
      RetriableTask.execute(new DrivePermissionInsertTask(insert)); 
   } else {
      // New owner is already in the list, update the existing permission
      newOwnerPermission.setRole("owner");
      Drive.Permissions.Update update = drive.permissions().update(fileId, newOwnerPermission.getId(), newOwnerPermission);
      update.setTransferOwnership(true);
      RetriableTask.execute(new DrivePermissionUpdateTask(update));
   }
}

Since all the files are owned by the system account, AODocs completely controls the lifecycle of the file (how they are created, in which folder they are located, who can change their permissions, who can delete them, etc). AODocs can thus provide higher-level document management features on top of Google Drive, such as configuring the retention time of deleted files, limiting external sharing to a whitelist of “trusted external domains”, or recording an audit log of file modifications.

As illustrated in the code snippet above, AODocs relies on the Google Drive API to perform all the operations on the managed files. The main challenge we had when using the Drive API was to properly handle all the error codes returned by the API calls, and make sure we make the difference between fatal errors that should not be tried again (for example, permission denied on a file) and the temporary errors that should be re-tried later (for example, “rate limit exceeded”). To handle that, we have encapsulated all our Google Drive API calls (we are using the Java client library) into a class named RetriableTask, which is responsible for handling the non-fatal errors and automatically retry the API calls with the proper exponential back-off. Here is a simplified version:

public class RetriableTask implements Callable {
[...]
  private final Callable task;

[...]
  @Override public T call() {
     T result = null;
     try {
        startTime = System.currentTimeMillis();
        result = task.call();
     } catch (NonFatalErrorException e) {
        if (numberOfTriesLeft > 0) {
          // Wait some time, using exponential back-off in case of multiple attempts
          Thread.sleep(getWaitTime());

          // Try again
          result = call();
        } else {
          // Too many failed attempts: now this is a fatal error
          throw new RetryException();
        }
     } catch (FatalErrorException e) {
        // This one should not be retried
        Throwables.propagate(e);
     }
     return result;
  }

AODocs is designed to work seamlessly with Google Drive, and our top priority is to leverage all the integration possibilities offered by the Google APIs. We are very excited to see that new features are added very often in the Admin SDK, the Google+ API, the Drive API that will allow AODocs to provide more options to system administrators and improve the experience for our end users.

Thomas Gerber profile Thomas is the CTO of Altirnao. Before founding Altirnao, Thomas has led a team of senior technologists and architects on High Availability/High Performance implementations of enterprise software.

When a file of a common type is uploaded to Google Drive, it is automatically indexed so users can easily search for it in their Drive files. Google Drive also tries to recognize objects and landmarks in images uploaded to Drive.

For instance, if a user uploaded a list of customers as an HTML, XML, PDF or text file he could easily find it later by searching for one of its customer’s name that is written inside the file. Users could also upload a picture of their favorite green robot, then search for “Android” and Google Drive would find it in their Drive:

Metadata such as the file’s title and description are always indexed so users can always find a file by name. However, Google Drive does not automatically index the content of less common or custom file types. For example if your application uploads or creates files using the custom MIME-type custom/mime.type, then Drive would not try to read and index the content of these files and your users would not be able to find them by searching for something that’s inside these files.

To have Google Drive index the content of such files you have to use one of the following two options available when uploading files through the Google Drive API.

useContentAsIndexableText URL parameter

We recently added a way for you to indicate that the file you are uploading is using a readable text format. In the case where your file data format is text based — for instance if you are using XML or JSON — you can simply set the useContentAsIndexableText URL parameter to true when uploading the file’s content to Drive. When this flag is set Google Drive will try to read the content of the file as text and index it.

indexableText attribute

There is a more flexible approach which is to set the indexableText attribute on the File Metadata. You can set the value of the indexableText attribute which is a hidden — write-only — attribute that we will index for search. This is very useful if you are using a shortcut file — in which case there is no content uploaded to Google Drive — or if you are using a non-text or binary file format which Google Drive won’t be able to read.

Have a look at our Google Drive API references or watch our latest Google Developer Live video about the topic to learn more.

Nicolas Garnier Google+ | Twitter Nicolas Garnier joined Google’s Developer Relations in 2008 and lives in Zurich. He is a Developer Advocate for Google Drive and Google Apps. Nicolas is also the lead engineer for the OAuth 2.0 Playground.

Do you like to store photos in Google Drive? You are not alone! Photographs are one of the most common file types stored in Google Drive. The Google Drive API now exposes Exif data for photos, so that Google Drive Apps can use it. The Exif data contains information about camera settings and photo attributes.

Despite being an awful photographer, I love photographing benches, and here is one I took while at the beach. Let’s have a look at some of these new fields for this photo.

When I examine the metadata for this image using a drive.files.get call, there is now a field, imageMediaMetadata, containing the detailed photo information:

"imageMediaMetadata": {
  "width": 2888,
  "height": 1000,
  "rotation": 0,
  "date": "2012:07:08 15:22:25",
  "cameraMake": "NIKON CORPORATION",
  "cameraModel": "NIKON D90",
  "exposureTime": 8.0E-4,
  "aperture": 5.6,
  "flashUsed": false,
  "focalLength": 105.0,
  "isoSpeed": 200
 }

So whether you are just storing your amateur snaps like me, or using Google Drive to store serious photographs, we hope this will be useful information for Drive apps. For example, a photo organizing application will be able to create thumbnail and information views for photos without ever having to download them.

For more information, please visit our documentation, and if you have any technical questions, please ask them on StackOverflow. Our team are waiting to hear from you.

Ali Afshar profile | twitter Tech Lead, Google Drive Developer Relations. As an eternal open source advocate, he contributes to a number of open source applications, and is the author of the PIDA Python IDE. Once an intensive care physician, he has a special interest in all aspects of technology for healthcare

Editor’s note: This is a guest post by Laura Bârlădeanu, lead programmer at MindMeister.
-- Steve Bazyl

MindMeister is a market innovator for providing collaborative online mind mapping solutions. Launched in May 2007, our site has since attracted hundreds of thousands of businesses, academic institutions and creative consumers who have mapped over 100 million ideas online. We were one of a few web applications invited to take part in the Google Drive launch earlier this year.

Requirements

The goal was to provide users with an intuitive integration between Google Drive and Mindmeister that would cover all the cases provided by the Google Drive guidelines at that time:

• Create mind maps directly from Google Drive
• Open mind map files from Google Drive using MindMeister
• Create a mind map file on Google Drive from MindMeister

Aside from these main integration points, we wanted to make use of the SDK and provide many useful Google Drive features, so we added a few more requirements to the list:

• Export all the user’s maps as a backup .zip file on Google Drive
• Import a file from Google Drive using the Google File Picker
• Attach a file from Google Drive directly to a node in a mind map
• Provide users the possibility to share mind maps with their Google contacts
• Provide users with an application setting that would allow them to sync all their mind maps with Google Drive
• Allow Google users opening the same file from Google Drive to collaborate in real time on the mind map directly in MindMeister
• Enable users to login with their Google account without providing any extra information

Authentication and authorization

Google Drive applications are required to use OAuth 2.0 as an authorization mechanism, and are recommended to use OpenID Connect for login. The authorization scope for Drive files is added by default for all registered drive apps. Additionally, the application can require extra scopes that would fit its needs. For our requirements, we needed the following scopes:

• https://www.googleapis.com/auth/drive.file (Drive)
• https://www.google.com/m8/feeds/ (Contacts)
• https://www.googleapis.com/auth/userinfo.profile (User information)
• https://www.googleapis.com/auth/userinfo.email (User email)

However, we didn’t want the user to turn away from our application by being asked for too many scopes straight from the beginning. Instead, we defined sets of actions that required a subset of these scopes:

• [‘drive’, ‘profile’, ‘email’] - any Google Drive action
• [‘profile’, ‘email’] - login with a Google account
• [‘contacts’, ‘profile’, ‘email’] - access the user’s Google contacts

Whenever the user wanted to execute an action that would require more scopes than they initially provided, we redirected them to a Google authorization dialog that requested the extra scope. Upon authorization, we stored the individual refresh tokens for each combination of scopes in a separate model (UserAppTokens).

Whenever the application needed the refresh token for a set of scopes (eg. for [‘profile’, ‘email’]) it would fetch the refresh token from the database which corresponded to a superset of the required scopes (eg. [‘drive’, ‘profile’, ‘email’] would fit for the required [‘profile’, ‘email’]). The access token would then be obtained from Google and stored in the session for future requests.

Challenges

The main challenge we encountered during design and implementation was dealing with the special cases of multiple users (Google users or internal users) editing on the same map which is a Google Drive file, as well as dealing with the special cases of the map being edited in multiple editors. We also had to find a solution for mapping the Google Drive user’s permissions (owner, reader, or writer) to the MindMeister’s existing permission mechanism.

The MindMeister application is registered for opening four types of files: our own .mind format, MindManager’s .mmap format, Freemind’s .mm format, as well as .xmind. However, since these formats are not 100% compatible with each other, there is always a chance of losing more advanced features when opening a file in a format other than .mind. We wanted to provide the user with the possibility to chose whether the opened file would be saved in its original format, thus risking some features loss, or saving the file in MindMeister format. This option should be per user, per file and with the possibility to be remembered for future files.

Solutions

After analyzing the requirements and the use cases, we designed the following architecture:

Out of sync maps and files

Using the revision fields in both Map and DriveData we always know if the map has been edited on MindMeister’s side without it being synced with the corresponding file on Google Drive. On the other hand, the token field from DriveData represents the file’s MD5 checksum at the moment of the last update and is supplied via the Google Drive SDK. So if the file is edited externally using another application than MindMeister, we have a mechanism in place for detecting this issue and presenting the user with a few courses of action.

Handling 3rd party formats

Upon opening a file that has a different format than .mind, the user is prompted with an option dialog where they can chose if they want the file to be saved back in the same format or in MindMeister’s own format. These options are then remembered in the current session and the per map settings are stored in the extension (the original format) and save_extension (the format to save back in) fields present in the DriveData model.

Handling user’s permissions

A map on MindMeister can always be shared with other MindMeister users and the collaborators can have reading or writing access to the map. However, only some of these users will have a corresponding Google account with access to the MindMeister Google Drive application and furthermore, only some of them will have access to the same file on Google Drive with writing permission. This is why it is important for us to know which users can write back to the file and the solution for these access levels was achieved with the help of the permission field in the DriveDataRight model.

Results

Now more than two weeks on from the Google Drive launch and we can confidently say that our integration was successful, with more than 14,000 new users using Google login and with over 7,000 users that have enabled the Google Drive integration. All in all, the Google Drive SDK was very easy to use and well documented. The developer support, especially, was always there to help and our contacts were open to our suggestions.

Laura Bârlădeanu Laura is the lead programmer at MindMeister, an online mind mapping tool built in HTML5 that features real-time collaboration.

The new values for quotaBytesUsed field will reflect the total amount of storage used across the unified products.  (This field used to reflect the total amount of storage used by Google Drive.)

Ali Afshar profile | twitter Tech Lead, Google Drive Developer Relations. As an eternal open source advocate, he contributes to a number of open source applications, and is the author of the PIDA Python IDE. Once an intensive care physician, he has a special interest in all aspects of technology for healthcare

To increase the discovery of your Google Apps Marketplace listings, you can now embed an Integrate with Google button on your website, marketing pages, blog posts, and other properties. This lets domain administrators install your apps with a single click without leaving your site. Once they click the button, administrators can enable your app for all users (or just some of them) just like they would from the Google Apps Marketplace.

Here’s what the Integrate with Google button looks like on CloudLock.com:



To put the Integrate with Google button on your site, just embed the code below anywhere you want to display the button:

<script src="https://apis.google.com/js/platform.js"></script>
<div class="g-additnow" data-applicationid="your-app-id"></div>

Check out the developer documentation to start integrating today.

Hiranmoy Saha Google+ Hiranmoy Saha is a Software Engineer working on the Google Apps Ecosystem.