5

When testing of delete, trash functionality discussed in SO 22295903, I've run into this issue.

1/ Create a file with contents

GoogleApiClient _gac;
DriveFile createFileWait(DriveFolder fldr, String name, String mime, byte[] buff) {
  DriveFile drvFile = null;
  try { 
    ContentsResult rslt = Drive.DriveApi.newContents(_gac).await();
    if (rslt.getStatus().isSuccess()) {
      Contents cont = rslt.getContents();    
      cont.getOutputStream().write(buff);
      MetadataChangeSet meta = (mime == null) ?
          new MetadataChangeSet.Builder().setTitle(name).build() :
          new MetadataChangeSet.Builder().setTitle(name).setMimeType(mime).build();
      drvFile = fldr.createFile(_gac, meta, cont).await().getDriveFile();
    }
  } catch (Exception e) {}
  return drvFile;
}

2/ retrieve the file using query (it's title):

ArrayList<DriveId> findAll(String title, String mime, DriveFolder fldr) {
  ArrayList<DriveId> dIDs = null;
  if (isConnected()) try {
    ArrayList<Filter> fltrs = new ArrayList<Filter>();
    fltrs.add(Filters.eq(SearchableField.TRASHED, false));
    if (title != null)  fltrs.add(Filters.eq(SearchableField.TITLE, title));
    if (mime  != null)  fltrs.add(Filters.eq(SearchableField.MIME_TYPE, mime));
    Query qry = new Query.Builder().addFilter(Filters.and(fltrs)).build(); 
    MetadataBufferResult rslt = (fldr == null) ? Drive.DriveApi.query(_gac, qry).await() : 
                                                   fldr.queryChildren(_gac, qry).await();
    if (rslt.getStatus().isSuccess()) {
      MetadataBuffer mdb = null;
      try { 
        mdb = rslt.getMetadataBuffer();
        if (mdb == null) return null;
        dIDs = new ArrayList<DriveId>();
        for (Metadata md : mdb) {
          if ((md == null) || md.isTrashed()) continue; 
          dIDs.add(md.getDriveId());
        }
      } finally { if (mdb != null) mdb.close(); } 
    }
  } catch (Exception e) {}
  return dIDs;
}

3/ You get valid DriveId. Try to use it to gain resource ID to use in RESTful API, or elsewhere.

String fileID = drvId.getResourceId();

You get a null value. After a few moments (random, difficult to specify), if you repeat the query, you'll finally get your resource ID. I know why, it is probably a latency issue. I'm just soliciting a comment from the Google Support Team. Is there a way to gain control? Query latency status?

Community
  • 1
  • 1
seanpj
  • 6,735
  • 2
  • 33
  • 54

1 Answers1

2

This happens because changes are persisted locally first, and then uploaded to the server at a (possibly) later time when we have sufficient network connectivity. Unfortunately the resource id is not available until the newly created file is committed to the server.

Currently all you can do is wait for it to be available. We are working on some additions that will make this flow easier, so stay tuned.

Cheryl Simon
  • 46,552
  • 15
  • 93
  • 82
  • Thanks, not a showstopper, just a 'heads-up' for others who may run into it. – seanpj Mar 17 '14 at 19:22
  • 2
    Fyi, we *just* announced a new change notifications API which should help with this problem. You'll be able to register to receive notifications whenever a file's metadata or contents change. When the file gets written to the server, the metadata will be updated with the new resource ID and you will get a notification. See http://android-developers.blogspot.com/2014/03/google-play-services-43.html (The actual API will be available once the release hits 100%) – Cheryl Simon Mar 17 '14 at 23:55
  • So, will the notifications solve the TRASH/DELETE issue http://stackoverflow.com/questions/22515028/deleted-files-status-unreliably-reported-in-the-new-google-drive-android-api-gd ? – seanpj Mar 21 '14 at 11:44
  • You should get notified when the trash state changes just like you do for any other metadata change. I'm not sure if that will solve your issue. – Cheryl Simon Mar 21 '14 at 15:48
  • My case involves only one particular file - config.db - with known ID, so it would help. It would stop me from creating a duplicate or writing into a trashed one. Thanks. – seanpj Mar 21 '14 at 18:36
  • Based on the name, it sounds like you might want to put this file in your app data folder (also part of this new launch), so that it can't be deleted or trashed without your knowledge. – Cheryl Simon Mar 21 '14 at 18:39
  • Hi Cheryl, Is there a documentation for the new API version for a sneak peek (seanpjanson@gmail.com)? Mainly the new metadata. – seanpj Mar 24 '14 at 16:15
  • Hi Cheryl, regarding the change notifications API, is it not possible to somehow listen for when MY change has synced? I want to be able to tell the user that their action has safely synced (i.e. I definitely don't want to be misled by some other change to the same file). – Mark Apr 05 '14 at 13:36