[MUSIC PLAYING]
ALI AFSHAR: Hi everyone.
Welcome to Google Developers Live.
My name's Ali, and today I'm going to be taking some
questions about the Google Drive SDK.
I'm going to be talking a bit about the answers.
And during this process, if you have any burning
questions, please feel free to ask it on the YouTube comments
or on the Google+ Event and someone will tell me, and
we'll try to get that answered live on air for you.
So for those of you don't know, we use Stack Overflow
for question and answer support.
We'll really happy with that.
At the moment it seems the community is growing and there
are a number of contributors who don't work at Google who
are actually helping other newer users on how to
use the Drive SDK.
So we're very happy about that, and thank you to
everyone who is answering.
That's great that you are part of the community.
And that's really our intention with using Stack
Overflow is to be part of the broader programming community.
So that's absolutely great.
So let's get started.
First question, is the only way to download a file through
Google drive through the download URL that is provided?
I have the file ID and would like to make one simple call
to download the file.
Right now it looks like you have to make one call to fetch
the file's metadata and one to actually download the file.
Is there any other way?
Well this is absolutely right.
The correct way of doing it is to fetch the metadata, to get
the download URL, and then download it.
That's always going to be two requests.
Now this is for a couple of reasons.
The first one is the download URL doesn't
last for very long.
This is a measure to make sure that people just can't keep
these immortal download URIs around for a long time because
that's not exactly great.
So we generate them, we give it to you, and then you can
use over a short space of time.
That's the first part.
The second part is although the scheme for these URLs
seems predictable and you could probably go about
generating it yourself, we strongly recommend
you don't do that.
So for these two things, we really
recommend making two requests.
If you're downloading that many files that it makes a
huge difference to make a small GET request beforehand,
I'd be really interested to know your use case.
So get in touch with us if that really is doing huge
network bandwidth that you just don't want to do.
Let us know and we'll have a look at that use case.
But for now, this is the way to do it.
There are other ways of downloading
files from Google Drive.
If you want to let the user download it in their browser,
we have this web content link.
That uses a different off mechanism and
that may be more suitable.
If you don't want to download a file and then give it to the
user to download, they can download it directly and you
will never have to get involved with that.
So that's great.
You'll only find the URL with the GET request and then the
user can download the file.
That's another option for you.
So that's that question answered by [? CloudEar, ?]
says pretty much the same thing.
All right, next question is about our date and time format
in the Google Drive API.
I'm having an issue with the create date, modify date for
the Google Drive API.
When I get the data, the time is displayed as, and there's a
time stamp there, and they want to know how to convert it
to and from this format.
That time format we use is RFC 3339, which is not that well
supported by some programming languages.
PHP doesn't have a good built-in standard library
thing to do it.
The Python standard library also doesn't do this without a
tiny bit of tweaking.
And it's mostly because, well, I'll use Python as an example.
Python's time zone segment on the end of the time stamp is
actually comes with a complete part.
So if it's seven hours before Greenwich mean time before
UTC, it will say minus seven zero zero.
And the format this expects is minus seven colon zero zero.
So although this is a RFC time stamp, and it is a good one,
and it's a consistent one.
And it is what we've been using for a long time and
[INAUDIBLE] and everything.
So you might have to write yourself a little function to
convert that.
I put an example on there in Python and someone else has
put an example in PHP.
And if you look up RFC 3339, you will find a sample in your
programming language.
So it's annoying to have to work around, but I'm sure
someone's already done that for you.
So that's times and dates.
And we use the same format for all our fields that have a
time or date in them.
Great, service account.
So the question is, Google Drive changing permissions by
service account.
They're looking for the best approach for administrators of
Google Apps domains to modify the permissions of a Google
Drive object owned by other users.
OK, this used to be done by 2-legged OAuth, if anyone has
used 2-legged OAuth.
We're now moving away from that and we've moved to a
model that is based on service accounts.
Now we have two different types of service accounts.
One of them is owned by a developer console project and
the other one is owned by a Google Apps domain.
Now this question is specifically asking about a
Google Apps domain.
So if you go to your C panel and you enable the Drive
scope, you can get your service account certificate
and you can actually use that to log in for any of the users
on your domain, to authorize for any of the
users on your domain.
And then really you can perform actions for that user
as if you were authorized as them.
This is pretty useful, and it pretty much covers the use
case in this question.
So you would authorize the user who wants to be able to
share the files with other people, OK?
And then you just add the permissions using the
permissions.insert method to add the permission for whoever
else to read or write or comment, or even you can use
this to change the owner of a file.
So that's that part.
There's a slight mention of Google App
Engine Service Accounts.
So Google App Engine Service Accounts is unfortunately yet
another way of doing service accounts.
Now how the application proves that it is who it is is App
Engine has its own specific service called App Identity.
So App Identity says hi, I am this application, so please
authorize me as a service account for this application.
Unfortunately, that's currently not supported
in the drive API.
We're really working hard to support this and if I had to
guess I'd say days or weeks this will be working.
So that's absolutely brilliant.
It's really useful in Python because the Python App Engine
SDK doesn't actually have enough cryptography to do
regular service accounts yet.
Again, that's something that's coming.
So for now, you can use these App Engine App Identity.
One proviso is that with App Identity, you will not be able
to use the drive.file scope.
Now the drive.file scope does depend very much on who the
app is so that users can authorize files for certain
applications.
And applications can't read all the files in your drive,
just the specific ones.
So those features get turned off for App
Identity Service Accounts.
But again, that's not exactly a problem because with App
Identity Service Accounts, the files are owned by the
application itself, so the file scope is reasonable
depending on your use case.
So that's enough about service accounts.
Just to let you know, we've covered these two cases, Def
Console Service Accounts and Domain Service Accounts.
And we've created two new tutorials on using them, so
please check them out.
They're at developers.google.com/drive.
They'll called Service Accounts and User
Impersonation.
This is one of the things we really want to
get absolutely right.
We do appreciate this use case that used to be covered well
by 2-legged OAuth.
So if you have any problems, let us know.
We want this to be absolutely right.
OK, next question.
Google Drive changes list API, detecting
changes at a folder level.
OK, this is a question we get asked quite a lot.
The changes feed, to give you a little summary, is if you're
authorized as a user you can get a list of, more like a
timeline, really, of all the changes that have happened to
files in their Google Drive.
So it will show this file is modified, this file is
created, a certain file was deleted.
And it goes in reverse chronological order.
Each one of these changes has a unique ID that you can
remember so you can say I only want changes
since that unique ID.
This is the changes feed.
Really, really useful to prevent having to download a
whole user's Google Drive, find out what's changed, and
then modify it locally.
I'm thinking of use cases like synchronizing applications
that you write.
So the question here is can we detect
changes at a folder level?
Brilliant use case and I can see why.
Unfortunately, we don't support that.
We believe that currently the changes feed is small enough,
there are only going to be a few hundred maybe at most
changes, is small enough that you can get the whole feed and
filter it for the ones that you want in the right folder.
So each of the entries in the changes feed will have--
as long as it's not a delete--
will have a parent ID, for example.
And if you look at the parent ID, you can find out which
folder it lives in.
Now I appreciate that the delete case doesn't actually
work because we believe very strongly that
users own the data.
So if they've deleted a file, you shouldn't really be able
to find out what the parents for that file were.
You shouldn't be able to know what the title
for that file was.
The user has deleted it and that's gone.
We do give you the file ID, but of course if you haven't
got a mapping of file IDs to parents, you don't know where
that exists.
So I appreciate this use case is not completely covered, but
there's not really much we can do.
We have to respect the user's privacy and the fact that the
user owns the data here.
I think that's a reasonable choice.
I'm a developer myself, so I would like it the other way,
but I do respect the user's choice here.
So another question asking about 2-legged OAuth for
Google Drive from Android.
So that's a really interesting question.
It doesn't actually work for a number of reasons.
One, we don't officially support 2-legged OAuth on
Google Drive.
And two, I'm not sure how you could use that
exactly from Android.
I guess you could use it as an installed
application on Android.
So I'm not sure what the use case is here.
Again, Mr. or Mrs. [? Gautome, ?]
I would be really pleased to hear your use case because
that sounds kind of interesting.
You can use a service account from Android.
The other thing you can actually do which, may or may
not be suitable for you but it would cover the use case, is
that if you have offline access, if you have an access
token and a refresh token, you can essentially keep them
forever and use them.
Now I'm assuming this app is not something you want to
publish widely because if you publish a 2-legged OAuth token
widely, and that's a permanent token, anyone can use that.
So really you've given away your whole credentials.
So I'm guessing this is an internal app.
And if it is an internal app, you can use a saved standard
OAuth2 token, or a saved service account OAuth2 token
that has offline access.
And that can be refreshed forever.
So I'm guessing this is for internal use case for someone
rather than the external app.
If it is an external app, please do not put raw tokens
in your APK, or in fact in anything, even if it's
compiled or fiscated.
The stuff is reasonably
straightforward to reverse engineer.
So yeah, please don't do that.
Fingers crossed that is an internal use case here.
So, done a few there.
Should we check if there any other questions?
I'm going to check quickly if there are any other questions
from people.
Nope, not there.
OK, so they'll let us know if there is.
Great, so next question.
Google Drive SDK image metadata.
Recently we launched the feature to add EXIF data.
If you don't know what EXIF data is for images, when your
camera, your flashy camera takes a photograph, it stores
some information in there.
Even the cameras on phones do this.
So the camera make, the camera model, the aperture, the
exposure, the focal length.
These kind of things are all stored in the image as some
extra metadata so the other applications can look at them.
Photo applications, photo organizing, photo editing.
We recently, last week, exposed this data because we
index it for Google Drive.
It's very useful, lots of photos in Google Drive.
Perfect use case if you're a photographer, store your
photos there.
And they never will be lost.
This question is asking for some missing
features, missing fields.
So actually, focal distance is one that we're missing.
Focal distance, metering mode, sensor type.
And there are some IPTC metadata
keywords that are missing.
A perfect example, thank you for bringing this up.
I hope this person's writing an awesome file image gallery
application for Drive because if they are, I really want to
use it myself because I've got lots of photos there.
So they're just asking for this extra data.
And there's a perfect use of Stack Overflow.
Thank you for telling us this.
We're looking to get these features added as soon as
possible so your apps can work.
OK, yes, please, someone write a photo editing app.
A photo management gallery app, I'm desperate to use it.
OK, let's do one more, shall we?
MALE SPEAKER: We do have a question on YouTube.
ALI AFSHAR: Oh, do we?
MALE SPEAKER: One of them says is there way to get files from
the Google Drive and read it in using Java?
ALI AFSHAR: Yes.
The answer is absolutely yes.
When you say get files, I guess you mean download files
or upload files?
Downloading files.
OK, great.
So yes, absolutely.
If you go to a URL that I will put in the YouTube comment,
I'll tell you what it is in the YouTube comment.
But we have a Java snippet for doing exactly that.
You should be able to take the snippet, copy it, paste it
into your application, and everything should work.
OK, it's two steps.
One, you get the download URL, and then you perform a
download using the raw underlying HTTP library with
the added authorization header.
But we show you how to do that, copy and paste it.
Java is not special.
We also have identical sample for Python, Go, PHP,
JavaScript, Ruby, .net.
And any language you want there, please let us know.
We'll look to see they add it.
So yes, absolutely.
We love Java developers, you're very important to us.
MALE SPEAKER: So there is another question via Google+
Events asking about 2LOA scope for the Drive API.
They are wondering if we can expect a 2LOA scope for the
Drive API so they can write apps, Marketplace apps that
take advantage of it.
ALI AFSHAR: So this is an unsupported
feature at the moment.
But actually 2LO scoped tokens for Google Documents List API
do currently work against the Drive API.
So I'm not exactly overly enamored with that because
we're trying to deprecate OAuth1.
Well, we have deprecated it, but we're trying to get rid of
all the use cases.
Now we specifically allowed this for the case where
someone already has a token for the Documents List API,
they want to start using the Drive API, and they don't want
users to reauthorized.
We wanted to smooth that user experience for your apps.
So right now you can get the Documents List API scope token
from your C panel used with 2-legged OAuth
with the Drive API.
Unsupported, may go away.
But if that covers your use case for now, please use it.
Please look to using regular service accounts.
I think you can even though you are in the Apps
Marketplace, but I think you can.
But we don't want to make it harder for you right now to
migrate across.
So first, I'd say migrate using the token and then we'll
look at fixing that.
MALE SPEAKER: And there's one more question from Joshua
Owen, who says he's developing a Hangout App that makes use
of the Google Drive Integration via picker object
to obtain the file ID.
He says he can temporarily share images he owns to
Hangout participants using permission methods, but this
obviously won't work for things that are shared to him.
Is the best way to accomplish this to copy the file to the
local user drive and then share out to the Hangout
participants?
ALI AFSHAR: Yes.
So if you don't have enough authority to add permissions
to the user, or if you really don't want to do that, it is
potentially not polite if someone shares something with
you and then you share on, yes, copying it to your own
drive and then sharing it out from there
kind of makes sense.
But that's the best way to do it.
You can, if you have permission to add other, I
think it's called the Writers Can Invite field, so if you
have that one set, then you can still invite other people
to do that.
But otherwise yes, copying it is the best way.
But that's a cool app.
I'd love to know about that.
When you launch, please let us know because, well obviously
we're always into integrations between two different Google
products, but I think the collaborative nature of
Hangouts and the collaborative nature of the drive editors,
there's really a lot of integration points there.
So please let us know, we're really keen to see that.
Any more questions?
No?
OK, brilliant.
Thank you very much for tuning in.
Please keep asking your questions and please telling
us how we can improve.
That's really useful for us.
Thank you very much, my name is Ali.
Take care.
Bye, bye.
[MUSIC PLAYING]