1

I need to delete files from Google Drive using com.google.android.gms.drive. From what I've read here and across the web there is no support for file deletion in the "new API". Is that (still) correct? I mean the API isn't that new anymore ...

I also read about the "clear contents and forget"-strategy, but I'd like not to follow that approach.

Part 2 of the question: Given it's still impossible to delete files via the API mentioned above; is there any easy way to combine the REST API w/ the code I've already written? Something like

  1. get token from GoogleApiClient
  2. fire DELETE request w/ token and file id
  3. ???
  4. profit

edit: The new Google Play Services (version 7.0.0 / March 2015) finally features a trash() method. See https://developer.android.com/reference/com/google/android/gms/drive/DriveResource.html for further details. .


edit2: Apparently you cannot use trash() on files from the app folder: Cannot trash App Folder or files inside the App Folder. :((


edit3: As of May 28th, it's now possible to actually delete files.

Community
  • 1
  • 1
m02ph3u5
  • 3,022
  • 7
  • 38
  • 51
  • When you say "new api" just to be clear, the android API (GDAA) is not a replacement for the REST API. Think of it as an offline subset of the full API which may be useful in some scenarios, useless in others. – pinoyyid Mar 13 '15 at 18:22
  • I filed a feature request https://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=3777&thanks=3777&ts=1426601882 (hopefully in the right spot) – m02ph3u5 Mar 17 '15 at 14:21

2 Answers2

3

UPDATE (May 2015)
Addition of trash / delete functionality to GDAA 7.5 renders the answer below irrelevant.

ORIGINAL ANSWER:

The sequence is:

  1. Get DriveId from GDAA (file or folder)
  2. Get ResourceId from DriveId.getResourceId() (may be null if file/folder is not committed yet)
  3. use ResourceId (rsid) in this REST call:
com.google.api.services.drive.Drive.files().trash(rsid).execute()
com.google.api.services.drive.Drive.files().delete(rsid).execute()
  1. finally realize that you can't do it since you'll see the file in GDAA long after it has been deleted / trashed. You can even write in it, create files in that folder you've just trashed, ... That's why people introduced the "clear contents and forget" strategy nobody likes.

Needless to say, this applies to any delete / trash action you may perform outside of GDAA universe (manually trash/delete using web interface etc...)

So, to wrap it up. 'pinoyyid' is right, each of the APIs is different and the GDAA can not replace the REST (yet). You'll quickly realize it when you try to work a little deeper, like getting thumbnail url, fighting latency issues etc... On the other hand GDAA has advantages, since it can work off-line without your app handling it. When using REST, your app should do all the Drive calls in some kind of sync service to separate your UI actions from network issues (delays, off-line, ...). GDAA handles this for you, but on it's own timing terms. And with no delete functionality.

I put a piece of code on github, that has both these API's used side-by-side and you may use it to play with different scenarios before committing yourself to one of them.

It would be nice to hear clearly from Google what the final strategy is, i.e.

  • Is GDAA going to replace REST one day, after all the REST functionality is in?
  • Will they retire the REST afterwards?

Good Luck

seanpj
  • 6,735
  • 2
  • 33
  • 54
  • Nice work on the github code. Obv, I'm not Google, but I think the answer about retiring the REST API has to be 'no' since GDAA is using that API under the covers and of course it is device/client independent and its effect is immediate (as opposed to GDAA's deferred sync). – pinoyyid Mar 14 '15 at 15:22
  • @pinoyyid ...what I thought. I'm just trying to poke them (https://developers.google.com/drive/support) here and there. No luck so far. – seanpj Mar 14 '15 at 16:14
  • 1
    I have this mental picture of a deserted office, door off its hinge, fading pictures of Ali Afshar and Steve Bazyl on the wall and tumbleweeds blowing through. – pinoyyid Mar 14 '15 at 17:22
  • 1
    ... and they sure had a lot of fun while it lasted 0:50, 1:23 @ https://youtu.be/r2dr8_Mxr2M – seanpj Mar 14 '15 at 22:32
  • 1. Is GDAA going to replace REST one day, after all the REST functionality is in? pinoyyid's comment above on the question is correct, at the moment the GDAA is a subset with off line caching and the file picker UI. The goal is to support more of the REST functionality natively, but we aren't there yet. Delete is something we are working on. 2. Will they retire the REST afterwards? Nope, the GDAA is built on the REST API. It also provides client libraries for other platforms, e.g. Objective-C for iOS. – Daniel Mar 16 '15 at 04:23
  • @Daniel THANK YOU ! The first clear unambiguous message I've heard in 15 months since GDAA has been introduced. I certainly suspected it would be the case, but never heard anything assuring from people who know. – seanpj Mar 16 '15 at 09:29
  • @Daniel is there any way to track the progress of your work for non-google people? – m02ph3u5 Mar 16 '15 at 17:02
  • 1
    We don't publish a roadmap externally, but please file feature requests and bugs against the Apps API Issue Tracker: https://code.google.com/a/google.com/p/apps-api-issues/ Use the issue template links on that page to make sure each issue is tagged with the correct API. – Daniel Mar 17 '15 at 01:49
  • @Daniel isn't google code going to be shut down? I'll file a request anyway. – m02ph3u5 Mar 17 '15 at 14:06
  • We will announce a new process nearer the read-only date. We expect to be able to migrate issues, they won't be lost, so please continue using the existing issue tracker. – Daniel Mar 20 '15 at 23:06
0

Delete is supported by the Google Drive Android API as of Google Play services 7.5 using the DriveResource.delete() method.

Delete is permanent, and recommended only for App Folder content, where trash is not available.

Daniel
  • 1,239
  • 1
  • 13
  • 24