0

I'm running a query on the Android SDK for Google Drive to check if a directory with a specific name exists or creating it otherwise (directory name is the resource title on Google Drive).

The problem I'm having with the following code is that it never finds my folder and creates a new one every time and I'm not sure why. It successfully finds the directory if the SDK created it itself.

public static final String FOLDER_NAME_CORE = "My Core Folder";

MetadataBuffer meta = Drive.DriveApi.query(mGoogleApiClient, new Query.Builder()
            .addFilter(Filters.eq(SearchableField.TRASHED, false))
            .addFilter(Filters.eq(SearchableField.TITLE, FOLDER_NAME_CORE ))
            .setSortOrder(new SortOrder.Builder().addSortDescending(SortableField.MODIFIED_DATE).build())
.build()).await().getMetadataBuffer();

if (metadataBufferResult.getCount() > 0) {
    Log.d(TAG, "Creating new folder"); 
    ...
} else {
    Log.d(TAG, "Using existing folder");
}

I've tried making the folder publicly shared but it didn't change anything (as expected). Does anyone know what I have to change to make it find the existing folder instead? As far as I know this list is the only possible search options.

seanpj
  • 6,735
  • 2
  • 33
  • 54
Nick Cardoso
  • 20,807
  • 14
  • 73
  • 124

1 Answers1

0

I hope you are aware of the supported scopes.
I think there are 2 things that cause your problem and you will have to re-think your app's logic.

First, GDAA (unlike the REST Api), introduces some latency, so the file/folder may not exist on the Drive for awhile, even if you got your DriveId (see this).

Second, the fact that you use TITLE as an indicator of existence does not work in the GooDrive universe, since TITLE is not unique (you already know that).

I would recommend this approach:

  1. when your (GDAA based) app creates a file/folder, wait until you get it's ResourceId. That confirms it's existence (again here).
  2. always check for the existence of a file/folder in the Drive using it's ResourceId (turned into DriveId)
Nimantha
  • 6,405
  • 6
  • 28
  • 69
seanpj
  • 6,735
  • 2
  • 33
  • 54
  • Thankfully I'm using ResourceId throughout most of the app because it was more uniform than DriveId (ResourceId matches sharing link). This is literally just for new installs where I'm looking by title in order to get that ResourceId. I hadn't realised the query results were SDK enforced I thought I'd made a mistake. Thanks for clearing it up! – Nick Cardoso Oct 02 '15 at 13:22
  • Just a 'heads-up', DriveId is useless outside of GooPlaySvcs instance (one device). It even changes during it's lifetime ([Daniel's comment here](http://stackoverflow.com/questions/21800257/where-did-the-createfromresourceid-go)). Don't cache it, don't publish it. – seanpj Oct 02 '15 at 13:28