The first steps in manipulating files in Google Drive

Uploaded by GoogleDevelopers on 30.07.2012


I'm Nicolas Garnier.
I'm a Developer Advocate for Google Drive.
Today I want to show you how web applications can integrate
deeply with Google Drive using the Google Drive SDK.
This will allow your application to take advantage
of Drive's user-managed storage, integrate with the
Google Drive online File Explorer, and potentially
leverage the billions of files that are currently stored in
users' Drive.
We will demonstrate how to do that by implementing and
integrating the web-based text editor.
But first, it is important to understand what can be
achieved by integrating your web
application with Google Drive.
So we're going to go through a few scenarios showcasing how
apps can integrate with Google Drive today.
Let's now go to Google Drive File Explorer.
As you probably know, Google Drive offers a way to
synchronize your files to your devices and desktop computers.
Our user currently has a few images stored
in his drive already.
We can see one of them here.
The user now wants to edit that image, and for that, he
has installed Cloud Paint.
Cloud Paint is a third-party image editor that offers a
Google Drive integration.
All that the user has to do is right click on the file and
choose to open it with Cloud Paint.
The user gets redirected to the application, and it's
displayed with the image which he can edit.
Here, let's edit it.

When the user saves the image, the modified image gets saved
directly on Google Drive.
Here, if we go back to Google Drive and have a look at the
image, as you can see, we've got the modified image
directly in Google Drive.

Similarly, we can also create an image through the Create
Menu with Cloud Paint.

We're going to call it MrPotato.

Let me do something using my awesome drawing skills and
click Save.

As you can see in my Drive, the new file has been created.
Let's just have a look.
And here, we can see MrPotato.
All of that was done in the cloud.
There was no manual file manipulation needed.
I didn't have to download the file from Drive and upload the
file back to the tool.
All that file creation and the text change were done server
to server using the Google Drive API.
This is the kind of experience that Google Drive integrated
application are able to offer to their users.
So now we're going to see how to create a Drive application.
For the purpose of this webinar, we will implement and
integrate a web-based text editor that
we will call DrEdit.
Prior to coding, there are two things that you need to do.
First, you need to register your application.
And then list your application.
To register your application, you have to go to the Google
APIs console, create a new project and enable the Google
Drive API and the Google Drive SDK.

Then you need to create OAuth 2.0 credentials.
You would usually have to select web applications and
provide the URL at which your app is hosted.
In our case, it's going to be DrEdit.
Your OAuth 2.0 credentials are now ready.
You also need to configure the Google
Drive specific features.
You can do that in the Drive SDK section.
You'll have to fill in some information about your
application and provide some icons.
Most of this is pretty straightforward.
In this example, I have already configured my app, but
let me go through a few of these fields that
need special attention.
The Open URL is the URL to which we will redirect users
when they open the file with your app.
You will have to make sure the Open URL is listed in the
redirect URIs of your OAuth 2.0 client ID.
This is because we do the redirect through an OAuth 2.0
flow using the client ID.
And therefore, the URL needs to be listed as a valid
redirect URI.
You need to list the main types and the extension that
the app can open.
For our app, we simply listed the basic text file MIME type
and the TXT extension.
It is usually best to list both MIME type and extensions.
If your app supports creating new files, which is the case
for DrEdit, you will need to specify the URL that will
handle such requests.
Make sure that the URL is also listed as a valid redirect URI
off your client ID.
Typically, you would need access to the user's email or
ID, and we will explain later why.
So we've added the user info profile scope here.
You don't need to list the Google Drive API scope as the
Drive that file scope is implicit.
That default scope gives you access to Drive files created
by your application or a file that has been opened through
the Google Drive UI with your application.
It is important to be aware of this profile security model.
Now the second thing you need to do is create a Chrome Web
Store listing.
You need that listing to be able to install app to some
Drive accounts so that you can initiate Open and Create file
actions from Drive.
Currently, all Drive apps are distributed and installable
through the Chrome Web Store.
This is the Chrome Web Store.
In the Developer Dashboard, you can create a new listing.

