2

I have updated to the new version of Google Play Services 4.2 (library version 15). And suddenly, the calls to DriveId.createFromResourceId("....") are unresolved.

DriveId sFolderId = DriveId.createFromResourceId("0B2EE......N3J6RU0");

I know I can use either DriveId, or encodeToString() / decodeFromString() instead, but:

  1. ResourceId corresponds directly with a http of the file in Google Drive.
  2. Appears to be persistent even if the file is manipulated

Both the documentation and demo code uses the method extensively. Also, the mirror method getResourceId() is still in existence.
More than a question, it is a request for clarification from the Google Drive / Google Play Svcs folks.

seanpj
  • 6,735
  • 2
  • 33
  • 54

2 Answers2

8

I tested Burcu's answer, and unfortunately it did not work. Or maybe I phrased the question incorrectly. I'll try to re-phrase it (and I found the correct answer).

There are 2 different string type ID representations available for DriveId (both file and folder).

1/ DriveId.encodeToString(), resulting in something like:
"DriveId:CAESHDBCMW1RVVcyYUZKZmRhakIzMDBVbXMYjAUgssy8yYFRTTNKRU55"
2/ and DriveId.getResourceId(), resulting in shorter:
"UW2aFJfdajB3M3JENy00Ums0B1mQ"

In 4.1, there were 2 methods that would turn these back to the DriveId

1/ DriveId.decodeFromString(DriveId.encodeToString());
2/ DriveId.createFromResourceId(DriveId.getResourceId());

Both of them worked correctly in pairs and I chose the ResourceId variety, since this short string appears in http address used in other systems (Apps Script...). For example: https://docs.google.com/file/d/UW2aFJfdajB3M3JENy00Ums0B1mQ
Also, it appears to be persistent even if the file is manipulated in Google Drive (trashed, restored, moved).

But in 4.2, the createFromResourceId() disappeared and CAN NOT be replaced by "decodeFromString()" like this:

//INCORRECT    
DriveId.decodeFromString(DriveId.getResourceId());

Instead, the DriveId from ResourceId has to be retrieved this way:

DriveIdResult result = Drive.DriveApi.fetchDriveId(GAC, DriveId.getResourceId()).await();
DriveId drvID = result.getDriveId();

(and I use the "await" version for simplicity).

So the conclusion is: The createFromResourceId() was replaced by 

Drive.DriveApi.fetchDriveId(GAC, DriveId.getResourceId()).await().getDriveId()

with the caveat that the "await()" construct should be implemented as a callback in normal UI thread.

UPDATE (2014-10-23)

The answer above is quite stale, please refer to the comments below.

seanpj
  • 6,735
  • 2
  • 33
  • 54
  • 1
    You are correct, fetchDriveId replaced createFromResourceId. Sorry for the confusion. The resourceId matches the ID used in the web versions of the Drive API, while the DriveId (and encodeToString method on it) encodes some additional information. Use resourceId if you want to use the web API in addition to the Android API, otherwise use the DriveId and encodeTo/FromString. – Cheryl Simon Feb 17 '14 at 21:53
  • Thanks Cheryl, can you please still pitch in about the persistence of the DriveID (the long one)? In other words, can I store it in my app's persistent storage (SQLite for instance) and refer to it later? Seems to me the "decode" is faster then the "fetchDriveId" method. – seanpj Feb 18 '14 at 00:02
  • Yes, that is the intention of the encodeToString. It should say that in the documentation. – Cheryl Simon Feb 18 '14 at 17:24
  • You just saved me from a lot of pain. Thank you – Eenvincible Jun 02 '14 at 03:28
  • Note that the string representation of a DriveId will change depending on whether the resource has been uploaded, so if you're doing comparisons you should always use DriveId.equals() rather than comparing the strings directly. ResourceId strings can be compared directly, however these are only available once a resource has been uploaded. – Daniel Oct 22 '14 at 03:40
  • @Daniel Yep, there were so many badly (or vaguely) documented quirks in GDAA, that I dropped it completely and went back to the RESTful API. A year since announcement and still no DELETE? The sync timing issues were killing me as well. And I was hoping to get synchronization across different devices, but custom GCM implementation is a better bet, so it seems. – seanpj Oct 22 '14 at 12:11
  • @Daniel Please take a peek at [this](http://stackoverflow.com/questions/22874657/unpredictable-result-of-driveid-getresourceid-in-google-drive-android-api/31553269#31553269), also reported [here](https://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=3929). Is it something that can be confirmed? I've been fighting it for a while now and since nobody else is complaining, I'm not sure if it is for real or some lack of understanding on my side. – seanpj Jul 22 '15 at 11:41
  • The driveId can not be used across devices, so do not store driveId to the database. – Hai nguyen thanh Oct 18 '16 at 07:31
0

createFromResourceId is renamed to decodeFromString.

DriveId sFolderId = DriveId.decodeFromString("0B2EE......N3J6RU0");
Burcu Dogan
  • 9,153
  • 4
  • 34
  • 34