Drive API for Android is broken, right? -
as @ august 2015, 'drive api android' not functioning (loosely)documented, broken. main sore points follows:
1) app sharing same app_id , logged in same google user meant able to find , access same files as google indicate (e.g. appx on device1 creates folder named 'blahblah' (where no 'blahblah' folder exists in user's drive), appx on device2 should able find folder , upload/download files also...however not case (or if work, intermittent , not working @ all)). remains case after (many) requestsync calls , on 72hours of allowing drive sync itself.
2) trashed folder not observed trashed, after requestsync call has succeeded. such trashed folder still have istrashed==false.
3) permanently trashed folder (i.e. gone drive, never coming back). can still found , "successfully" have folders , files created within it, writing such file's contents yield failure in completion event service. again, such folder still have istrashed==false (which abysmal).
bug reports have been lodged (thanks @dalmto 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, question: know way around these issues?
update:
i've narrowed these problems down personal google account (or personal drive, has many, many files in it). suggests these issues symptoms of or closely related https://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=3905
i can give points regarding issue 1/ (syncing on multiple devices running same app). i've been pointing out in april 2014 without satisfactory answer (actually resounding silence). switched rest api , handled myself (using syncadapter, service, ...). rest's algorithm is:
- create/update/delete/ .... (execute() method)
- dispatch resource id ('id'+message) using gcm other devices
- let other devices deal change through rest api (again, in service)
i've re-visited gdaa few times since , never got satisfactory results (requestsync). finally, got half-way happy when started use 'completion events' (a year later, needless say).
again algo is:
- create ....
- get resourceid completion
- dispatch 'resourceid'+message using gcm other devices
- let other devices deal change through gdaa (using resourceid)
... , point is:
during time trying make work, realized gdaa is not suited applications (like 1 we're discussing here). gdaa goes through kinds of hoops , loops make online/offline state transparent , @ same time cache data , optimize network traffic, battery use, ... creates latency, unpredictable states...
... so, in end stopped blaming gdaa not being swiss-knife , ever dreamed up. developer understand advantages / drawbacks of toolbox he/she using , decide upfront tool use. know, docs not spell out , believe me, myself got caught in magnus's excitement. still remember pinoyyid's warning in january 2014, telling me not jump in early.
good luck
Comments
Post a Comment