This is like creating any other Chrome Web Store listing
except that you will need to add two special lines to your
Chrome Web Store apps manifest file.
You need to specify the Google Drive container and also your
API console apps ID.
To create your listing, you will need to include a few
mandatory assets like icon, screenshots, promo image.
Also, enter a description to verify that you are the owner
of the website and so on.
To save time, I have already prepared the Chrome Web Store
listing for DrEdit.
Once these are done, make sure that you publish your listing
only to a list of trusted testers while your Drive
application is in development.
This is important so that your listing does not appear in the
public list of available Drive apps while not finished.
Once your listing is ready and published to trusted testers,
just install your app.
And the next time you open Google Drive in your browser,
you will get a notification that the app has been
installed, and you will be able to open supported files
with the app, in our case, textile.
You will also be able to create files with the app
through the Create Menu.
So if you choose to create a file with DrEdit, Drive
initiates an OAuth 2.0 flow.
And since this is the first time that we are using the
app, we are prompted to authorize DrEdit for Google
Drive file access and also for the extra scopes that were
listed in the API's console.
After the user grants access, he's redirected to your
application Create with URL where we first need to handle
authorization to the API.
There will be two parameters passed in the URL.
The first parameter contains the auth code.
And the second is the state parameter which contains the
JSON object containing two attributes.
The first one simply states which action was triggered on
Drive, in this case, a Create New File action.
The second is the ID of the parent folder that was
currently being displayed in the Drive UI.
This is provided so that the file created can be saved
directly to the currently open folder.
So now we need to finish the OAuth 2.0 flow.
This means exchanging the auth code for tokens.
In that case, we will get an access token
and a refresh token.
As you can see here, this is pretty easy to do using our
client libraries.
After initializing a few static objects, the extension
is done in one line of code.
In Google OAuth 2.0 protected APIs, the access token allows
you to use the API for one hour.
And the refresh token allows you to extend that by getting
new access tokens.
This is important because you will need the refresh token if
your application needs to use the API for more than an hour,
which is the case for DrEdit.
Now, what you need to do is save this refresh token.
That's basically because we get a refresh token only the
first time a user opens the application in Drive.
Subsequent times, the user will not be prompted for the
OAuth 2.0 green screen, and we will only get an access token.
So in order to be able to retrieve the refresh token in
the future, we need to save it against the ID of the user.
And what we do here is get the ID of the user through the
UserInfo API.
Alternatively, you could also use the email of that user,
but the ID is a little more robust because
it will never change.
We now can save the refresh token using the user ID
as the table key.
Just use your preferred database.
For instance, in an App Engine environment, you could simply
save it to the App Engine Data Store.
We now have an access token and a refresh token, which we
just saved.
At that point, we save the refresh token and the access
token to the session, and pass the folder ID
as a request parameter.
Then we display the UI of the web-based text editor.
Let's choose a name for the new file and
then enter some text.
Let's simply call it Hello World.

The web-based text editor using the
sample is called ACE.
ACE is open source, fully client side, and
To be able to use ACE with Drive, we simply hooked up
ACE's JavaScript API to some Ajax call to our back end,
which handles the reading and writing of Drive files.
So when the Save button is clicked, what happens is we
send the content of the text file to our server side code
through an Ajax call.
Server side, we receive the content of the new file, its
name, description, and the destination folder ID through
an Ajax call.
Then you simply need these few lines of code to create the
file on Google Drive using our client libraries.
There are two parts to a Drive file, the metadata and the
actual file's content.
We first set some metadata, such as the file, the name,
the description, MIME type, and parent folder.
Then in the same request, both the metadata and the file's
content are sent to the Drive API to create the file.
Now let's go back to the Drive Explorer, and as you can see,
the text file that was just created is here.

Now let's see how to handle the other integration point,
which is opening an existing file with your app.
So if we choose to open a Drive file with DrEdit, again,
Drive will trigger an OAuth 2.0 flow, but your users won't
see the green screen this time because we have approved the
application earlier.
So all subsequent auth flow for that app will skip the
approval screen, and you will be automatically redirected to
the open URL of the app.

Again, there will be two parameters passed in the URL.
The first parameter contains the auth code, and the second
contains adjacent object again.
Still containing two attributes, the first one
indicates that the action triggered
on Drive is an open-with.
The second is an array of IDs of the files
that have been opened.
It is an array because you can enable a feature that will let
your users open multiple files with your app,
if you choose so.
Since this is not the first time the user authorizes the
app, exchanging the code will only return an access token
and the refresh token.
Now, you have a refresh token saved in your database from
the first time the user authorized.
So to get it, you would typically get the user ID
using the access token to call the UserInfo API, as we've
seen earlier, and then pull the refresh token from your
local database using the user ID.
That way, we can have access to the API for more than the
expiration period of the access token,
which is one hour.
Note that all of our client libraries handle refreshing
the access token automatically if you passed a refresh token.
Again, we saved the refresh token and the access token to
the session and passed the file ID
as a request parameter.
Then we displayed the UI of the web-based text editor.
Now, the editor queries an Ajax endpoint on your back end
that will load the files content, which we
can display in ACE.
So what happens here is that we have a servlet serving the
Ajax requests that will use the API to read the file.
After handling the authorization and initializing
the Drive service, this is done in two steps.
First, read the files metadata.
This gives us important info like the file's name and also
the download URL, which is where the
file's content is located.
So then we download the file's content using an authorized
request to the download URL and return
that to the Ajax call.
Here it is.
The content of the file is being displayed
client side in the UI.
This is it.
Your app now has basic Google Drive functionalities.
It can open files from Drive as well as
create files from Drive.
Don't forget to check our online
documentation for more details.
You will also find the sources for the sample application
used in this video.
It is available in five languages.
Thanks for watching.