As at August 2015, the 'Drive API for Android' is not functioning as (loosely)documented, is effectively broken. The main sore points are as follows:
1) An app sharing the same APP_ID and logged in with the same Google User is meant to be able to find and access the same files as Google indicate (e.g. appX on device1 creates a folder named 'blahblah' (where no 'blahblah' folder already exists in the User's Drive), appX on device2 should be able to find that folder and upload/download files from it also...however this is not the case (or if it does work, it is intermittent and mostly not working at all)). This remains the case even after (many) requestSync calls and over 72hours of allowing Drive to sync itself.
2) A trashed folder is not observed as trashed, even after a requestSync call has succeeded. Such a trashed folder will still have isTrashed==false.
3) A permanently trashed folder (i.e. it is GONE from Drive, it is never coming back). Can still be found and "successfully" have folders and files created within it, however writing to such a file's contents will always yield a failure in Completion Event Service. Again, such a folder will still have isTrashed==false (which is abysmal).
Bug reports have been lodged (thanks to @DalmTo for the link) via: https://code.google.com/a/google.com/p/apps-api-issues/issues/entry?labels=Type-Defect,API-Drive
https://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=4003
https://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=4004
SO, the question: know a way around these issues?
UPDATE:
I've narrowed these problems down to my personal Google account (or my personal Drive, which has many, many files in it). That suggests these issues are symptoms of or closely related to https://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=3905
I can give you some points regarding the issue 1/ (syncing on multiple devices running the same app). I've been pointing out this already in April 2014 without satisfactory answer (actually resounding silence). So I switched back to the REST API and handled everything myself (using syncadapter, service, ...). The REST's algorithm is:
- create/update/delete/ .... (execute() method)
- dispatch resource ID ('id'+message) using GCM to other devices
- let other devices deal with the change through the REST API (again, in service)
I've re-visited the GDAA a few times since and never got satisfactory results (requestSync). Finally, I got half-way happy when started to use 'completion events' (a year later, needless to say).
Again the algo is:
- create ....
- get ResourceId from completion
- dispatch 'ResourceId'+message using GCM to other devices
- let other devices deal with the change through the GDAA (using the ResourceId)
... and the point is:
During the time I was trying to make it work, I finally realized that the GDAA is not well suited for all applications (like the one we're discussing here). The GDAA goes through all kinds of hoops and loops to make the online/offline state transparent and at the same time to cache data and optimize network traffic, battery use, ... It creates latency, unpredictable states...
... so, in the end I stopped blaming the GDAA for not being a swiss-knife and do everything everybody ever dreamed up. It is up to the developer to FULLY understand the advantages / drawbacks of a toolbox he/she is using and decide upfront which tool to use. I know, the docs do not spell it out and believe me, I myself got caught in Magnus's excitement. I still remember pinoyyid's warning in January 2014, telling me not to jump in too early.
Good Luck
As per your response on the issue tracker, we believe this is an issue with sync for your particular account, potentially related to this issue. We'll continue discussion of this issue on the issue tracker.
